敏捷方法

敏捷方法是一種從1990年代開始逐漸引起廣泛關注的一些新型軟體開發方法，是一種應對快速變化的需求的一種軟體開發能力。敏捷開發（agile development）是一種以人為核心、疊代、循序漸進的開發方法。

基本介紹

• 中文名：敏捷方法
• 開始時期：1990年代
• 原則：以人為核心、疊代、循序漸進
• 實際用：新型軟體開發方法

簡介

敏捷方法是一種從1990年代開始逐漸引起廣泛關注的一些新型軟體開發方法，是一種應對快速變化的需求的一種軟體開發能力。它們的具體名稱、理念、過程、術語都不盡相同，相對於“非敏捷”，更強調程式設計師團隊與業務專家之間的緊密協作、面對面的溝通（認為比書面的文檔更有效）、頻繁交付新的軟體版本、緊湊而自我組織型的團隊、能夠很好地適應需求變化的代碼編寫和團隊組織方法，也更注重軟體開發中人的作用。

敏捷開發

敏捷開發（agile development）是一種以人為核心、疊代、循序漸進的開發方法。在敏捷開發中，軟體項目的構建被切分成多個子項目，各個子項目的成果都經過測試，具備集成和可運行的特徵。簡言之，就是把一個大項目分為多個相互聯繫，但也可獨立運行的小項目，並分別完成，在此過程中軟體一直處於可使用狀態。

敏捷開發是全新理論嗎？答案莫衷一是。細心的人們可以發現，敏捷開發其實借鑑了大量軟體工程中的方法。疊代與增量開發，這兩種在任何一本軟體工程教材中都會被提到的方法，在敏捷開發模式中扮演了很重要的角色。再向前追溯，我們還也可見到瀑布式與快速原型法的影子，也許還有更多。

改善，而非創新。敏捷開發可理解為在原有軟體開發方法基礎上的整合——取其精華，去其糟粕。因此敏捷開發繼承了不少原有方法的優勢。“在敏捷軟體開發的過程中，我們每兩周都會得到一個可以工作的軟體，”Fowler介紹，“這種非常短的循環，使終端客戶可以及時、快速地看到他們花錢構建的軟體是一個什麼樣的結果。”

也許是因為時間關係，Fowler只說出了這些優勢中的一部分。允許開發過程中的需求變化、通過早期疊代可以較早發現風險、使代碼重用變得可行、減少項目返工……借鑑了眾多先進方法和豐富經驗，擁有的眾多優勢使得敏捷開發看來已經成為解決軟體危機的標準答案。

問題與思考
然而，我們不得不面對的現實卻是，模式與方法的最佳化並不意味著問題的終結。作為一種開發模式，敏捷開發同樣需要面對眾多挑戰。

大項目的拆分意味著更多子項目的出現，協調這些同步或異步推進的子項目，合理的資源調配都將變得更加複雜。另外，在當前項目和項目組普遍“增容”的情況下，遇到的問題同樣成倍增長。人的重要性被提到了更高的高度，而缺乏有效協調手段，減少人員流動和項目變更對整個項目造成的影響也將成為一大挑戰……新方法帶來眾多便利的同時，也相應引發了幾乎同樣多的問題。

敏捷開發（agile development）概念從2004年初開始廣為流行。Bailar非常支持這一理論，他採取了"敏捷方式"組建團隊：Capital One的"敏捷團隊"包括3名業務人員、兩名操作人員和5～7名IT人員，其中包括1個業務信息指導（實際上是業務部門和IT部門之間的"翻譯者"）；另外，還有一個由項目經理和至少80名開發人員組成的團隊。這些開發人員都曾被Bailar送去參加過"敏捷開發"的培訓，具備相關的技能。

每個團隊都有自己的敏捷指導（Bailar聘用了20個敏捷指導），他的工作是關注流程並提供建議和支持。最初提出的需求被歸納成一個目標、一堆記錄詳細需要的卡片及一些供參考的原型和模板。在整個項目階段，團隊人員密切合作，開發有規律地停頓--在9周開發過程中停頓3～4次，以評估過程及決定需求變更是否必要。在Capital One，大的IT項目會被拆分成多個子項目，安排給各"敏捷團隊"，這種方式在"敏捷開發"中叫"蜂巢式（swarming）"，所有過程由一名項目經理控制。

為了檢驗這個系統的效果，Bailar將項目拆分，從舊的"瀑布式"開發轉變為"並列式"開發，形成了"敏捷開發"所倡導的精幹而靈活的開發團隊，並將開發階段分成30天一個周期，進行"衝刺"--每個衝刺始於一個啟動會議，到下個衝刺前結束。

在Bailar將其與傳統的開發方式做了對比後，他感到非常興奮--"敏捷開發"使開發時間減少了30%～40%，有時甚至接近50%，提高了交付產品的質量。"不過，有些需求不能用敏捷開發來處理。" Bailar承認，"敏捷開發"也有局限性，比如對那些不明確、優先權不清楚的需求或處於"較快、較便宜、較優"的三角架構中卻不能排列出三者優先權的需求。此外，他覺得大型項目或有特殊規則的需求的項目，更適宜採用傳統的開發方式。儘管描述需求一直是件困難的事，但經過陣痛之後，需求處理流程會讓CIO受益匪淺。

敏捷開發是由一些業界專家針對一些企業現狀提出了一些讓軟體開發團隊具有快速工作、回響變化能力的價值觀和原則，並於2001初成立了敏捷聯盟。他們正在通過親身實踐以及幫助他人實踐，揭示更好的軟體開發方法。通過這項工作，他們認為：

• 個體和互動 勝過 過程和工具
• 可以工作的軟體 勝過 面面俱到的文檔
• 客戶合作 勝過 契約談判
• 回響變化 勝過 遵循計畫

並提出了以下遵循的原則：

• 我們最優先要做的是通過儘早的、持續的交付有價值的軟體來使客戶滿意。
• 即使到了開發的後期，也歡迎改變需求。敏捷過程利用變化來為客戶創造競爭優勢。
• 經常性地交付可以工作的軟體，交付的間隔可以從幾個星期到幾個月，交付的時間間隔越短越好。
• 在整個項目開發期間，業務人員和開發人員必須天天都在一起工作。
• 圍繞被激勵起來的個體來構建項目。給他們提供所需的環境和支持，並且信任他們能夠完成工作。
• 在團隊內部，最具有效果並富有效率的傳遞信息的方法，就是面對面的交談。
• 工作的軟體是首要的進度度量標準。
• 敏捷過程提倡可持續的開發速度。責任人、開發者和用戶應該能夠保持一個長期的、恆定的開發速度。
• 不斷地關注優秀的技能和好的設計會增強敏捷能力。
• 簡單是最根本的。
• 最好的構架、需求和設計出於自組織團隊。

每隔一定時間，團隊會在如何才能更有效地工作方面進行反省，然後相應地對自己的行為進行調整。

一、敏捷開發方法

（一） 說明
本文是閱讀Alistair Cockburn的Agile Software Development和William C. Wake的XP Explored的一些筆記和想法，Agile Software Development是一組軟體開發方法的總稱，包括（Crystal , Extreme Programming , Adaptive software development等等）。敏捷開發方法又稱為“輕量級”開發方法。

下面這段話摘自Martin Fowler的一篇文章：

從無到繁重再到敏捷
多數軟體開發仍然是一個顯得混亂的活動，即典型的“邊寫邊改” （code and fix）。設計過程充斥著短期的，即時的決定，而無完整的規劃。這種模式對小系統開發其實很管用，但是當系統變得越大越複雜時，要想加入新的功能就越來越困難。同時錯誤故障越來越多，越來越難於排除。一個典型的標誌就是當系統功能完成後有一個很長的測試階段，有時甚至有遙遙無期之感，從而對項目的完成產生嚴重的影響。
我們使用這種開發模式已有很長時間了，不過我們實際上也有另外一種選擇，那就是“正規方法”（methodology）。這些方法對開發過程有著嚴格而詳盡的規定，以期使軟體開發更有可預設性並提高效率，這種思路是借鑑了其他工程領域的實踐。
這些正規方法已存在了很長時間了，但是並沒有取得令人矚目的成功，甚至就沒怎么引起人們的注意。對這些方法最常聽見的批評就是它們的官僚繁瑣，要是按照它的要求來，那有做太多的事情需要做，而延緩整個開發進程。所以它們通常被認為是“繁瑣滯重型”方法，或Jim HighSmith 所稱的“巨型”（monumental)方法。
作為對這些方法的反叛，在過去幾年中出現了一類新方法。儘管它們還沒有正式的名稱，但是一般被稱為“敏捷型”方法。對許多人來說，這類方法的吸引之處在於對繁文縟節的官僚過程的反叛。它們在無過程和過於繁瑣的過程中達到了一種平衡，使得能以不多的步驟過程獲取較滿意的結果。
敏捷型與滯重型方法有一些顯著的區別。其中一個顯而易見的不同反映在文檔上。敏捷型不是很面向文檔，對於一項任務，它們通常只要求儘可能少的文檔。從許多方面來看，它們更象是“面向源碼”（code-oriented）。事實上，它們認為最根本的文檔應該是源碼。
但是，我並不以為文檔方面的特點是敏捷型方法的根本之點。文檔減少僅僅是個表象，它其實反映的是更深層的特點：
? 敏捷型方法是“適配性”而非“預設性”。 重型方法試圖對一個軟體開發項目在很長的時間跨度內作出詳細的計畫，然後依計畫進行開發。這類方法在計畫制定完成後拒絕變化。而敏捷型方法則歡迎變化。其實，它們的目的就是成為適應變化的過程，甚至能允許改變自身來適應變化。
? 敏捷型方法是“面向人”的(people-oriented) 而非“面向過程”的 (process-oriented)。 它們試圖使軟體開發工作順應人的天性而非逆之。它們強調軟體開發應當是一項愉快的活動。
我認為以上兩個特點很好的概括了敏捷開發方法的核心思想：適應變化和以人為中心

（二） 方法背後的思想

Alistair Cockburn在Agile Software Development中講述了敏捷開發方法背後的思想

人們掌握過程（process）可以分為3個階段：
1 following 遵循一個定義好的process
2 detaching 知道不同process的適用範圍，在不同的場合使用不同的process
3 fluent 不關心是否遵循特定的process，知道在什麼情況下採用什麼動作

軟體開發是一個充滿發明和交流的協作性遊戲(cooperative game of invertion and communication)。軟體開發的首要目標是生產出軟體，遵循特定的過程和模型只是手段，只要傳遞了足夠的信息，手段是次要的。交流的效果要遠遠重於交流的形式（Effect of communication is more important than the form of communication）。
一般軟體開發有兩個目標：1 儘快的生產出軟體2 為下一個team或項目做準備，有時這兩個目標是矛盾的，我們要在這兩個目標之間尋求平衡

在軟體開發中，人的因素要遠遠大於過程和技術。人是有缺陷的：
1 容易犯錯誤，因此必須在錯誤擴散之前找到並改正錯誤
2 當覺得可能失去較多的時候，不願意冒險
3 重新構造而不願意重複使用已有的東西
4 難於堅持一個習慣

針對個人因素的幾個建議：
1 具體的模型較抽象的模型更容易理解
2 從一個例子開始是容易的
3 通過觀察他人的成果學習
4 要有足夠的不受打擾的時間
5 分配的工作要與個人意向，能力匹配
6 不正確的獎勵會有壞作用，從長期看個人興趣比獎勵更重要，培養在工作中的自豪感：
1) pride in work參與工作的自豪感，通常參與一個重要的工作會有自豪感
2) pride in accomplishment 完成工作的自豪感，長期未完的工作會使士氣低落
3)pride in contribution 為他人貢獻的自豪感
7 鼓勵關心其他人的工作和整體的工作

在一個團隊之間，交流是最重要的，實踐證明面對面的實時的交流是最有效的，對交流的延誤會損失信息，白板是最好的交流工具，交流工具的先進並不能提高交流效果。文檔的作用是記錄和備忘，不能通過文檔交流。

敏捷開發方法要避免的過程設計的幾個常見錯誤
1 對所有的項目使用同一種過程
2 沒有彈性
3 過於沉重
4 增加不必要的“必須完成”（“should do” is really should？）
5 沒有經過實踐檢驗

敏捷開發方法過程設計的幾個原理：
1 互動的面對面的交流是代價最小，最迅速的交換信息的方法
2 超過實際需要的過程是浪費的
3 大的團隊需要重量級方法
4 處理重大問題的項目需要重量級方法強調
5 增加反饋和交流可以減少中間產品和文檔的需求
6 輕量級方法更強調理解（understanding）,自律（discipline）和技能(skill)，重量級方法更強調文檔（documentation），過程（process）和正式（formality）
understanding指整個團隊關於項目的全部知識，包括討論的過程，documentation只能記錄其中的一部分
discipline是指個人主動的完成工作，process指個人根據指令完成工作
skill指具有良好技能的人可以省略中間的產品，formality指必須按照規定步驟完成工作

7 確定開發中間的瓶徑，提高它的效率
對於瓶徑處的工作應該儘量加快，減少重複，（使用更熟練的人，使用更多的人，使用更好的工具，使瓶徑處的工作的深入儘量穩定）對於非瓶徑處的工作可以多一些重複，在輸入還不確定的情況下也可以儘早開始。

這些原理的幾個結論：
1 向一個項目增加人員要花費較大代價（constly），因為原有人員和新人員之間的交流要花費大量時間
2 團隊的規模經常是跳躍的，例子：需要6個熟練的程式設計師，但是只有4個，於是增加不熟練的程式設計師，結果團隊的大量時間花費在培訓不熟練的程式設計師上面，最後增加到了20個不熟練的程式設計師。
3 應該側重於提高團隊的技能而不是擴充團隊
4 對不同的項目使用不同的過程
5 在適用的條件下，輕量級的方法優於重量級的方法
6 對不同的項目要裁減過程

敏捷開發方法的原則是“剛剛好”（Light and Sufficient）

敏捷開發重點

敏捷宣言四個價值中的兩個都強調的敏捷方法對協作有重要性。“整個流程和工具中涉及到的人和互動”提醒著我們相到尊重的交流的重要性。例如，與其 讓測試和開發人員使用缺陷跟蹤工具來記錄bug，還不如鼓勵他們坐下來，一起使用重要創建並解決問題。“根據契約指示的客戶協作”提醒我們開發團隊給予的靈活性更重要，更能令客戶滿意，找到協作解決方案來解決產品開發中可能會出現的問題，遠遠比只是固守著嚴格的契約好的多。

雖然協作並不是局限在使用敏捷方法團隊的中，但與控制命令型企業文化相比，敏捷開發實踐可以通過培養交流的企業文化幫助企業更好地發展。敏捷心態與交流文化中的價值實踐類似——鼓勵共享驅動決策，自我管理跨功能團隊和服務型領導。

敏捷開發安全性

在敏捷產品開發中，提高安全性的一些建議如下：

• 時刻關注安全性完成的定義（DoD）。
• 用驗收標準來驗證滿足了安全性需求。
• 在產品評審過程中，請利益相關者攻擊產品安全性。
• 用回顧反省的方法調整你的安全策略。
• 群聚解決安全問題。