什麼是敏捷軟體開發
敏捷開發(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)