戲說敏捷方法

　　敏捷(agile)方法現在非常Hot, 特別是Scrum, 在國內各個技術大會上都能見到其身影，許多公司也在考慮引入敏捷方法。 敏捷方法，的確給軟件研發帶來一陣清新的空氣，但一定要客觀地看待它。正如人們常說，軟件工程中沒有銀彈，沒有適合一切企業或開發模式的方法。上次在北京開會，有一個重量級專家就特別強調，團隊是主要的，方法是次要的，他所在的團隊很強，用什么辦法都可以成功。如果團隊差，寄希望于方法來解決問題，幾乎是不會獲得成功。只有好的團隊，采用適當的方法，才會獲得更大的成功。讓我們回到主題，如何看待敏捷方法呢?我下面盡量簡單地用通俗易懂的話來解釋，所以說得不對的地方，敏捷方法的粉絲也不要激動，因為本文的標題就是“戲說敏捷方法”，會故意夸張、有所片面，請不要太在意。當然，也是有一定的道理，值得大家思考。

　　敏捷方法并不是一種新的方法，而是快速原型方法的一種延伸，將原來適用于需求分析和設計的方法延伸到整個研發過程。

　　敏捷方法并不是一種新的方法，而是原來迭代方法(螺旋模型、增量模型、RUP)的變種，只是迭代周期更短。

　　敏捷方式是高科技人為自己偷懶而找的借口，這樣可以少寫文檔，或不寫文檔。

　　敏捷方式是高科技人為自由而尋找的一條鄉間小路，這樣可以減少公司對自己的約束。

　　敏捷方法是年輕的一代為了獲得更多的工作樂趣，將更多的游戲引入到研發之中。

　　沒有互聯網，就沒有敏捷方法生存的土壤。新的土壤需要新的種子——敏捷方法。

　　互聯網的許多應用需求不確定、變化迅速，互聯網的不少應用又是免費的，對質量的要求不是很高。這一切適合快速迭代，呼喚著一種更靈活的開發方法，那就是敏捷方法。

　　敏捷方法并沒有太大的創新，而只是一種改變。這種改變在某些領域是改善，這種改變在某些領域則是倒退。

　　敏捷方法則是將規范的、大規模的軟件開發再拉回到最初的“軟件小作坊”，是一種新的倒退。

　　小作坊的特征就是團隊小、天天可以見面、大家比較熟悉，主要靠口頭交流，采用工具也比較原始(白板、貼紙條等)，挺像敏捷方法的實踐。

　　小團隊以人治為主，法治為輔。大團隊以法治為主，人治為輔。敏捷方法適合小團隊，主要停留在人治的階段，但說得好聽點則是“以人為本”。

　　敏捷方法還是一種倒退，對角色定義越來越不夠明確，測試人員和開發人員的界限越來越模糊，而成熟的工業，角色細分，責任明確。

　　敏捷方法違反傳統的質量觀點“第一次就將事情做對”，而是打著擁抱變化的旗幟，想怎么做就怎么做，然后再不斷修改、重構。

　　代碼重構實際上就是償還自己欠下的技術債務。

　　敏捷方法是對工程學原理的叛逆。Matin Flower認為：“在敏捷開發過程中，人是第一位的，過程是第二位的。”而成熟的工程方法強調先過程，后個人，個人工作要服從于全局，受流程限制。

　　如果說傳統的軟件工程方法假設“人之初，性本惡”，則敏捷方法的管理假設就是“人之初，性本善”。

　　也有人說，傳統的軟件工程方法是“中藥”，見效慢，但效果持久，治本、重在預防;而敏捷方法是“西藥”，見效快，但只治標、不治本，長期有害。

　　敏捷開發模式需要經驗豐富、配合良好而又異常穩定的項目組、積極而富有成效的溝通、良好的管理手段和流程、有效的工具與平臺，只有滿足這些條件敏捷開發模式才能帶來收益。如果有了這些條件，用其它方法也能成功。

　　有了良好的框架，上面的展現就比較容易，敏捷方法才能敏捷起來。

原文轉自：http://www.anti-gravitydesign.com