Scrum and XP from the Trenches - How we do Scrum 
Henrik Kniberg
http://www.crisp.se/ScrumAndXpFromTheTrenches.html


是否在sprints之間重新組織團隊

每個sprint通常來說是相當不同於其他的sprint, 這是因為在每個時段, 較高的優線順序的故事並不相同. 因此, 在每個sprint中, 最佳的團隊組成也就不同.

事實上, 幾乎在大部分的sprint中, 我們發現我們自己, 可能會說像這樣的話"這個sprint不是一般的sprint, 因為....". 在一段時間後, 我們放棄了"一般"sprint的概念. 沒有所謂的一般sprint, 就像沒有所謂的"一般"家庭或"一般"人一樣.

在這個sprint中, 有一個用戶端團隊隊可能是件好的主意, 它由非常懂用戶端程式的人所組成. 下一個sprint, 有兩個跨元件的團隊也可能是件好的主意, 把懂用戶端的人拆散到這兩個團隊中.

"團隊凝聚力"是scrum重要的關鍵之一, 也就是, 如果團隊要工作在一起好幾個spprints, 他們通常會變得非常緊密. 他們會學習到如何達成團體心流(group flow), 並達到令人難以置信的生產力水準. 但是需要花幾個sprint才能做到. 如果你持續變換組織, 你將無法達到真正的團隊凝聚力.

所以, 如果你要重新組織團隊, 確認你考慮過後果. 它是長程的改變還是短程的改變? 如果它是短程的改變, 那就考慮跳過它. 如果它是長程的改變, 那就進行吧

當你對大的團隊, 第一次進行開始進行scrum, 這裡有個例外. 在這種情況下, 值得對團隊的拆解做些實驗, 直到你找到每個人都滿意的答案. 並且要確認每個人都了解, 在前幾次犯些錯誤是可以被接受的, 只要你能持續改進.

兼職的團隊成員

我可以確認很多Scrum的書上說 - 在scrum的團隊中有兼職的成員, 一般而言不是一個好的主意.

假設你要讓Joe擔任你的scrum團隊的兼職成員. 請先仔細考慮一下. 你真的需要Joe到你的團隊嗎? 你確定Joe不能作全職嗎? 那他其它時間在做什麼? 有人能幫忙他做他的其它工作嗎? 好讓Joe在其他工作中變成被動或是支援的角色? 在下個sprint中, 能讓Joe在你的團隊中是全職, 並且同時把他的其他工作轉給別人嗎?

有時候就是沒有其他方法. 你非常需要Joe, 因為他目前這棟大樓是唯一的DBA, 但是其他團隊也非常需要他, 因此他很難把所有時間都用在你們團隊上面. 此外公司也沒有辦法僱用更多的DBA. 好的, 這種狀況下只好讓他可以兼職工作(這剛好是發生在我們身上). 但是, 要確定每次你都有做這樣的評估.

一般而言, 我寧可要一個團隊中有3個正職, 也不要有8個兼職

如果有一個人需要把它的時間分配到多個團隊, 像是上面提到的DBA, 最好讓他主要隸屬於某一個團隊. 找出哪一個團隊最需要他, 把它當作他的"主要團隊". 當沒有人急著需要他, 他可參加這個團隊的每日scrum會議, sprint規劃會議, 回顧會議等等.

我們如何進行Scrum-of-Scrums

Scrum-of-Scrums基本上是一個經常性的會議, 所有的scrum master聚在一起談話

在某個時間點, 我們曾經有4個產品, 其中3個產品都各自有一個scrum 團隊, 最後一個產品有25個人, 分成好幾個scrum團隊. 像是以下的狀況:

這意味著我們有兩個層次的Scrum-of-Scrums. 我們有一個"產品層次"的Scrum-of-Scrums, 由所有在產品D的所有團隊組成. 另外有一個"群體層次"的Scrum-of-Scrums, 由所有產品組成.

產品層次的Scrum-of-Scrums

這個會議非常重要. 我們每週舉行一次, 有時候可能頻率更高. 我們討論整合的問題, 團隊平衡的問題, 為了下次sprint規劃會議的準備, 等等. 我們保留了30分鐘, 但是經常超過. 另外一個方法是每天都有Scrum-of-Scrums, 但是我們沒有試過這樣.

我們Scrum-of-Scrums的議程
1) 圍繞著桌子, 每個人描述他們團隊上週完成什麼, 什麼計劃將藥本週完成, 以及他們遇到什麼困難.
2) 任何其他需要被提到的跨團隊的問題, 例如整合的問題.

對我來說, Scrum-of-Scrums的議程不是很重要, 重要的事情是你要定期舉行Scrum-of-Scrums會議

群體層次"的Scrum-of-Scrums

我們稱這會議叫做"脈動". 我們曾經試過各種不同的形式, 邀請不同的參與者. 後來, 我們已經放棄整個概念, 而是用每週所有人開會來代替(是的, 所有一起開發的人), 15 分鐘長的會.

什麼? 15分鐘? 所有人? 所有產品, 所有團隊的所有人? 這可行嗎?

是的, 只要你(或是其他主持會議的人)嚴格確保會議不要太長, 那就可行.

會議的形式像是
1) 由開發主管來更新或公佈訊息. 像是即將發生的事件.
2) 依序報告, 每個產品小組有個人報告他們上週完成什麼, 他們本周計劃完成什麼, 以及有什麼問題. 其他人也會報告(建構管理的lead, QA Lead等等)
3) 任何人自由去補充任何訊息, 或是問問題.

這裡是用來簡述團隊訊息的論壇, 不是用來進行討論, 或是反思的. 只要只剩這件事, 15分鐘通常夠用. 有時候我門會超過, 但是很少超過30 分鐘. 如果有些熱烈的討論出現, 我會中斷它, 請有興趣的人在會議結束後繼續這個討論.

為什麼我們要舉行全體的脈動會議? 因為我們注意到, 群體層次"的Scrum-of-Scrums的內容大多是報告而已. 我們很少有真正的討論. 此外, 許多其他團隊組織外面的人, 很渴望知道這類型的資訊. 基本上, 每個團隊想知道其他團隊在做什麼. 所以我們想, 既然我們花時間聚在一起來分享這些訊息, 那為什麼不讓所有的人都參加呢?


上一篇: Scrum and XP的實戰經驗 Ch15 (2)
上一篇: Scrum and XP的實戰經驗 Ch15 (4) http://www.wretch.cc/blog/kojenchieh/15289815

arrow
arrow
    全站熱搜

    kojenchieh 發表在 痞客邦 留言(0) 人氣()