詩特林-sterning

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

一、前言

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

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

二、變味的敏捷

敏捷是大家在一起高效率地工作，清楚所有溝通上的障礙，關注于增值的活動，從而使得開發更加成功。敏捷是大家肩并肩地工作，而不是什么都通過文檔。敏捷是管理者積極地參加到項目管理中而不是整天去寫狀況報告，用那個來監督到底發生了什么事情。敏捷是開發人員和涉眾（項目開發中涉及的從需求到最后交付的各種人員）在一起制定實際的計劃，而不是用復雜的微軟Project去制定一些幾乎沒人看的進度表。

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

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

另外關于實施敏捷的效果也是充滿置疑之聲。我們經常看到一些號稱 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在他的《敏捷項目管理》一書中這樣寫道：敏捷是指在動蕩的業務環境中，適應變化并創造變化，從而獲得價值的一種能力。同時敏捷是平衡靈活性和穩定性的一種能力。由此可見，望文生義地把“敏捷”理解為“做得快”也頗可商榷。如果缺乏有效的實施指導、忽視嚴格的敏捷實踐，單憑著高層面的理解甚至“文化”就開始盲目前行，往往會因為缺乏對質量的有力保障而失去平衡，最終欲速則不達。

套用一句比較俗氣的話，敏捷不是放諸四海而皆準的通用理論；敏捷不是玄而又玄的文化；敏捷不是在傳統項目合作模式下包治百病的金丹；敏捷不是拋開紀律盲目求快。除了這些，敏捷還不是什么？那么，今天你真的“敏捷”了嗎？