敏捷（agile）方法現在非常Hot, 特別是Scrum, 在國內各個技術大會上都能見到其身影，許多公司也在考慮引入敏捷方法。 敏捷方法，的確給軟體研髮帶來一陣清新的空氣，但一定要客觀地看待它。正如人們常說，軟體工程中沒有銀彈，沒有適合一切企業或開發模式的方法。上次在北京開會，有一個重量級專家就特彆強調，團隊是主要的，方法是次要的，他所在的團隊很強，用什麼辦法都可以成功。如果團隊差，寄希望於方法來解決問題，幾乎是不會獲得成功。只有好的團隊，採用適當的方法，才會獲得更大的成功。讓我們回到主題，如何看待敏捷方法呢？我下面盡量簡單地用通俗易懂的話來解釋，所以說得不對的地方，敏捷方法的粉絲也不要激動，因為本文的標題就是“戲說敏捷方法”，會故意誇張、有所片面，請不要太在意。當然，也是有一定的道理，值得大家思考。
- 敏捷方法並不是一種新的方法，而是快速原型方法的一種延伸，將原來適用於需求分析和設計的方法延伸到整個研發過程。
- 敏捷方法並不是一種新的方法，而是原來迭代方法（螺旋模型、增量模型、RUP）的變種，只是迭代周期更短。
- 敏捷方式是高科技人為自己偷懶而找的借口，這樣可以少寫文檔，或不寫文檔。
- 敏捷方式是高科技人為自由而尋找的一條鄉間小路，這樣可以減少公司對自己的約束。
- 敏捷方法是年輕的一代為了獲得更多的工作樂趣，將更多的遊戲引入到研發之中。
- 沒有互連網，就沒有敏捷方法生存的土壤。新的土壤需要新的種子——敏捷方法。
- 互連網的許多應用需求不確定、變化迅速，互連網的不少應用又是免費的，對品質的要求不是很高。這一切適合快速迭代，呼喚著一種更靈活的開發方法，那就是敏捷方法。
- 敏捷方法並沒有太大的創新，而只是一種改變。這種改變在某些領域是改善，這種改變在某些領域則是倒退。
- 敏捷方法則是將規範的、大規模的軟體開發再拉回到最初的“軟體小作坊”，是一種新的倒退。
- 小作坊的特徵就是團隊小、天天可以見面、大家比較熟悉，主要靠口頭交流，採用工具也比較原始（白板、貼紙條等），挺像敏捷方法的實踐。
- 小團隊以人治為主，法治為輔。大團隊以法治為主，人治為輔。敏捷方法適合小團隊，主要停留在人治的階段，但說得好聽點則是“以人為本”。
- 敏捷方法還是一種倒退，對角色定義越來越不夠明確，測試人員和開發人員的界限越來越模糊，而成熟的工業，角色細分，責任明確。
- 敏捷方法違反傳統的品質觀點“第一次就將事情做對”，而是打著擁抱變化的旗幟，想怎麼做就怎麼做，然後再不斷修改、重構。
- 代碼重構實際上就是償還自己欠下的技術債務。
- 敏捷方法是對工程學原理的叛逆。Matin Flower認為：“在敏捷開發過程中，人是第一位的，過程是第二位的。”而成熟的工程方法強調先過程，後個人，個人工作要服從於全域，受流程限制。
- 如果說傳統的軟體工程方法假設“人之初，性本惡”，則敏捷方法的管理假設就是“人之初，性本善”。
- 也有人說，傳統的軟體工程方法是“中藥”，見效慢，但效果持久，治本、重在預防；而敏捷方法是“西藥”，見效快，但只治標、不治本，長期有害。
- 敏捷開發模式需要經驗豐富、配合良好而又異常穩定的項目組、積極而富有成效的溝通、良好的管理手段和流程、有效工具與平台，只有滿足這些條件敏捷開發模式才能帶來收益。如果有了這些條件，用其它方法也能成功。
- 有了良好的架構，上面的展現就比較容易，敏捷方法才能敏捷起來。
關聯部落格：
敏捷方法中測試人員的價值?
上善若水——專案管理的真諦
軟體開發不是一門藝術什麼是軟體工程？先進、成熟的軟體工程思想有哪些？
