目錄
怎樣進行每日例會
每天都會在同一個地方，同一個時間進行，在任務板前面進行每日例會。時間限制15分鐘。
更新任務板
每日例會的時候更新任務板。每個人都會一邊描述昨天已經做的事情和今天要做的事情，一邊移動任務板上對應的即時貼。
如果他講的是一個未經計劃的條目，那他就新寫一張即時貼，貼到板上。如果他更新了時間估算，那就在即時貼上寫上新的時間，
把舊的劃掉。
都要盡力讓整個團隊參與到保持 sprint backlog 及時更新的工作中來。如果只上Scrum Master一個人維護sprint backlog,會導致以下缺點：
- Scrum master 把太多時間用在了管理之類的工作上，而不是爲團隊提供支持，消除他們的障礙。
- 因爲團隊成員不再關心 sprint backlog，所以他們就意識不到 sprint 的狀態。缺少了反饋，團隊整體的敏捷度和精力的集中程度都會下降。
每日例會一結束，就要有人算出剩餘工作的時間估算之和（自然，那些被放在“完成”一欄中的就不用算了），在 sprint 燃盡圖上畫上一個新的點
處理“我不知道今天干什麼”的情況
有時候，有人會說“我昨天干了這個、這個和這個，但是今天根本不知道該幹什麼。”
跟團隊一起從上到下遍歷任務板，檢查是否所有條目都已同步，保證所有人都清楚每個條目的含義等等。然後請人添加更多的即時貼上去。接下來我就會對覺得自己沒事可幹的人說，“我們已經過了一遍任務板，你們現在對今天要做的事情有想法了麼？”。但是如果團隊還沒有達成目標，而且 Joe 和 Lisa 還就是不肯做些有用的工作，那又該怎麼辦？一般我會嘗試下面的某種策略（這些都不怎麼讓人愉快，但已經是無可奈何之計了）：
- 羞辱式做法： “如果你不知道怎麼幫助團隊，我建議你還是回家去，或者看書，或者怎麼都行。要不也可以找個地方坐下，等別人需要幫忙的時候你就過去。”
- 守舊式做法： 簡單給他們分配個任務了事。
- 施加同事壓力的做法： 對他們說，“Joe，還有 Lisa，你們兩個可以放鬆點，我們會站在這裏慢慢等，直到你們找到幫助我們完成目標的事情爲止。”
- 奴役式做法： 對他們說，“你們今天可以給大夥兒乾乾雜活。倒咖啡、做按摩、清理垃圾、做午飯，一切一切大家今天讓你們做的事情。”你會驚訝的發現 Joe 和 Lisa 在霎那之間就找出了有用的技術任務:o)
怎樣進行 sprint 演示
時間盒：一個月的迭代：4小時，2周的迭代：2小時
Sprint 演示會（有人也叫它 sprint 評審）是 Scrum 中很重要的一環，卻常爲人們低估。sprint會議的影響：
- 團隊的成果得到認可。他們會感覺很好。
- 其他人可以瞭解你的團隊在做些什麼。
- 演示可以吸引相關干係人的注意，並得到重要反饋。
- 演示是（或者說應該是）一種社會活動，不同的團隊可以在這裏相互交流，討論各自的工作。這很有意義。
- 做演示會迫使團隊真正完成一些工作，進行發佈（即使是隻在測試環境中）。如果沒有演示，我們就會總是得到些99%完成的工作。有了演示以後，也許我們完成的事情會變少，但它們是真正完成的。這比得到一堆貌似完成的工作要好得多，而且後者還會污染下一個 sprint。
Sprint 演示檢查列表
- 確保清晰闡述了 sprint 目標。如果在演示上有些人對產品一無所知，那就花上幾分鐘來進行描述。
- 不要花太多時間準備演示，尤其是不要做花裏胡哨的演講。把那些玩意兒扔一邊去，集中精力演示可以實際工作的代碼。
- 節奏要快，也就是說要把準備的精力放在保持演示的快節奏上，而不是讓它看上去好看。
- 讓演示關注於業務層次，不要管技術細節。注意力放在“我們做了什麼”，而不是“我們怎麼做的”。
- 可能的話，讓觀衆自己試一下產品。
- 不要演示一大堆細碎的 bug 修復和微不足道的特性。你可以提到一些，但是不要演示，因爲它們通常會花很長時間，而且會分散大家的注意力，讓他們不能關注更加重要的故事。
怎樣進行Sprint回顧會
時間盒：一個月的迭代：3小時，2周的：1.5小時
看起來每個人都覺得回顧的用途極大。說句實話，我認爲回顧是 Scrum 中第二重要的事件（最重要的是 sprint 計劃會議），因
爲這是你做改進的最佳時機！
回顧會議一般沒有太規整的結構。不過潛在的主題都是一樣的：“我們怎樣才能在下個 sprint 中做的更好”。
回顧會可從三方面入手：
- Good： 如果我們可以重做同一個 sprint，哪些做法可以保持。
- Could have done better： 如果我們可以重做同一個 sprint，哪些做法需要改變。
- Improvements： 有關將來如何改進的具體想法。
在團隊中傳播經驗
一些重要規則：
- 他應當是一個很好的傾聽者。
- 如果回顧會議過於沉寂，他應該問一些簡單而目標明確的問題，以刺激團隊展開討論。例如“如果時間可以倒流，從第一天重新開始這個 sprint，那你覺得哪些事情會用其它方式來做？”
- 他應該自願花時間參加所有團隊的全部回顧。
- 他應該有一定的行政權力，如果出現一些團隊無法控制的改進建議，他可以幫助推進實施。
變還是不變
很多時候，只要能清楚地指出問題所在，到了下一個sprint，問題也許就自行解決了。把 sprint 回顧結果貼在團隊房間的牆上（我們常常忘了這一點，可真丟人！）會更有效。
Sprints 之間的休整時刻
在實際生活中，你不可能一直像上緊了發條一樣始終高速工作。你需要在衝刺的間歇休息。如果弦總是繃得那麼緊，實際上收到的成效反而不好。
Sprint 演示和回顧結束以後，團隊和產品負責人都有一大堆信息和想法需要消化。如果他們立刻計劃下一個 sprint，那就沒人能有機會消化現有的信息或是學到的經驗，產品負責人也沒有時間在 sprint 演示以後調整優先級。
制定發佈計劃
定義驗收標準
除了普通的產品 backlog 之外，產品負責人還會定義一系列的驗收標準，它從合同的角度將產品 backlog 中重要性級別的含義進行了簡單分類。
下面是驗收標準規則的一個例子：
- 所有重要性>= 100 的條目都必須在 1.0 版中發佈，不然我們就會被罰款到死翹翹。
- 所有重要性在 50 - 99 之間的條目應該在 1.0 中發佈，不過也許我們可以在緊接着的一個快速發佈版中完成這些。
- 重要性在 25 – 49 之間的條目也都是需要的，不過可以在1.1 版中發佈。
- 重要性< 25 的條目都是不確定的，也許永遠不會用到。
下面是一個產品 backlog 的例子，根據上面的規則標記了不同顏色。
| 產品 backlog | 對最重要的條目進行時間估算 | 統計一切因素，生成發佈計劃 |
 |
 |
 |
| 紅= 必須在 1.0 版中發佈（banana – pear） 黃= 應該在 1.0 版中發佈（raisin – onion） 綠= 也許可以以後再做（grapefruit – peach） |
這個會議的時間必須要嚴格限制，不然團隊就會把大量時間花費在 少數幾個故事上。 |
估算投入程度：投入程度表示“團隊有多少時間可以放在當前所承諾的故事上”，一般都是70%左右 |
對最重要的條目進行時間估算
- 讓團隊來做估算。
- 不要讓他們花太多時間。
- 確保他們理解時間估算只是粗略估算，而不是承諾。
調整發布計劃
每個 sprint 之後，我們都要看一下這個 sprint 的實際生產率。如果實際生產率跟估算生產率差距很大，我們就會給下面的 sprint 調整生產率，更新發布計劃。
Sprint 週期
驗收測試應該作爲 sprint 的一部分麼？
我們在這裏分歧較大。有些團隊把驗收測試當成了 sprint 的一部分。
但大部分團隊都沒這樣做。原因主要有兩點：
- Sprint 是有時間盒限制的。驗收測試（在我的定義中，它要包括調試和再次發佈）的時間卻很難固定。如果時間用完了，你還有一個嚴重的 bug 怎麼辦？是要帶着這個嚴重 bug交付上線，還是等到下個 sprint 再說？大多數情況下，這兩種解決方案都是不可接受的。所以我們把人工驗收測試排除在外。
- 如果有多個團隊開發同一個產品，那就得等所有團隊的工作成果合併以後，再進行人工驗收測試。如果每個團隊都在 sprint 中進行人工驗收測試，最後還是要有一個團隊測試最終版本，而且這個版本集成了全部團隊的工作。
“可以開始構建新東西，但是要給‘將舊功能產品化’分配高優先級”
一般我們完成一個 sprint 以後就會開始進行下一個。但是我們會在接下來的 sprint 中花一些時間解決過往 sprint 中留下的 bug。如果修復 bug 佔用了太多時間，從而導致接下來的 sprint 遭到嚴重破壞，我們就會分析問題產生的原因以及如何提高質量。我們會確保sprint 的長度，使之足以完成對上個 sprint 中一定數量 bug 的修復。
在 sprint 計劃會議上，考慮到會花時間修復上個 sprint 的 bug，所以我們會把投入程度設得足夠低。經過一段時間，團隊在估算方面已經做得很到位了。生產率度量也起到了很大幫助作用