轉載：https://yq.aliyun.com/articles/130605

敏捷開發（Agile Development） 隨著“敏捷”一詞出現在越來越多的專案中，於是，敏捷開發本身也被賦與了越來越多的意義，而敏捷的真正內涵反而變得越來越模糊。如何邁出敏捷開發第一步？是按照敏捷寶典、操作指南或是教父語錄，還是因地制宜、因專案定方法？完成所有這些工作後，我們就真的“敏捷”了嗎？

　　一、前言

　　Agile是指企業能夠對外部環境做出速捷、有效的反應，是未來企業的必備素質。21世紀企業面臨的競爭環境將是一個不斷變化、不可預測的環境。由於高新技術的出現和更迭越來越快，產品的生命週期日益縮短，企業要面對這樣的新的競爭環境，抓住市場機遇，迅速開發出使用者所需要的產品，就必須實現敏捷反應。

　　狹義地講，敏捷企業就是將柔性的先進製造技術、熟練掌握生產技能、有知識的勞動力以及促進企業內部和企業之間的靈活管理三者整合在一起，對千變萬化的市場機會做出快速、有效的響應。敏捷企業強調人、組織和技術的有機結合。通過這三者的緊密結合，敏捷企業可以發揮最佳的整體效益。評價一個企業敏捷性的具體指標是時間、成本、穩健性（Robustness）和適應範圍。對敏捷企業的廣義理解，可以認為敏捷企業是一個CIMS（計算機整合制造系統）、動態聯盟、並行工程、模擬製造、高素質員工等多方面的系統整合，是一個基於CIMS、在CMS基礎上發展起來的一個更高層次的整合大系統。

　　二、變味的敏捷

　　敏捷是大家在一起高效率地工作，清除所有溝通上的障礙，關注於增值的活動，從而使得開發更加成功。敏捷是大家肩並肩地工作，而不是什麼都通過文件。敏捷是管理者積極地參加到

　　公平地說，很難設想敏捷術能如何發揮作用，尤其是在一些軟體開發本身都問題重重的傳統組織中，被誤導過的敏捷更是難以幫上什麼忙。

　　敏捷開發，看到過這個詞時，很多人一直沒有什麼深刻的體會，也沒有仔細去研究到底什麼才是敏捷開發。而一直在很多人的思想裡，敏捷開發的印象就是，開發速度比較快。沒錯，做網際網路的，快確實是一個制勝的法寶，那麼敏捷開發似乎也就是在網際網路應用的開發中最適合的方法了。那麼敏捷開發中的參與者應該是什麼狀態？這似乎成了一直以來困擾很多管理者的嚴重問題。可以說，在敏捷開發中，並沒有覺得有多敏捷，進度一拖再拖，問題一個接著一個，讓我覺得我們是在進行慌亂開發。為什麼會這樣？

　　另外，關於實施敏捷的效果也是充滿置疑之聲。我們經常看到一些號稱Agile的國內專案，按照菜譜、操作指南和教父語錄的提示，採用了許多花哨的技巧和實踐（做法），是啊，表面上確實Agile了，那麼結果呢？專案還是不能按時完成，甚至嚴重超支和超時，這能叫“敏捷”嗎？

　　三、敏捷十戒

　　1、天報制度

　　就算是進行遠端開發或是兩地使用開發，專案組的成員每天至少碰一次，不管是當面的，還是通過其它方式，如通過電話、email、Skype或其它。進行敏捷開發的時間，任何團隊都不能以任何理由進行孤立的開發。

　　2、例會制度

　　即使每天通過Email給主管彙報工作，但有時主管還是無法及時準確的掌握專案組成員的狀況及工作量。此時，通過每週一小時左右的例會將會有效的解決此問題。通過例會，大家面對面的就某些問題進行共同的探討與討論，找到共同的解決方案。

　　3、版本控制

　　如果沒有一臺乾淨的電腦來進行團隊程式碼管理的話，則很有可能導致程式碼的混亂。而每天只須花很少的時間，哪怕一天一次，進行及時的資料提交與程式碼提交，則可以有效的保證團隊之前程式碼的同步及程式碼的備份。

　　4、需求失靈

　　即使手裡拿著30頁且客戶進行了簽字的需求說明，有可能仍然不知所措。相對起那些良好的設計、精確的分析等，與客戶持續的溝通、及時的反饋、不斷的演示這些工作顯得更加的有效果。可以有效的獲得需求變化，減少誤解，更加準確的把握使用者的需求。

5、單元測試是QA的工作

　　很多開發人員，甚至一些高階的軟體開發人員，對於單元測試沒有足夠的認識，在行動上也沒有足夠的注意。大家都一致的認為那是QA的事情。就開發人員來講，單元測試應該是一種白箱測試，能從功能上充分的測試軟體的功能性。而對QA來說，只能是一種黑箱測試，無法深入的去分析程式碼的優勢，只是從使用者的角度進行功能上的測試而已。

　　6、質量保證是QA的責任

　　自從有了質量管理這個詞以及後來產生的質量管理部門後，很多開發人員就理所當然的認為質量保證是QA的責任了。其實每一個人都需要對軟體的質量負責，特別是開發人員。Bug越最早發現，那麼解決它的成本就越低。

　　7、專案進度風險控制

　　也許一個專案需要18個月左右才能完成，但在沒完成之前，誰也無法進行比較準確的時間估計。無法確定需要多長的時間進行設計、編碼及軟體元件的組合。但進行專案設計、實現及融合的人應該相對比較準確的掌握與估計專案的時間。因此，需要進行專案進度的風險控制，風險總是存在的，但要進行有力與及時的控制。充分意識到專案中可能會存在的風險因素，在制定計劃時預留一定的時間，如果在專案進行中出現了沒有想到的問題，根據其重要性，考慮壓後解決，要在計劃的時間內把計劃的事情完成好，併為後續解決問題爭取更多的時間。

　　8、架構師身體力行

　　很多軟體架構師基本上不寫程式碼，這也許是好事。軟體架構師嘛，當然是比較高階的，他們對環境、語言、類庫方面都可能比軟體開發人員要更加在行，但他們一般不編碼。這樣的架構師是危險的，特別是那些基本上不與首席開發人員進行溝通或諮詢的架構師，離專案失敗可能已經不遠了。

　　9、牽一髮而動全身

　　很多時間，在功能上做了一個很小的變動，往往導致花費好幾天的功夫來進行軟體的整合與整合。如果沒有持續的整合、及時的迴歸測試、可靠的整體設計，一些看起來非常微小的修改都有可能導致很大的麻煩。

　　10、加大管理執行力

　　目前專案中，開發者或者說參與人的狀態是混亂的，或者說是慌亂的。那問題在哪裡呢？是工作流程出了問題？不應該啊！在專案啟動前已經定了一個看似美好的流程，而且是經過參與人討論一致通過的。那麼問題在哪裡呢？原來是溝通、傳達出了問題，執行力不夠。那麼，就必須加大執行力，今日事今日畢，這是必須的。

　　另外，在一些產品級的軟體開發中，覺得要實施敏捷式開發，我覺得也有一個不好解決的問題：沒有具體的客戶！沒有具體的客戶，那你的溝通去哪裡尋找呢？一般的做法也是給一些有興趣的使用者釋出Alpha版本，或者是beta版本的軟體。可是當軟體都到了Alpha/beta版本的時候，軟體還有迭代的餘地嗎？未必！從我個人理解的角度來看，敏捷開發的適用範圍還是很有侷限性的。個人認為最適合使用敏捷開發的軟體必須要有非常明確的客戶才能進行，而有明確客戶的情況以定製型軟體為主。所以，我覺得最適合用敏捷方式開發的軟體應該是——定製軟體！

　　四、小結

　　記得Jim Highsmith在他的《敏捷專案管理》一書中這樣寫道：敏捷是指在動盪的業務環境中，適應變化並創造變化，從而獲得價值的一種能力。同時敏捷是平衡靈活性和穩定性的一種能力。由此可見，望文生義地把“敏捷”理解為“做得快”也頗可商榷。如果缺乏有效的實施指導、忽視嚴格的敏捷實踐，單憑著高層面的理解甚至“文化”就開始盲目前行，往往會因為缺乏對質量的有力保障而失去平衡，最終欲速則不達。