推遲承諾

Nov. 25 16:11~16:57

 

上禮拜在北科上課的時候，Teddy跟同學提到精實開發的七個原則，其中有一條是defer commitment（推遲承諾），又稱為decide as late as possible。這個原則在不同的敏捷方法，例如XP、Scrum、Kanban，都看的到。

***

Kanban
Kanban方法可以把整個價值流分成三段，開發團隊可以控制的部分用Kanban方法來管理工作流，開發團隊不能控制的部分，可分為上游（upstream）與下游（downstream）。假設上游是stakeholder的需求，從Kanban的角度來看，當需求的價值尚未明確之前，不需要急著把工作「拉入」到Kanban系統當中。但是一但工作拉入之後，就要儘快完成。這就是一種推遲承諾的例子。

 

Kanban方法沒有iteration，因此若是採取JIT（Just in Time）的方式，當需求要被實作的時候再來分析採解它，這也是一種推遲承諾的表現。

***

Scrum
Scrum的推遲承諾最明顯表現在product backlog上面，只要足夠1~2個sprint工作所需的product backlog item（PBI）都經過討論、估算、撰寫驗收條件就可以了，其他的PBI可以等到即將被挑選出來實作之前再來討論。

***

XP

接下來要舉的例子其實在敏捷方法中都適用，只是XP更強調，就是TDD。先寫一個會失敗的測試案例，然後撰寫足夠讓這個測試案例通過的production code，然後再透過refactoring改善設計。不需要事先花很多設計功夫，透過一連串有紀律的小步驟就可以讓軟體品質維持在一個可接受的範圍內。這種做法，當然也是推遲承諾的表現。

***

敏捷開發不是要「騙選票」，不需要七早八早承諾一堆作不到的「支票」。與其亂改路名、亂發津貼，還不如等真正需要的時候再承諾。

***

友藏內心獨白：選票先騙到再說，不是有人說政見又不一定要兌現嗎。