實施敏捷的人, 相信都很討厭 waterfall. 而死守瀑布式開發的, 一定也覺得 agile 不好. 但事實上, 他們兩個根本是系出同門, 或者說瀑布式老祖他想的是要 agile 啊.
何解呢? 讓我們來看看瀑布式開發的發源文章吧:
NAGING THE DEVELOPMENT OF LARGE SOFTWARE SYSTEMS, Winston W. Royce, 1970
Winston W. Royce 雖然一開始說, 軟體開發應該有以下階段會比較好
但是, 講完這個圖後, 他立馬補一句:
I believe in this concept, but the implementation described above is risky and invites failure.
也就是說, 軟體開發是需要有這些階段. 但是實作時, 照上圖的流程來進行這階段, 那將會有很多風險, 並且會導致失敗.
Standish Group 在 1994 出的 Chaos Report 中, 也明白地指出這件事情: 軟體開發專案中, 16% 的比例是成功的, 31% 沒做完就被砍掉, 而 53% 的專案加人加錢才把它搞定. 所以瀑布式開發的做法真的不太靠譜.
Winston W. Royce 其實在文章還提到了, 為了降低上圖瀑布式模型所帶來的風險, 可以有以下做法
A. Program design comes first
B. Document the design
C. Do it twice
D. Plan, control and monitor testing
E. Involve the customer
各位如果想知道這五點, 是可以翻翻原文. 我們今天只想聊聊後面三點
C. Do it twice
Winston W. Royce 第一次做出的東西, 是不合適交付給客戶, 因為我們對他還不夠了解. 如果再做一次, 這個東西會比較合適給客戶. 下圖就是文章中這個想法的示意圖
大家會認為這樣成本不就是兩倍, 不是這樣的. Winston W. Royce 說第一次只是簡易版, 只是針對精華功能做, 所需時間不需要太多.
看個這裡, 各位不會覺得他就是 incremental and iterative 的前身概念嗎?
D. Plan, control and monitor testing
Winston W. Royce 認為最後才測試, 這是很危險的. 雖然他沒說該怎麼做, 但是他十分強調測試的重要性, 最好可以由 second party (第二方, 就是另一個人) 來檢查.
你看看, pair programming + TDD 不就剛好可以落實這樣的想法.
E. Involve the customer
Winston W. Royce 認為客戶應該要參與, 並且很深入和持續. 沒有客戶參與的開發團隊, 這個團隊是孤立的.
雖然 Winston W. Royce 沒有提出 on site customer 這樣的概念, 但是他認為在瀑布式模型中, 有三個地方可以請客戶來檢查, 開發團隊做的東西到底對不對. (也就是下圖中圓形圈圈的地方).
PSR: Preliminary Software Review (很像是需求 review)
CSR: Critical Software Review (很像是設計 review)
FSAR: Final Software Acceptance Review (很像是驗收測試)
能做到這三個階段的 review, 也是有 on site customer 的效果, 不是嗎?
看到這裡, 你是不是覺得這誤會大了, Winston W. Royce 的想法跟 agile 是很接近的, 他根本不認同瀑布式開發.
所以, 天底下根本不該有 waterfall, 當初信仰的 waterfall 根本是一場誤會啊 !!!
全站熱搜
留言列表
