如何提升Sprint Review的質量？

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敏捷博客

歡迎訪問交流更多關於技術及協做的問題。

文章轉載請註明出處。