unintended…

還記得大學時軟件工程課教的所謂「流水式開發」(waterfall development)，
一個軟件系統由需求收集，分析，到系統設計，編寫，最後到測試，
一步一步，循序漸進。
想當年學習的時候還覺得合情合理，
覺得凡事總有先後次序，
到出來工作才覺得大學教育，尤其是和IT有關的，
竟是如此脫節。

這種開發過程套用在舊有的系統還可以，
畢竟從前的軟件系統基於硬件的能力和數據量有限，
軟件設計比較著重算法(algorithm)和數據結構(data structure)，
以節省計算資源為主。
而且當時企業對系統整合(system integration)的需求也沒有現時那麼大，
軟件系統的開發相對比較獨立，
不必顧及企業內其他系統，變數較少。

為什麼會突然說起這種話題．．．
話說昨天跟一名客戶傾談，
討論一個為他們公司做的系統，
說到他在公司內部推動新系統的種種困難。
他的上一位上司堅持要用流水式開發，
開發一個新系統之前必須把公司上下有關職員的需求收集好，
再初步訂下系統設計，得到所有職員同意才進行編寫。
職員給出的需求不是太過天馬行空就是模稜兩可，
收集和分析也需時，一拖就是兩三個月，
到設計完成出來了，用戶一看，
根本不是他們想要的東西，
或是需求因為拖太久而變得過時了。

現在這位客戶堅持要以「迭代式開發」(iterative development)來管理軟件開發，
一開始盡量把收集到的需求分成較小的批量，
開發出一個個軟件原型(prototype)，
直接給用戶看。
用戶在看到實物下，
一來限制了用戶的思路，
不會給出太過不著邊際的需求，
二來也比較能給出快速和準確的意見，
進一步修改原型，直到雙方對原型有一定信心，
就拍板進行正式編寫，
過程中也一直進行「溝通，設計，編寫，再溝通．．」的循環。
出來的效果是開發週期更短，而成品更緊貼用戶需要。

好是好．．．不過話說回來，
給他們的prototype 已做到第4個修正了，
完成度對於一個prototype來說，
未免太高了吧。