前言

項目不太可能一帆風順的進行到驗收，而是充滿了變數，愿望是美好的，但現實是殘酷的。所以這一次我想跟大家介紹一下如何團隊如何面對失敗的Sprint。

如何判定Sprint成敗

Sprint的成敗實際上沒有涇渭分明的一條線，除非團隊跟PO在做計劃會議時就約定Sprint目標。
所謂Sprint目標就是PO確定的本Sprint最重要的任務項，沒有完成目標，那么做多少其他工作也是枉然。
有了Sprint目標，成敗在Sprint結束時就一清二楚了，實際上團隊成員在Sprint沒結束時就能確定Sprint會不會失敗，要是每個團隊成員都覺得Sprint已經完蛋了，那還是及早調整的好。

Sprint失敗的誘因

接下來我們說說Sprint失敗的常見誘因有哪些：
1.團隊成員突發性調整
這個因素對于小團隊幾乎是致命的，如果是正常的5人團隊，1人突然提出離職，1人被調到其他項目中，那么SM還是及早跟PO商量對策為好。
2.PO經驗不足
這個因素也很常見，PO經驗不足，在Sprint內進行大量的緊急需求的插入導致主要目標都無法完成，或是PO弄錯了Sprint目標，導致給用戶演示被一頓噴，從而導致失敗。
3.技術債務爆發
有句話叫出來混早晚要還的，這類問題在對原有系統的升級中最為常見，本來預計3天完成的任務，結果搞到Sprint結束沒有搞定，遺留系統往往牽一發而動全身，這改好了那又崩潰了。
4.不敢面對現實
這個也是十分常見的，在計劃會議上明明已經發現了風險，很可能導致無法完成相應目標，但是礙于情面或過于樂觀沒有提出來調整目標，導致在Sprint結束時無法完成任務。
或是本來預計這個任務需要一個特殊的人投入5天，結果這個人常常被臨時任務打斷，在計劃會議時沒有考慮這個問題，或是心存僥幸，導致Sprint都被卡住掛掉。
本質原因：組織文化有問題，若組織文化良好，以上都不是問題，經驗不足的PO根本不可能上位，人員調整也應該提前規劃和商議，技術債務應該提早預估，應該按照股則來進行評估

如何處理

項目周期最后的回顧會議就是專門處理這個問題的。
最重要的是不要一味的追究是誰的責任。
如果Sprint失敗了，那么回顧會議就十分重要了，但是不要直接就開回顧會議，要先收集資料和數據，這樣在會議才能有跡可循。
讓團隊騰出一個大段時間來舉行回顧會議，同時PO必須要參加。
以下是注意事項：
1.重點不是追究責任，而是分析更深層次的原因，然后改進
2.如果確實是團隊成員的問題，那么必要的人事調整是必不可少的。
3.這種回顧會議時間一般少于2小時，要是開了10分鐘大家都覺得沒問題了，那么說明還有更大的問題隱藏著。
4.切忌含糊其辭，否則團隊就變成大鍋飯
5.一切以事實為依據，對事不對人，注意不能變成批斗會
6.改進要進行追蹤和確認。

不要一味的追究是誰的責任

總結

以上是生活随笔為你收集整理的敏捷开发中团队如何面对失败的Sprint的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。