Sprint Review不是回顧，其目標是演示這個Sprint中自己的工作成果，參會人員包括設計師、開發人員和Product Owner。在Worktile，我們儘量保持Sprint評審會的輕鬆隨意氛圍。團隊成員們會聚集在桌子周圍進行非正式的演示，講述自己在本次迭代中完成的工作。在這期間團隊成員可以相互提問、嘗試新的功能並提供反饋。成功的分享是構建敏捷團隊的重要工作。
首先，我們回顧一下為什麼團隊對“完成”的定義對Sprint review如此重要：
第一步：定義“完成”
如果你在使用敏捷開發工具，那麼你就應該清楚將任務卡從“測試中”拖到“已驗收”這個操作會令你非常有成就感。這個任務卡的流轉代表著一項工作終於完成了！
在截止時間前完成工作需要合理的規劃、定義清晰的“完成”和專注的執行力。雖然大多情況下，這些工作是在Sprint規劃階段要做的事，但為了確保Sprint和review能順利進行，團隊要做的遠不止規劃，還要形成一種清晰的交付文化以及明確“完成”的定義。
交付文化
高效團隊能夠將清晰的流程和開發文化帶到每個工作項中。你可以用下面這些問題來評估一下你的流程，確保該流程能讓團隊保持最佳狀態：
- 實施前，Product Owner、設計師和研發團隊對使用者故事的定義是否明確？
- 每個人是否都理解並踐行團隊的工程價值觀和文化？
- 關於程式碼審查、自動化測試和持續整合是否有明確的定義和需求來鼓勵可持續的敏捷開發？
- 團隊每完成一個使用者故事，是否會有很多bug？ 換句話說，“完成”是否真的意味著“完成”呢？
團隊的質量和完成文化應該在每個使用者故事、工程工作項和bug之上。這種文化反映了團隊交付軟體的方式。
為每個工作項定義“完成”
明確 “完成”的定義可以幫團隊聚焦每個工作項的最終目標。當Product Owner在團隊的backlog中新增工作時，定義驗收標準是他工作流程中非常關鍵的一部分。使用者故事的完成意味著什麼？在Worktile，團隊也會跟蹤其他使用者故事的驗收標準和測試說明。這樣，整個團隊就能夠明確掌握每個工作項的完工情況。那麼什麼是驗收標準和測試說明呢？
- 驗收標準：Product Owner用於確認故事已滿足其需求的指標。
- 測試說明：來自質量支援團隊的簡短、有針對性的指導，可幫助開發工程師編寫更好的功能程式碼進行自動化測試。
定義明確的事項在實施過程中更容易成功。通過使用Worktile，團隊可以輕鬆新增欄位及描述，讓每個任務都有清晰的定義。
第二步：慶祝團隊成果
Sprint review是慶祝團隊和個人在迭代過程中所取得成就的好時機。所以在Worktile，我們通常在週五下午進行Sprint review。Sprint review並不是回顧的同義詞，所以要確保在迭代完成之後，回顧之前舉行Sprint review會議。雖然我們歡迎外部人員加入會議，但通常情況下是Product Owner、整個開發團隊和Scrum master參與會議。為了取得最佳效果，建議每個迭代花費30分鐘到1小時的時間。
我們喜歡Sprint review，因為它可以保證團隊的健康和士氣。Sprint review的核心目標就是團隊建設。review並不是對抗，也不是考試——而是整個團隊的協作活動，讓成員可以展示自己的工作，現場交流並獲得反饋。
如果Sprint review沒能在團隊中產生積極影響，原因可能是：
- 團隊任務太多以至於迭代期間無法完成；
- 團隊深陷現存的技術債；
- 功能開發未能確保持續性，以避免在程式碼庫中引入新的bug；
- 團隊的開發習慣沒有適時調整；
- Product Owner在迭代過程中更改了優先順序，而開發團隊則因範圍的變更陷入困境；
注意：團隊在迭代中遇到困難是常有的事。迭代回顧會議時，團隊可以花費點時間探討一下為什麼迭代過程中會發生變更，並制定計劃在下一個Sprint中解決問題。
最後建議
對於那些不熟悉sprint review的團隊來說，它們很容易就將其併入sprint回顧會議。Sprint review是獨立於sprint回顧會議之外的獨立儀式。通過sprint review，我們可以花點時間享受工作成果、自由地慶祝成就。有效的sprint review可以增強團隊的士氣和動力。
文章來源：Worktile敏捷部落格
歡迎訪問交流更多關於技術及協作的問題。
文章轉載請註明出處。