敏捷開發大家談（二）

一、敏捷開發方法

（一） 說明
本文是閱讀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）

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/3433/viewspace-269187/，如需轉載，請註明出處，否則將追究法律責任。