敏捷開發甘苦談 - 20170401


今天是要來分享 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. 

幾個原因造成這次大爆胎的:
1. 一個外部 API 服務有根本上的改變,
   虛耗 Android / iOS 各一名開發人員一週工時.
   (造成有實際工時但對整個 Sprint 是無效的開發)
2. APP 與儀器溝通的 Protocol 頻繁變動,重複消耗開發時間.

3. 新的 UI 設計調整,溝通的時間比平時多,才能完成修改.

4. 問題回饋的管道品質低落,
    造成測試人員要花費更多心力整理才能回覆給開發端,
    驗證時程整個往後堆疊,無法及時反應開發錯誤.

結論
1. 可預測性基於可靠性
2. 需求不可以憑想像力就隨便亂加
3. 需要深切檢討的不是工程師,而是規劃管理的人

留言