用 Waterfall 好, 還是 Agile 好嗎?
最近在討論專案的時程時, 有些討論很好玩.
有人提到用了 Waterfall 的方式, 就是範圍固定, product manager 就不能任意加功能. 並且整個工作就會比較快, 不會有打擾, 因此產品可以出的來.
若是用了 Agile, Product manager會認為可以任意加功能, 因此範圍就會不確定. 整個工作容易被打斷, 因為要應付改變; 也需要因為修改些 bug, 導致功能的實作無法專心進行.
有些人認為 Waterfall 還是可以做到 Agile 的效果. 只要我們可以訂出周期性的 milestones, 例如每兩周或是一周交付某些功能. 這樣範圍不會變動, 又可以及早看到一些成果.
個人認為 Agile 的好處是在及早給feedback來調整方向.
哪些feedback呢? 例如:
(1) 做的東西是否正確, 是否是客戶或是 Product manager要的. 每次的 iteration 完後, review meeting便有一個機會可以讓 Product manager 或是大家檢視. 若是真的不正確或是不足, 確實是有需要在下個 iteration 中修改.
當然前提是須要把 product backlog 的user stories, 依照優先順序排好, 也就是我們是最重要的東西先做. 因此若是之後因為這些修改, 導致後面不重要的項目沒辦法做完時, Product manager會需要有cut feature 的認知.
(2) 團隊或個人之間的整合, 是否能及早確認是否有問題, 是否有誤解. 因為只要是溝通, 就會有誤解. Agile 是一開始就透過 continuous integration + TDD, 一有修改變會早期發現, 要修改或是除錯的代價也不會很高.
用 Waterfall 定出周期性的 milestones, 是個不錯的調整. 可以及早看出做的東西是否是人家要的, 是否真的整合成功. 可是前提是要 milestones 的做完的定義要清楚. 也就是何謂 milestones 達成.
一般狀況是只要是開發人員把自己的部分做完, 就宣稱自己達到 milestone. 可是往往是和別人和別的團隊整合不起來; 或是一經執行下去, 根本是錯誤一大堆; 或是有可能這些東西的實用性不高, 但因 Waterfall時程不能變, 所以也沒修改的空間
另外是你如何確定有大家有遵從定義做完, 這件事情通常很難確認. 因為開發人員也沒做單元測試, 測試人員又無法在當下立刻檢查出所有狀況. 所以這設定好的目標, 便會形同虛設.
所以用 Waterfall 會比較快嗎? 是會很快做出一個東西. 但是做出來的是不是客戶想要, 是不是品質好的東西, 不知道!! 最後關頭一拍兩瞪眼, 成功就成功, 失敗就失敗.
留言列表
