今天是要來分享 Sprint 失敗的經驗
團隊導入敏捷開發導入 1 年半來,
雖然也是有跌跌撞撞的時候,但大致上來說還算順利。
通常可以完成完預計的 Story,順利 Release 新版本,
頂多是需要草草結束 retrospective meeting
但這次的 Sprint 卻出現了可怕的炸裂。
預計結束 Sprint 的日子,有半數的 Story 尚未完成,
而且衍生出來的還有掛著 80+ 條 Bug Issue
遠遠超過平時,明眼的人一看,
就知道這是一個非常糟的 Sprint.
所以這週五下班時間一到的時候,我就催促著大家下班了,
明白地告知大家加班也不可能做的完.
好好放個清明連續假期.。
但事實上比想像中的還糟糕,因為有幾個可怕的點:
1. 這次 Scrum 的 Planning Meeting 的時候
還因為上一個 Sprint 的 retrospective 討論後
還調降團隊速率 (每個 Sprint 能完成的 Story point)
2. Planning Meeting 大家都清楚的確認自己身上有多少的功能
確認過身上的工作項目符合工時規劃且在自己能力可以完成.
3. 完全沒有產出可以執行 Review Meeting 的版本.
而且也沒有時間做 Review Meeting.
4. 仔細算了每個人完成的工作項目與工時,
基本上還超過平時的 Sprint.
確認過身上的工作項目符合工時規劃且在自己能力可以完成.
3. 完全沒有產出可以執行 Review Meeting 的版本.
而且也沒有時間做 Review Meeting.
4. 仔細算了每個人完成的工作項目與工時,
基本上還超過平時的 Sprint.
幾個原因造成這次大爆胎的:
1. 一個外部 API 服務有根本上的改變,
虛耗 Android / iOS 各一名開發人員一週工時.
(造成有實際工時但對整個 Sprint 是無效的開發)
2. APP 與儀器溝通的 Protocol 頻繁變動,重複消耗開發時間.
3. 新的 UI 設計調整,溝通的時間比平時多,才能完成修改.
4. 問題回饋的管道品質低落,
造成測試人員要花費更多心力整理才能回覆給開發端,
驗證時程整個往後堆疊,無法及時反應開發錯誤.
結論
1. 可預測性基於可靠性
2. 需求不可以憑想像力就隨便亂加
3. 需要深切檢討的不是工程師,而是規劃管理的人
留言
張貼留言