敏捷方法，瀑布思維

April 22 10:59~11:38

▲只想依賴文件的敏捷就不敏捷了

 

瀑布流程與從小到大所受的訓練，使得開發人員習慣並且期待能夠在一個「相對不變」且有「標準答案」的基礎上從事開發活動。多年來開發人員被這種「按圖施工，保證成功」的瀑布思維訓練得非常成功，以至於既使轉移到採用敏捷方法，但瀑布思維卻根深蒂固存在開發人員的心中，成為不可分割的一部分。

***

在Sprint planning meeting的時候…

開發人員：這個user story你可以寫詳細一點嗎，或是等你想清楚了之後我們再做，否則到時候做好你又要改，這樣子我們很麻煩耶。

Product Owner內心獨白：我就是要等看到成品之後才有更進一步的想法啊。

***

在Sprint review meeting的時候…

Stakeholder：這個產生畢業證書電子檔的功能目前可以修改人名跟證書號碼，但是畢業日期跟科系為什麼是寫死不能修改的？

開發人員：這是Product Owner要求的。

Stakeholder：Product Owner為什麼要做這樣的限制，你在開發這個功能的時候不會覺得怪怪的嗎？

開發人員：Product Owner就要求這樣做，我們就照做啊。

***

敏捷開發是一種迭代與增量式開發，講難聽一點就是「重工（rework）」。如果一件事情可以按部就班一次做好，為什麼要用迭代與增量的方式？這不是很浪費生命、浪費資源嗎？就是因為需求、技術、外在環境等存在相當高程度的不確定性或風險，導致沒辦法「一槍斃命」，一口氣就做出使用者心中想要的產品，所以只好退而求其次，採用且戰且走，摸著石子過河的策略。

在敏捷開發中，如果鄉民們心裡還想著給我一份超完美文件我才願意開工，或是想要採取「只動你手，不動你腦」的方式完成開發工作（一個口令，一個動作），專案的成果幾乎不會因為「型式上敏捷」或是「嘴皮子上敏捷」而產生任何改善，只會變得更糟。

***

友藏內心獨白：嘴巴說敏捷，身體倒是挺誠實的嘛。