軟體工程大家都知道是怎麼回事，百度百科的解釋是：軟體工程是一門研究用工程化方法構建和維護有效的、實用的和高質量的軟體的學科。它涉及程序設計語言、資料庫、軟體開發工具、系統平台、標準、設計模式等方面。為什麼會有軟體工程？是由於 60 年代，「軟體危機」的產生，當軟體的規模越來越大，複雜度不斷增加，軟體項目開發維護過程中的問題就逐步暴露出來：軟體產品質量低劣、軟體維護工作量大、成本不斷上升、進度不可控、程序人員無限度地增加。為了解決這些問題，軟體工程誕生了，目前最有代表性的兩種模式是瀑布模型和敏捷開發模型。

瀑布模型和敏捷開發模型各有優缺點，各自的適用場景不同，總的來說，瀑布模型適合需求比較明確，確定性因素比較多的的場景，敏捷開發恰恰相反。

在小公司裡面，適合使用哪種？坦率來講，小公司不確定因素太多了，業務不確定，有什麼業務就做什麼業務，能養活公司就行；用戶需求不確定，經常變更，讓你改，你就得改，而且要馬上改；公司員工也不確定，一人身兼多職，什麼都干，壓力大，待遇低，流動性大。咋眼一看，似乎，敏捷開發很適合，然而，如果前提條件不具備就匆忙上馬敏捷開發，結果會讓你大吃一驚，開發效率反而降低了，問題反而更多了，大家反而都更迷茫了，只好又走回原來的老路。

為什麼會這樣？原因就是實施敏捷開發有一個很重要的前提條件，人的素質要高，能夠自我驅動和自我管理。然而，小公司的高素質人才絕對不會很多，一個敏捷開發的小組都是這樣的人基本上不太可能，這也就意味著敏捷開發的一些理念無法落地，比如確定產品列表，如果PO(產品負責人)不強，這個環節就會出問題，需求描述不清，跟真實需求南轅北轍，項目開發還沒開始，就已經失敗了。又比如確定迭代開發列表，每個開發人員自己評估開發工作量，如果經驗不足，開發工作量評估不準確，為了趕進度，只能犧牲開發質量，後期測試發現bug不斷，不能按時發布，整個項目都不得不延期。又比如每日站會，本來是為了大家交流工作，更好的溝通，如果大家責任心都不夠，各人自掃門前雪，哪管他人瓦上霜，最後就變成了形式主義，應付差事，最後不了了之。

中國人的文化和小公司的現狀，決定了敏捷開發團隊裡面強調平等的原則是不能的，人人都強，才可能地位平等，你讓老虎跟羊平等相處，顯然是不可能，但是如果人人都是老虎，估計問題更大，誰都不服誰，時間都耗在內鬥上，項目估計也完蛋了。中國的開發團隊，必然是頭狼+一群狼，確定頭狼的地位，讓他去指揮狼群。

所以，要想在小公司推行敏捷開發，不能全盤照搬敏捷開發的東西，要做些修改，讓他能接地氣。比如推行里程碑評審+敏捷開發，在需求環節、設計環節、測試環節都加上評審，集中公司裡面的牛人當評委，小公司人再少，估計2,3個牛人還是能找出來的，否則這小公司估計也活不了多久。PO得兼項目經理，維護產品列表和項目計劃，負責產品規劃和項目管理，開發團隊得有一個開發負責人，負責評估任務工作量和任務分配，解決開發中碰到的技術難點。

這樣下來，開發過程基本上就比較順了，敏捷開發的一些關鍵點也能得到落地，比如說二個星期一個版本迭代，最強的應該能做到一個星期一個迭代，需求能夠快速迭代，質量也能夠保證，當然，如果公司沒幾個牛人，估計啥也幹不了，敏捷開發還是瀑布式開發就別折騰了 ，活下來再說。