一、scrum軟件開發用例

scrum軟件開發用例有一個“三三四”原則，即三個角色、三個產出物、四個會議。

?? 三個角色：PO、Scrum Master、Dev Team

PO：Product Owner，一般都是產品經理，負責需求分析和整理、分解驗收story、維護Product backlog等（關于backlog和story會在下面有詳細的描述）。Scrum Master：扮演推動者的角色，他要負責主持會議、協助團隊內部成員解決困難、解決外部對團隊內部的過分干擾、和外界的主要溝通工作等。Master可以由專門的人來擔當，也可以由團隊內部的成員來擔當，很多團隊都是由PO來同時兼任Master，筆者建議由團隊內部成員輪流擔當，這樣能夠培養團隊成員的責任感，增強團隊的凝聚力，并讓大家更加容易理解敏捷開發的精髓。Dev Team：整個開發和測試團隊，包括UI設計師等所有相關人員。

?? 三個產出物：Product Backlog、Sprint Backlog、Potential Shippable Product Increment

Product Backlog：產品需求池Sprint Backlog：此次需要開發的需求集合Potential Shippable Product Increment：可交付的結果

?? 四個會議：Sprint Planning、Daily Scrum Planning、Sprint Review、Sprint Retrospective

Sprint Planning：需求評審會和迭代啟動會，這個會議上，需要得出以下結論：全員明確清晰的迭代目標澄清所有的需求及技術實現風險評估需要的工作量，以及需要投入的人員確定出所有最終需要發布的功能集合及工作量，需要將Story拆解成Task，以小時為單位。Daily Scrum Planning：每日站會，顧名思義，就是站著開會，大家圍成一個圈或者半圈，這樣做有兩個目的，一個是高效，另一個是可以方便團隊所有人都可以看見對方。站會的目的有以下3個：監督個人的承諾：確認個人是否完成昨日的目標培養團隊文化了解項目進展：團隊中每個人都應該了解其他人在做的事情，以及當前團隊的進展和風險。最實際的好處就是這樣可以清楚的知道別人做的事情是否對自己有影響，或者自己是否可以提供幫助等。

站會的時間，建議不超過15分鐘，只描述狀態和任務，不討論技術細節，另外，每個人圍繞以下3個話題來簡單描述自己的進展：

昨天完成了什么？目前有什么困難，需要幫助的？今天準備做什么？

站會的時候，Scrum Master一定要注意以下問題：制止不必要的討論、禁止小會、控制發言時間、不要跑題等，另外，站會的時候，Master需要修改燃盡圖（后面會有對燃盡圖的詳細描述）。

Sprint Review：迭代評審會，此次會議的主要內容是相關利益者及團隊成員展現本次迭代的功能增量，需要注意的是不展示未完成的功能，也不需要PPT，演示結束后記錄好相關反饋。很多采用敏捷開的團隊都不開Review會議，其實Review會議是有一定的好處和目的的：可以讓團隊的成果得到認可，提升團隊的自我價值感其他人可以了解團隊在做的事情可以吸引一些利益相關者的注意，并得到一些反饋演示能夠對團隊成員造成的一定的壓力，迫使團隊認真完成工作Sprint Retrospective：迭代回顧會，會議主要是回顧此次迭代的整體情況，一定要全員參加，一起回顧此次迭代做的好的地方，以及需要改進的地方，并對這些需要改進的點，提出改進措施。

延伸閱讀：

二、看板 & 燃盡圖

看板一般是一個物理白板，目的是做迭代進展可視化跟蹤和協作溝通。看板上需要將每個人的任務，以對應的狀態（To Do/Not checked out、Doing/Checked out、Done）展示出來，一般使用便簽紙。

同時要在白板上畫出燃盡圖，燃盡圖指示的是當前剩余的工作量，是一個跟蹤項目進展非常好的指示器。燃盡圖上一般有2條曲線，如下圖的燃盡圖，灰色的直線表示的是優異剩余工作量曲線，藍色的表示實際的剩余工作量曲線，正常情況下，藍色的線應該在灰色的線上下浮動，并在最后一天合到同一個點上。燃盡圖可以在每天站會的時候由PO更新狀態。