我們不採用瀑布模型，除了本身不是多版本交付的特點，我們把更多原因歸於當需求設計結束後，開發中變更的需求不能及時地更新到設計文檔中，程序包與設計文檔不匹配，文檔眾多煩瑣。於是我們把文檔過程簡化掉。筆者不認為以上是我們採用敏捷的根本原因（敏捷確實根據不同的團隊有更高的效率，但以上並不是我們選擇敏捷的緣由），因為我們經歷過非常成功的瀑布模型。
我們採用敏捷的時候，多半有一個共性的特點，項目以客戶為導向，需要在最短時間內在市場上得到反饋或客戶的演示使用，團隊人員較少。有人會說Google也在敏捷呀！這顯然是一個大團隊呀！其實就好像企業通過CMMI5的評定一樣，最初，東軟也只是一個汽車音響事業部去通過了這個認證，而不是整個東軟，Google也是一樣，其中分為很多項目組和產品團隊，而有個最有趣的問題出現了，大家都知道當採用敏捷時，既然目標是最快地進行產品演示和發佈，用很多手段去壓縮開發週期，那麼質量一定會相應地有所下降（除非你做得足夠好，否則質量和時間多半是成正比的），但我們的產品類型通常允許我們質量略有問題，因為我們有個版本叫Beta版。也許這也是為什麼Google的產品中有45%的產品常年是Beta版的原因，因為後續他們某些團隊中幾乎省略了驗收測試的環節（其實如果你的其他環節做得足夠好，這確實能稍有壓縮）。
如果你的項目或者產品是摩天大樓和火箭發射（除了研發新的內容），你一定不會減少這些環節，更不會用Beta版來發布，因為我們經不起任何誤差和Bug性的失敗。有個例子，M國為賣出的導彈做驗收性演示，一個士兵在批量性導彈中隨機選擇一枚發射，成功即可，你會說用什麼來保證質量？答案是他們用了近10年的時間做測試，顯然，這真沒法敏捷。
所以並非所有的企業都適合敏捷，根據企業類型、項目情況、團隊情況綜合判定採用哪種開發模型更為合適。
總結：
● 不完善需求說明書，是我們的錯誤理解，並不是敏捷方法的缺點。
● 簡化需求過程，是否統計過後期的返工、補充給我們帶來的損失。
● 互聯網產品特點，個人用戶為單位，創新多於行業基準，視覺大於操作性，對雛形操作性要求高。
● 行業軟件開發，要吸收敏捷中適合自己的內容，而不是拿來主義。
閱讀更多 鄧鋤頭挖科技 的文章
