周金根：個人敏捷的創立與詳解Scrum會議
原創【51CTO專稿】在敏捷實踐中，Scrum可以說是用于運行項目的框架，它基于敏捷的原則和價值。對于管理嚴格的項目團隊，Scrum會議也會每天都在同一時間進行。通過每日Scrum 會議，團隊成員之間可以彼此相互熟悉工作內容，充分了解項目進度，相互幫助解決問題。那么，在Scrum中的Sprint計劃會議應當如何進行？記者采訪了敏捷個人創立者，周金根老師跟網友們談談Scrum的實施與Sprint計劃會議。
個人簡介：周金根，個人成長教練，軟件產品架構師，培訓師，敏捷個人創立者和推廣者。
以下內容為采訪實錄：
記者：請問你是如何接觸到敏捷開發的？敏捷個人的創立是出于什么樣的想法？
周金根：最早我們是采用RUP開發的（可以看看從IT方法論來談RUP），我記得在一個產品設計階段，我們使用Rose畫了很多圖，但是最終開發的時候其實沒有人去看；更為重要的是，產品交付之后需求變更很多。這之后，我就開始關注軟件全生命周期的方法、技術和工具，于是了解了敏捷。最早是XP，然后是Scrum。08年我去了一個新的項目組，這個組沒有開發流程方法，也不知道如何做需求，于是我在這個組實踐了一些新的方法，其中包括Scrum。在Scrum的實施過程中，我發現并不像最初想象的簡單。看似簡單的流程和角色，真正要發揮功效并不容易，除了技術能力之外，我還需要讓自己學習更多管理方法，更需要自己深入領悟敏捷管理背后的東西。對Scrum的深入思考，我越發覺得團隊中每個人的成長是敏捷發生效果的動力，這讓我對個人管理這個話題有了更加濃厚的興趣，于是把自己在個人管理和個人成長方面的思考寫下來，并在團隊中學習和實踐。團隊中的成員有自發打印出來給家屬學習的，也有主動參與討論的，以及后期社區對敏捷個人的認可，這都鼓勵和激發我慢慢系統化的思考個人成長，并提出了敏捷個人。 經過兩年多的思考，目前敏捷個人已經是一個較為體系的個人成長框架，它可以幫助個人成長，并促進敏捷團隊的形成。
記者：請問敏捷開發是否真的能解決傳統開發的一些問題？如何去認識敏捷的根本？
周金根：從瀑布到敏捷，我們已經發現產品更適合用戶、質量越高、上市時間也越短，敏捷順應不斷變化的時代，是否能解決傳統開發已經不是一個問題。對于敏捷，我認為其根本在于學習和適應，這也是擁抱變化需要具備的兩項最重要的能力。
記者：團隊的敏捷實踐與管理是分不開的，您是怎么看目前國內的管理？
周金根：在沒有敏捷之前我們就在管理，但在敏捷盛行的時候，有些管理者就分不清敏捷和管理了。其實我不太在意某種***實踐出自哪種敏捷方法，我認為只要有利于當前團隊的實踐都是管理的一種工具，也就是說，作為管理者，我們仍需保持更大的視角，敏捷僅是管理的一種工具，我們還要學習目標設定、流程優化、團隊建設、個人成長等更多管理方法。
記者：有些人認為敏捷開發并不適用于水平一般的程序員或團隊，您是怎么認為的？
周金根：任何方法都不是銀彈，也說明了沒有一種方法是***的。既然沒有***的方法，那自然也不必是***的人去執行了。水平高的程序員在技術實踐領域的敏捷固然可以做得更好，但一個產品的失敗大多數都不是因為你是否采用了測試驅動、結對編程等***實踐，而是開發管理上的問題。Scrum作為一種敏捷方法，背后具有很多管理思想，只要管理者和團隊對Scrum有進一步的思考和認識，也可以很大程度上去提高技術水平一般的程序員團隊。
周金根：敏捷方法在國內實施起會導致項目管理原有模式的改變，而很多公司都沒有達到敏捷的目的。以致公司往往不愿意引進這樣的開發模式。您怎么看待這個問題呢？
回答：從公司角度來說，你能把軟件越快越好的做出來就可以了，至于采用的是敏捷還是瀑布并不重要。與其說是公司不愿意引進這種模式，不如說是軟件開發負責人不愿意或者沒有能力引進新的方法。敏捷開發相對來說已經比較成熟，我認為現在不是討論是否愿不愿意引進這種開發模式的時候，反而是思考如何引進的問題，這不僅僅是技術實踐，還有管理，甚至是個人成長方面的改變。
記者：團隊的人數對于敏捷開發有何影響？如何進行拆分？
周金根：人數的規模會帶來團隊的復雜性，隨著人數增加，管理、溝通等都會越來越困難。而保持7±2人左右的小團隊，可以更利于團隊的形成。在這樣的團隊中，人與人之間都更為熟悉，協作起來就更容易。那這樣的小團隊由哪些人組成呢？這也需要根據產品的規模來定。對于一個小型產品，這個團隊將由市場、需求、開發、測試等人員組成全功能性團隊；如果產品屬于中大型，那有可能會形成單一功能性團隊，再由多個這樣的團隊組成一個大的敏捷團隊，由這個大的團隊來實現對客戶的交付。
記者：敏捷實踐過程中Scrum實施整個過程怎樣規劃。
周金根：實施Scrum，我們可以采用類似學習一樣的過程，首先完全按照Scrum流程執行；然后再根據執行后的效果進行自我裁剪和補充；***淡化Scrum的概念，與更大范圍的軟件產品周期過程融合起來。
記者：敏捷開發的方法內有很多不同的程度，而幾乎每個敏捷開發團隊都有scrum會議，在您們的團隊中是如何進行的？
周金根：溝通在任何團隊都是必不可少的，而會議是其中一種。我認為Scrum中的Sprint計劃會議是最重要的事件，這確定了每次迭代的目標。回顧會議是第二重要的事件，因為這是團隊做改進的***時機，如果沒有回顧，就會發現團隊在重犯相同的錯誤。如何進行可以看看我之前寫的幾篇blog：
1、Scrum之 Sprint計劃會議（以下內容摘自周金根博客）
sprint計劃會議1
產品負責人和團隊一起，在先前評估的成果基礎上，定出 Sprint 目標和既定產品Backlog。
目標
定出 Sprint 目標和既定產品 Backlog
會議準備
- 邀請與會者：產品負責人、Scrum Master、團隊所有成員
- 已按優先級排列產品 Backlog 中各項問題
- 已評估 Backlog 中的各項問題
- 把產品 Backlog 公開給會議中的每個人，保證其可被獲取
- 預期團隊中有哪些人已明確會缺席（如度假）
- 保證房間環境適合小組討論
- 每個人都可以獲取上次 Sprint 評審會議和 Sprint 回顧會議的結果
- Sprint 時間表已經安排
- Sprint 計劃會議 1 的時間安排
- Sprint 計劃會議 2 的時間安排
- Sprint 的***天已確定
- Sprint 的***一天已確定
- Scrum 每日例會的時間安排
- Sprint 評審會議的時間安排
- Sprint 回顧會議的時間安排
- （可選）為既定 Backlog 準備圖釘板:一個至少 2x2 米的圖釘板、卡片和貼紙、熒光筆
- （可選）用作計劃紙牌的卡片
會議進程（4 小時）
- 把 Sprint 時間表公開給所有人
- 把 Sprint 評審會議的結果公開給所有人
- 把 Sprint 回顧會議的結果公開給所有人
- 產品負責人向團隊產品闡述產品遠景
- 產品負責人和團隊一起確定 Sprint 目標
- 如果 Backlog 里有問題遺漏：產品負責人有權限往 Backlog 里添加問題
- 如果產品 Backlog 完全未被評估：選擇 Backlog 中您認為是最小用例的問題，并指派其工作量為 2 個Story Point。以這個最小用例的工作量標準，分配 Backlog 中其他問題的 Story Point
- 如果 Backlog 中的一些問題尚未被評估：根據其他問題工作量，評估這些問題的 Story Point 量
- 如果產品 Backlog 中的各項還沒能合理地按優先級排序:產品負責人對產品 Backlog 中的各項按優先級排序
- 產品負責人和小組成員相互認可這 Sprint 目標和既定產品 Backlog
會議結果
為Sprint計劃會議2的進行準備好既定產品 Backlog
sprint計劃會議2
在 Sprint 計劃會議 2 中，團隊將既定產品 Backlog 中的每一項細化成多個任務。每個任務完成的時間限定在一天內。
目標
確定所有任務，生成 Sprint Backlog，確認 Sprint 目標
會議準備
- 邀請與會者：Scrum Master、團隊所有成員、產品負責人（可以有權得知所有問題）
- 任務規劃時可以參考既定產品 Backlog
- （可選）為既定 Backlog 準備圖釘板:一個至少 2x2 米的圖釘板、卡片和貼紙、熒光筆
會議進程（4 小時）
- 團隊成員從 Backlog 的各項問題中分出相應的任務
- 確保考慮到工作中所有的細節:編碼、測試、代碼評審、會議、學習新技術、編寫文檔
- 如果任務需時超過一天：嘗試把該任務分割成幾個小任務
- 如果團隊認為 Sprint Backlog 中項過多：和產品負責人一起刪減 Backlog 中的問題
- 如果團隊認為 Sprint Backlog 中的項過少：和產品負責人一起從產品 Backlog 中選出最重要問題，加入Sprint Backlog 中
- 團隊確認 Sprint 目標
會議結果
- Sprint 目標和 Sprint Backlog 對于公司內的所有人都是公開的
- 所有團隊成員都可以獲取 Sprint Backlog 中的任務
2、Scrum之 站立例會（以下內容摘自周金根博客）
在sprint期間，每天都會通過站立例會來進行溝通，以下我將把會議主要內容羅列一下。（以下會議內容來自于Scrum Checklists)
會議內容
目標
團隊成員間工作進度的溝通和協調
會議準備
- 邀請與會者：團隊所有成員、Scrum Master、產品負責人（可選）、相關人員（可選）
- 在Sprint Backlog 上的所有任務都是可以增刪修改，可重排序的
- 任務的狀態可設為todo、doing、done（可以再加一個test表示需要驗證）
會議進程（15 分鐘內）
- 上次會議時的任務哪些已經完成：把任務從“正在處理”狀態轉為“已完成”狀態
- 下一次會議之前，你計劃完成什么任務？ •如果任務狀態為“待處理”：轉為“正在處理”狀態
- 如果任務不在 Sprint Backlog 上：添加這個任務
- 如果任務不能在一天內完成：把這任務細分成多個任務
- 如果任務可以在一天內完成：把任務狀態設為“正在處理”
- 如果任務狀態已經是“正在處理”：詢問是否存在阻礙任務完成得問題
- 有什么問題阻礙了你的開發：如果有阻礙你開發進度的問題，把該障礙加入到障礙 Backlog 中
- 如果展開了一個問題的討論：提醒團隊的成員們注意把精力集中在回答關鍵問題上
- 如果相關人員想發表些言論：禮貌地提醒他，該會議只允許讓小組成員討論
會議結果
- 得到***的障礙 Backlog
- 得到***的 Sprint Backlog
- ***的工作進度圖
其他
可以指定一個主持人（或輪流）。他來召集并控制會議時間，會議中注意引導話題，在會議結束時可以做個簡短的總結，說出重點就行，做好每日規劃。
3、Scrum之 評審會議（以下內容摘自周金根博客）
在sprint周期***，需要進行一次評審會議，讓團隊向產品負責人和利益相關者展示已完成的功能。sprint審核的大部分實踐用于團隊成員展示功能、回答利益相關者對展示的疑問并記錄所期望的更改。評審會議可以吸引相關利益者的關注，讓其他人了解團隊在做些什么，并得到重要反饋。做演示也會迫使開發團隊真正完成一些工作。
- 小組準備好工作站和設備等等，用以展示產品的新功能
- 團隊準備sprint審核實踐不應超過1小時
會議進程（4小時）
- 確保所有人員都清晰目標，如果有人對產品不知道，則花幾分鐘來進行描述。
- 團隊按 Backlog 中的問題，逐個地介紹這次 Sprint 的結果，和演示新功能。
- 如果產品負責人想要改變功能：添加一個新問題到產品 Backlog 中
- 如果對功能有一個新的想法：添加一個新問題到產品 Backlog 中
- 如果小組報告項目遇到阻礙現在還沒能解決：把該障礙加入到障礙 Backlog
- 會議結束時，ScrumMaster向產品負責人和全體利益相關者宣布下一次審核的地點和時間。
會議結果
- 對這次 Sprint 的結果和整個產品的開發狀態的共識
其他
- 讓演示關注業務層次，不要關注技術細節。注意力放在“我們做了什么”，而不是“我們怎么做的”
- 有的sprint可能會包含很多bug修復等功能，在評審會議中不要演示太多一大堆細碎的bug修復，除非這個很重要。
4、Scrum之 回顧會議（以下內容摘自周金根博客）
會議內容
目標
通過總結以往的實踐經驗來提高團隊生產力。
會議準備
- 邀請與會者： Scrum Master、團隊所有成員 、產品負責人（可選）
- 附屬工具：為所有參與者準備的熒光筆、貼紙、白板磁吸、白板和掛紙板
- 準備一個回顧白板，分三列。***列和第二列是回顧過去，第三列是展望將來。
- Good：如果重做同一個sprint，哪些做法可以保持
- Could have done better：如果重做同一個sprint，哪些做法需要改變
- Improvements：有關將來如何改進的具體想法
會議進程（1－3小時）
- 介紹會議目標和議程
- 準備（setting the stage）：制定和回顧團隊價值觀和約定（Team values and working agreements）：(10-30分鐘）
- 不管我們現在發現了什么問題，我們必須懂得并堅信每個人通過他們當時所知的，他所擁有的技能和可得到的資源，在限定的環境下，都盡其所能做出了***的成績
- 每個人都參與
- 坦誠交流
- 多說I，少用You
- 不深究具體業務細節內部問題
- 收集數據（Gather Data）：收集硬數據：事件（events）、度量（metrics）、完成的故事等
- 事件：對團隊每個人都重要的任何事件，包含會議、決策點、里程碑、采用新技術等，例如上期回顧會議中確定的改進項是否執行了
- 度量：包含燃燒圖、速度、bug數、完成故事點數、代碼重構數等
- 產生見解（Generate Insights）：多問“為什么”，從收集的數據中找出優點和問題
- 向與會者解說如何使用該貼紙進行工作：使用貼紙時，注意一張貼紙只記錄一件事。
- 派發貼紙，通過頭腦風暴分別得出回顧白板三列的所有想法。
- 確定改進項（Decide What to Do）
- 每人三票，投票決定下一sprint著重進行哪些改進（2－5項左右）。
- 結束回顧（Close the Retrospective）
- 給會議做個總結，表明下一個回顧會議需要跟蹤哪些做法
會議結果
- 回顧白板，以及下一sprint需要改進的做法，在下一個回顧中，會跟蹤這些改進的執行情況把障礙增加到障礙 Backlog 中去
記者： 對于未來幾年敏捷開發的發展，您希望看到哪些新方向?有何建議?
周金根：敏捷只是一個代名詞，我希望它不僅僅只包含開發，還能能夠在基于敏捷思想下，把方法框架擴充到市場、業務、營銷環節等軟件產品開發全生命周期。
