敏捷開發(fā)（agile development）概念從2004年初開始廣為流行。Bailar非常支持這一理論，他采取了"敏捷方式"組建團(tuán)隊：Capital One的"敏捷團(tuán)隊"包括3名業(yè)務(wù)人員、兩名操作人員和5～7名IT人員，其中包括1個業(yè)務(wù)信息指導(dǎo)（實際上是業(yè)務(wù)部門和IT部門之間的"翻譯者"）；另外，還有一個由項目經(jīng)理和至少80名開發(fā)人員組成的團(tuán)隊。這些開發(fā)人員都曾被Bailar送去參加過"敏捷開發(fā)"的培訓(xùn)，具備相關(guān)的技能。
每個團(tuán)隊都有自己的敏捷指導(dǎo)（Bailar聘用了20個敏捷指導(dǎo)），他的工作是關(guān)注流程并提供建議和支持。最初提出的需求被歸納成一個目標(biāo)、一堆記錄詳細(xì)需要的卡片及一些供參考的原型和模板。在整個項目階段，團(tuán)隊人員密切合作，開發(fā)有規(guī)律地停頓--在9周開發(fā)過程中停頓3～4次，以評估過程及決定需求變更是否必要。在Capital One，大的IT項目會被拆分成多個子項目，安排給各"敏捷團(tuán)隊"，這種方式在"敏捷開發(fā)"中叫"蜂巢式（swarming）"，所有過程由一名項目經(jīng)理控制。
為了檢驗這個系統(tǒng)的效果，Bailar將項目拆分，從舊的"瀑布式"開發(fā)轉(zhuǎn)變?yōu)?并列式"開發(fā)，形成了"敏捷開發(fā)"所倡導(dǎo)的精干而靈活的開發(fā)團(tuán)隊，并將開發(fā)階段分成30天一個周期，進(jìn)行"沖刺"--每個沖刺始于一個啟動會議，到下個沖刺前結(jié)束。
在Bailar將其與傳統(tǒng)的開發(fā)方式做了對比后，他感到非常興奮--"敏捷開發(fā)"使開發(fā)時間減少了30%～40%，有時甚至接近50%，提高了交付產(chǎn)品的質(zhì)量。"不過，有些需求不能用敏捷開發(fā)來處理。" Bailar承認(rèn)，"敏捷開發(fā)"也有局限性，比如對那些不明確、優(yōu)先權(quán)不清楚的需求或處于"較快、較便宜、較優(yōu)"的三角架構(gòu)中卻不能排列出三者優(yōu)先級的需求。此外，他覺得大型項目或有特殊規(guī)則的需求的項目，更適宜采用傳統(tǒng)的開發(fā)方式。盡管描述需求一直是件困難的事，但經(jīng)過陣痛之后，需求處理流程會讓CIO受益匪淺。
敏捷開發(fā)是由一些業(yè)界專家針對一些企業(yè)現(xiàn)狀提出了一些讓軟件開發(fā)團(tuán)隊具有快速工作、響應(yīng)變化能力的價值觀和原則，并于2001初成立了敏捷聯(lián)盟。他們正在通過親身實踐以及幫助他人實踐，揭示更好的軟件開發(fā)方法。通過這項工作，他們認(rèn)為：
- 個體和交互 勝過 過程和工具
- 可以工作的軟件 勝過 面面俱到的文檔
- 客戶合作 勝過 合同談判
- 響應(yīng)變化 勝過 遵循計劃
并提出了以下遵循的原則：
- 我們最優(yōu)先要做的是通過盡早的、持續(xù)的交付有價值的軟件來使客戶滿意。
- 即使到了開發(fā)的后期，也歡迎改變需求。敏捷過程利用變化來為客戶創(chuàng)造競爭優(yōu)勢。
- 經(jīng)常性地交付可以工作的軟件，交付的間隔可以從幾個星期到幾個月，交付的時間間隔越短越好。
- 在整個項目開發(fā)期間，業(yè)務(wù)人員和開發(fā)人員必須天天都在一起工作。
- 圍繞被激勵起來的個體來構(gòu)建項目。給他們提供所需的環(huán)境和支持，并且信任他們能夠完成工作。
- 在團(tuán)隊內(nèi)部，最具有效果并富有效率的傳遞信息的方法，就是面對面的交談。
- 工作的軟件是首要的進(jìn)度度量標(biāo)準(zhǔn)。
- 敏捷過程提倡可持續(xù)的開發(fā)速度。責(zé)任人、開發(fā)者和用戶應(yīng)該能夠保持一個長期的、恒定的開發(fā)速度。
- 不斷地關(guān)注優(yōu)秀的技能和好的設(shè)計會增強(qiáng)敏捷能力。
- 簡單是最根本的。
- 最好的構(gòu)架、需求和設(shè)計出于自組織團(tuán)隊。
- 每隔一定時間，團(tuán)隊會在如何才能更有效地工作方面進(jìn)行反省，然后相應(yīng)地對自己的行為進(jìn)行調(diào)整。
一、敏捷開發(fā)方法
（一） 說明
本文是閱讀Alistair Cockburn的Agile Software Development和William C. Wake的XP Explored的一些筆記和想法，Agile Software Development是一組軟件開發(fā)方法的總稱，包括（Crystal , Extreme Programming , Adaptive software development等等）。敏捷開發(fā)方法又稱為“輕量級”開發(fā)方法。
下面這段話摘自Martin Fowler的一篇文章：
從無到繁重再到敏捷
多數(shù)軟件開發(fā)仍然是一個顯得混亂的活動，即典型的“邊寫邊改” （code and fix）。設(shè)計過程充斥著短期的，即時的決定，而無完整的規(guī)劃。這種模式對小系統(tǒng)開發(fā)其實很管用，但是當(dāng)系統(tǒng)變得越大越復(fù)雜時，要想加入新的功能就越來越困難。同時錯誤故障越來越多，越來越難于排除。一個典型的標(biāo)志就是當(dāng)系統(tǒng)功能完成后有一個很長的測試階段，有時甚至有遙遙無期之感，從而對項目的完成產(chǎn)生嚴(yán)重的影響。
我們使用這種開發(fā)模式已有很長時間了，不過我們實際上也有另外一種選擇，那就是“正規(guī)方法”（methodology）。這些方法對開發(fā)過程有著嚴(yán)格而詳盡的規(guī)定，以期使軟件開發(fā)更有可預(yù)設(shè)性并提高效率，這種思路是借鑒了其他工程領(lǐng)域的實踐。
這些正規(guī)方法已存在了很長時間了，但是并沒有取得令人矚目的成功，甚至就沒怎么引起人們的注意。對這些方法最常聽見的批評就是它們的官僚繁瑣，要是按照它的要求來，那有做太多的事情需要做，而延緩整個開發(fā)進(jìn)程。所以它們通常被認(rèn)為是“繁瑣滯重型”方法，或Jim HighSmith 所稱的“巨型”（monumental)方法。
作為對這些方法的反叛，在過去幾年中出現(xiàn)了一類新方法。盡管它們還沒有正式的名稱，但是一般被稱為“敏捷型”方法。對許多人來說，這類方法的吸引之處在于對繁文縟節(jié)的官僚過程的反叛。它們在無過程和過于繁瑣的過程中達(dá)到了一種平衡，使得能以不多的步驟過程獲取較滿意的結(jié)果。
敏捷型與滯重型方法有一些顯著的區(qū)別。其中一個顯而易見的不同反映在文檔上。敏捷型不是很面向文檔，對于一項任務(wù)，它們通常只要求盡可能少的文檔。從許多方面來看，它們更象是“面向源碼”（code-oriented）。事實上，它們認(rèn)為最根本的文檔應(yīng)該是源碼。
但是，我并不以為文檔方面的特點是敏捷型方法的根本之點。文檔減少僅僅是個表象，它其實反映的是更深層的特點：
? 敏捷型方法是“適配性”而非“預(yù)設(shè)性”。 重型方法試圖對一個軟件開發(fā)項目在很長的時間跨度內(nèi)作出詳細(xì)的計劃，然后依計劃進(jìn)行開發(fā)。這類方法在計劃制定完成后拒絕變化。而敏捷型方法則歡迎變化。其實，它們的目的就是成為適應(yīng)變化的過程，甚至能允許改變自身來適應(yīng)變化。
? 敏捷型方法是“面向人”的(people-oriented) 而非“面向過程”的 (process-oriented)。 它們試圖使軟件開發(fā)工作順應(yīng)人的天性而非逆之。它們強(qiáng)調(diào)軟件開發(fā)應(yīng)當(dāng)是一項愉快的活動。
我認(rèn)為以上兩個特點很好的概括了敏捷開發(fā)方法的核心思想：適應(yīng)變化和以人為中心
（二） 方法背后的思想
Alistair Cockburn在Agile Software Development中講述了敏捷開發(fā)方法背后的思想
人們掌握過程（process）可以分為3個階段：
1 following 遵循一個定義好的process
2 detaching 知道不同process的適用范圍，在不同的場合使用不同的process
3 fluent 不關(guān)心是否遵循特定的process，知道在什么情況下采用什么動作
軟件開發(fā)是一個充滿發(fā)明和交流的協(xié)作性游戲(cooperative game of invertion and communication)。軟件開發(fā)的首要目標(biāo)是生產(chǎn)出軟件，遵循特定的過程和模型只是手段，只要傳遞了足夠的信息，手段是次要的。交流的效果要遠(yuǎn)遠(yuǎn)重于交流的形式（Effect of communication is more important than the form of communication）。
一般軟件開發(fā)有兩個目標(biāo)：1 盡快的生產(chǎn)出軟件2 為下一個team或項目做準(zhǔn)備，有時這兩個目標(biāo)是矛盾的，我們要在這兩個目標(biāo)之間尋求平衡
在軟件開發(fā)中，人的因素要遠(yuǎn)遠(yuǎn)大于過程和技術(shù)。人是有缺陷的：
1 容易犯錯誤，因此必須在錯誤擴(kuò)散之前找到并改正錯誤
2 當(dāng)覺得可能失去較多的時候，不愿意冒險
3 重新構(gòu)造而不愿意重復(fù)使用已有的東西
4 難于堅持一個習(xí)慣
針對個人因素的幾個建議：
1 具體的模型較抽象的模型更容易理解
2 從一個例子開始是容易的
3 通過觀察他人的成果學(xué)習(xí)
4 要有足夠的不受打擾的時間
5 分配的工作要與個人意向，能力匹配
6 不正確的獎勵會有壞作用，從長期看個人興趣比獎勵更重要，培養(yǎng)在工作中的自豪感：
1) pride in work參與工作的自豪感，通常參與一個重要的工作會有自豪感
2) pride in accomplishment 完成工作的自豪感，長期未完的工作會使士氣低落
3)pride in contribution 為他人貢獻(xiàn)的自豪感
7 鼓勵關(guān)心其他人的工作和整體的工作
在一個團(tuán)隊之間，交流是最重要的，實踐證明面對面的實時的交流是最有效的，對交流的延誤會損失信息，白板是最好的交流工具，交流工具的先進(jìn)并不能提高交流效果。文檔的作用是記錄和備忘，不能通過文檔交流。
敏捷開發(fā)方法要避免的過程設(shè)計的幾個常見錯誤
1 對所有的項目使用同一種過程
2 沒有彈性
3 過于沉重
4 增加不必要的“必須完成”（“should do” is really should？）
5 沒有經(jīng)過實踐檢驗
敏捷開發(fā)方法過程設(shè)計的幾個原理：
1 交互的面對面的交流是代價最小，最迅速的交換信息的方法
2 超過實際需要的過程是浪費的
3 大的團(tuán)隊需要重量級方法
4 處理重大問題的項目需要重量級方法強(qiáng)調(diào)
5 增加反饋和交流可以減少中間產(chǎn)品和文檔的需求
6 輕量級方法更強(qiáng)調(diào)理解（understanding）,自律（discipline）和技能(skill)，重量級方法更強(qiáng)調(diào)文檔（documentation），過程（process）和正式（formality）
understanding指整個團(tuán)隊關(guān)于項目的全部知識，包括討論的過程，documentation只能記錄其中的一部分
discipline是指個人主動的完成工作，process指個人根據(jù)指令完成工作
skill指具有良好技能的人可以省略中間的產(chǎn)品，formality指必須按照規(guī)定步驟完成工作
7 確定開發(fā)中間的瓶徑，提高它的效率
對于瓶徑處的工作應(yīng)該盡量加快，減少重復(fù)，（使用更熟練的人，使用更多的人，使用更好的工具，使瓶徑處的工作的深入盡量穩(wěn)定）對于非瓶徑處的工作可以多一些重復(fù)，在輸入還不確定的情況下也可以盡早開始。
這些原理的幾個結(jié)論：
1 向一個項目增加人員要花費較大代價（constly），因為原有人員和新人員之間的交流要花費大量時間
2 團(tuán)隊的規(guī)模經(jīng)常是跳躍的，例子：需要6個熟練的程序員，但是只有4個，于是增加不熟練的程序員，結(jié)果團(tuán)隊的大量時間花費在培訓(xùn)不熟練的程序員上面，最后增加到了20個不熟練的程序員。
3 應(yīng)該側(cè)重于提高團(tuán)隊的技能而不是擴(kuò)充團(tuán)隊
4 對不同的項目使用不同的過程
5 在適用的條件下，輕量級的方法優(yōu)于重量級的方法
6 對不同的項目要裁減過程
敏捷開發(fā)方法的原則是“剛剛好”（Light and Sufficient）
（三） Crystal
Crystal是Alistair Cockburn提出的一組開發(fā)方法，分為Crystal Clear,Crystal Yellow, Crystal Orange和Crystal Red分別適用于不同的項目。項目可以按照參加的人員和重要性劃分。重要性根據(jù)項目中的錯誤引發(fā)的后果分為：
C Loss of comfort （某些不舒適）
D Loss of discretionary money (經(jīng)濟(jì)損失)
E Loss of Essential Money (嚴(yán)重經(jīng)濟(jì)損失)
L Life Critical (生命危險)
一個項目稱為C6說明參加人員在6人以下，重要性是C級，D20說明人員在6-20人，重要性是D級。
Crystal Clear適用于 C6,D6項目
Crystal Yellow適用于 C20,D20,E20項目
Crystal Orange 適用于 C40,D40,E40項目
Crystal Red 適用于 C80,D80,E80項目
Crystal Clear
適用于一個辦公室內(nèi)的一個小組
角色有： sponsor發(fā)起人，任務(wù)下達(dá)者
Senior Designer-Programmer 高級設(shè)計開發(fā)人員
Designer-Programmer 設(shè)計開發(fā)人員
User 用戶
其中一個人是項目協(xié)調(diào)者(Project Coordinator)。Senior Designer-Programmer是關(guān)鍵人員
策略：
1 軟件的開發(fā)采用有規(guī)則的周期性遞增方法，每2-3個月提交（deliver）一個版本
2 使用里程碑(milestone)跟蹤進(jìn)度（包括delvier和開發(fā)期間的重大決定）
3 自動回歸測試（automated regression test）
4 用戶直接參與
5 每個release有兩個user viewings(用戶審核?)
6 在上一個步驟足夠穩(wěn)定（stable enough to review）時立即開始下一個步驟，盡量并行開發(fā)
7 在每個周期的開始和中間進(jìn)行產(chǎn)品和過程調(diào)整
過程產(chǎn)品（指整個過程產(chǎn)生的所有產(chǎn)品，包括軟件和文檔）
1 軟件釋放順序（release sequence）
2 用戶審核的計劃
3 用戶案例（usecase）或需求描述
4 設(shè)計框架和必要的說明
5 界面草圖
6 基本的對象模型
7 執(zhí)行代碼
8 migration code
9 測試用例
10 用戶手冊
11 local matters有項目組決定：
上述product的摸班
編碼和用戶界面的標(biāo)準(zhǔn)
回歸測試的標(biāo)準(zhǔn)和細(xì)節(jié)
其他文檔
需要的工具：
版本控制工具
白板（最好可打印）
Crystal Orange
角色：sponsor 發(fā)起人
business export/usage export 業(yè)務(wù)專家
technical facilitator 技術(shù)專家
business analyst/designer 業(yè)務(wù)分析和設(shè)計人員
project manager 項目管理員
architect 系統(tǒng)架構(gòu)人員
Design Mentor 設(shè)計指導(dǎo)人員
Lead Designer-Programmer 主要設(shè)計編碼人員、
Other Designer-Programmer設(shè)計編碼人員
UI Designer 用戶界面設(shè)計人員
Writer 文檔寫作人員
Tester 測試人員
策略：
同Crystal Clear (周期可以為3-4個月)
過程產(chǎn)品：
需求文檔
計劃
狀態(tài)報告
用戶界面設(shè)計文檔
基本對象模型
外部接口標(biāo)準(zhǔn)
用戶手冊
源代碼
測試用例
migration code
local matters 同Crystal Clear
（四） The Agile Alliance
敏捷聯(lián)盟是17位不同敏捷開發(fā)方法的提倡者共同成立的，目的是推進(jìn)敏捷開發(fā)方法的研究和應(yīng)用，他們并不要求強(qiáng)制使用某種開發(fā)方法，而是提出了敏捷開發(fā)的幾個核心價值和基本原則：
core value:
Individuals and interactions over processes and tools
個人和交流重于過程和工具
Working software over comprehensive documentation
正在運(yùn)行的軟件本身重于復(fù)雜的文檔
Customer collaboration over contract negotiation
與客戶的溝通和交流重于使用合同約束客戶
Responding to change over following a plan
對變化的快速響應(yīng)重于跟隨計劃
principles
1 最高目標(biāo)是通過快速的和經(jīng)常的發(fā)布軟件滿足客戶的需要
2 提交軟件的周期為幾個星期到幾個月
3 產(chǎn)生正確的軟件是衡量進(jìn)度的首要標(biāo)準(zhǔn)
4 主動接受需求的改變而不是拒絕
5 商務(wù)人員和開發(fā)人員工作在一起
6 個人必須有動力，要創(chuàng)造環(huán)境支持他們的要求，信任他們
7 最有效的交流方法是面對面的交流
8 最好的結(jié)構(gòu)，需求和設(shè)計來自于自組織的團(tuán)隊（self-organizing team），允許任何人提出想法和建議
9 持續(xù)改進(jìn)設(shè)計和編碼
10 鼓勵正常工作，減少長時間加班
11 保持簡單，減少不必要的部分，認(rèn)識到簡單的設(shè)計比復(fù)雜的設(shè)計更難（simple design is harder to produce）
12 定期調(diào)整過程，獲得更高效率
（五） Extreme Programming
Extreme Programming（XP，極限編程） 是一種輕量級的軟件開發(fā)方法，它使用快速的反饋，大量而迅速的交流，經(jīng)過保證的測試來最大限度的滿足用戶的需求。XP強(qiáng)調(diào)用戶滿意，開發(fā)人員可以對需求的變化作出快速的反應(yīng)。XP強(qiáng)調(diào)team work。項目管理者，用戶，開發(fā)人員都處于同一個項目中，他們之間的關(guān)系不是對立的，而是互相協(xié)作的，具有共同的目標(biāo)：提交正確的軟件。XP強(qiáng)調(diào)4個因素：
交流(communication)，XP要求程序員之間以及和用戶之間有大量而迅速的交流
簡單（simplicity），XP要求設(shè)計和實現(xiàn)簡單和干凈
反饋（feedback）通過測試得到反饋，盡快提交軟件并根據(jù)反饋修改
勇氣（courage）。勇敢的面對需求和技術(shù)上的變化
XP特別適用于需求經(jīng)常改變的領(lǐng)域，客戶可能并系統(tǒng)的功能并沒有清晰的認(rèn)識，可能系統(tǒng)的需求經(jīng)常需要變動。
XP也適用于風(fēng)險比較高的項目，當(dāng)開發(fā)人員面對一個新的領(lǐng)域或技術(shù)時，XP可以幫助減低風(fēng)險
XP適用于小的項目（人員上），人員在2-12人之間，XP不適用于人員太多的項目，事實上，在需求經(jīng)常變化或風(fēng)險比較高的項目中，少量而有效的XP開發(fā)人員效率要遠(yuǎn)遠(yuǎn)高于大量的開發(fā)人員。
下面是XP的開發(fā)流程
XP的原則和實踐：
1 Planning:
1)user stories。
User stories類似use case，描述用戶所見的系統(tǒng)功能，但避免使用大量的文檔，user stories由用戶編寫（不僅限于描述用戶界面）。User stories使用用戶的語言編寫，不使用技術(shù)性的語言，每個user stories限于幾句話。User stories用于在release plan會議上對開發(fā)時間進(jìn)行評估，也用于產(chǎn)生驗收測試（acceptance test），必須使用可以自動進(jìn)行的驗收測試保證軟件的正確性。User stories與傳統(tǒng)的用戶需求的區(qū)別在于詳細(xì)的程度，user stories并不會確定需求的每個細(xì)節(jié)，它只是用來簡單的描述系統(tǒng)功能，供開發(fā)人員進(jìn)行估計開發(fā)進(jìn)度，在開發(fā)過程中開發(fā)人員和用戶會不斷的交流以討論細(xì)節(jié)問題。User story應(yīng)該專注于功能，不應(yīng)該過分注重用戶界面等細(xì)節(jié)。一般一個user storiy在1-3周的時間完成，如果估計超過3周，說明user story太大了，需要細(xì)分。
2)release plan.
召開一個release plan會議，產(chǎn)生release plan。Release plan將用于指定每個iteration的計劃。開發(fā)人員對每個user story估計開發(fā)時間（在不被打斷，無其他工作情況下的開發(fā)時間，包括測試），用戶對user stories給出優(yōu)先級，release plan會議并不制訂每個iteration的計劃。Release plan要用戶，開發(fā)人員和管理者都同意，在完成功能范圍（scope），使用資源（resource）,時間（time）和質(zhì)量(quality)上達(dá)成一致（一般質(zhì)量是不能改變的）
3) small release
often and small release是XP的一個原則，每個release完成一些用戶有意義的功能集合，盡快的提交給用戶以獲得反饋，及時調(diào)整，提交的越晚，調(diào)整越困難。
4）project velocity
團(tuán)隊在開發(fā)過程中要收集數(shù)據(jù)，以便于對自己的開發(fā)速度進(jìn)行評估，用于以后的releazse plan
5)iteration
每個small release的周期稱為iteration，每個iteration約為1-3周，在一個項目中保持每個iteration的時間相等，不要超前制定計劃，每個iteration的計劃在iteration的開始時制定。這樣能夠更靈活的應(yīng)付變化。不要急于完成本次iteration沒有包括的功能。要注重每個iteration的時間限制，當(dāng)團(tuán)隊覺得不能按時完成iteration時，召開一次iteration plan會議，重新評估，減少一些user stories。
下面是iteration的圖示：
6）iteration plan
在每個iteration開始的時候召開會議，從release plan中選擇還沒有實現(xiàn)的用戶最迫切需要的user stories。上一個iteration中沒有通過驗收測試的功能也要在這個iteration中實現(xiàn)?？梢愿鶕?jù)上一個iteration的實踐調(diào)整團(tuán)隊速度。User stories和失敗的測試被分解成programming task，task使用技術(shù)語言編寫，作為iteration plan的詳細(xì)描述。程序員主動領(lǐng)取task并估計完成時間，每個task應(yīng)該在1-3天內(nèi)完成，超過3天的task應(yīng)該被細(xì)分。如果整個團(tuán)隊需要的時間多于或少于規(guī)定的iteration時間，調(diào)整user stories。
7）move people around
不要使每個開發(fā)人員局限于一項工作，不要使某項工作依賴于一個開發(fā)人員，增加知識共享，減少信息孤島，多進(jìn)行交流和培訓(xùn)。當(dāng)項目中的所有人對所有模塊都了解并可以進(jìn)行開發(fā)時是效率最高的，鼓勵開發(fā)人員在不同iteration中開發(fā)不同的模塊。
8) stand-up meeting
每天工作開始之前，開5-10分鐘的stand-up會議（站立會議），站立的目的是為了強(qiáng)迫節(jié)省時間，會議的目的是交流，提出存在的問題，但不要在會議上解決問題。開一個所有人員參加的短會比多個個別人員參加的會議要高效。在會議上提出的問題可以由少數(shù)人討論解決，這個少數(shù)人參加的會議如果涉及到代碼，可以在計算機(jī)前討論。
9) fix XP when it breaks
XP并不是一成不變的，當(dāng)團(tuán)隊覺得需要修改的時候，可以根據(jù)自己的情況進(jìn)行修改，任何修改都要經(jīng)過整個團(tuán)隊的討論和達(dá)成一致
2 Designing
1) Simplicity
保持簡單的設(shè)計，在完成同樣的功能的情況下，選擇簡單的設(shè)計，不要急于設(shè)計沒有計劃的功能，應(yīng)該認(rèn)識到：keeping a design simple is hard work
2）system metaphor
使用統(tǒng)一的術(shù)語描述系統(tǒng)，在用戶，管理者和開發(fā)人員之間使用統(tǒng)一的術(shù)語。這將使交流清晰。
3）CRC card
使用CRC(Class, Responsibilities, and Collaboration) card進(jìn)行系統(tǒng)設(shè)計，鼓勵更多的人參加設(shè)計。每個CRC卡片表示系統(tǒng)中一個對象，寫上對象的名字，責(zé)任和每個責(zé)任需要交互的其他對象?？梢阅M對象之間的交互。CRC卡片是易于理解的，但是是非正式的，如果需要正式的文檔，要將卡片轉(zhuǎn)換為相應(yīng)的文檔。
4) spike solution
使用spike solution減低風(fēng)險，當(dāng)遇到技術(shù)難題或設(shè)計問題時，使用簡單的程序進(jìn)行測試，找出問題，在不同的解決方法之間進(jìn)行評估。在早期進(jìn)行實驗可以有效的降低風(fēng)險。
5）never add function early
不要過早的設(shè)計沒有計劃的功能，在一個需求經(jīng)常變化的環(huán)境中，過早的設(shè)計經(jīng)常是沒有用的。
6）refactoringwhenever and wherever
XP鼓勵對設(shè)計和代碼經(jīng)常進(jìn)行重構(gòu)（Refactoring），目的是去除冗余，提高質(zhì)量，保持設(shè)計簡單。重構(gòu)必須以完全測試為檢驗條件
3 Coding
1) customer is alaways available
用戶是項目組的成員之一，用戶的參加貫穿整個開發(fā)過程，用戶與開發(fā)人員之間的交流是重要的
2) coding standard
使用統(tǒng)一的編碼標(biāo)準(zhǔn)，這是保持代碼整潔和共享代碼的基礎(chǔ)
3）coding unit test first
test first是XP的一個特點，在編寫代碼之前先編寫單元測試代碼，單元測試代碼和代碼由同一個程序員完成。先編寫測試代碼可以使程序員更好的理解需求，避免直接編碼造成的理解偏差，對需求的不清晰，可以在編寫測試代碼時就發(fā)現(xiàn)。測試代碼也是檢驗程序是否完成的標(biāo)準(zhǔn)。編碼工作應(yīng)該是以下工作的循環(huán)：
1 編寫測試代碼
2 運(yùn)行測試程序，確認(rèn)失敗
3 編寫實現(xiàn)這個測試程序要求功能的代碼，不需要實現(xiàn)其他的功能，只需要實現(xiàn)剛剛滿足測試程序的功能
4 運(yùn)行測試程序，確認(rèn)成功
實踐證明，test first方式需要的編碼實踐少于先編碼，后寫測試代碼
4) Pair Programming
Pair programming是XP的特色，它要求兩個程序員在一臺計算機(jī)上同時進(jìn)行編程工作。共用鼠標(biāo)和鍵盤，通常一個人進(jìn)行戰(zhàn)略上的思考，程序架構(gòu)和函數(shù)，類之間的關(guān)系，一個人進(jìn)行輸入和戰(zhàn)術(shù)上的思考，完成函數(shù)和類。兩個人可以經(jīng)常交換角色。Pair programming需要一段時間學(xué)習(xí)和適應(yīng)，實踐證明pair programming并不消耗更多的時間(人*小時)，但是代碼的質(zhì)量得到很大的提高。（避免將兩個新手放在一個pair中）
5）sequential integration
要保證源代碼庫的狀態(tài)是可標(biāo)識的，同一時間，只允許一個pair的程序進(jìn)行整和和測試，這樣可以縮小問題產(chǎn)生的范圍。不同的pair可以在自己的機(jī)器上隨時進(jìn)行整和和測試.
6) integrate often
只要有可能就進(jìn)行代碼整合，周期可以在幾個小時，最好不要超過一天。經(jīng)常的整合可以避免錯誤的積累，可以增加可重用的代碼。在一個pair認(rèn)為適當(dāng)?shù)臅r候并通過了所有的unit test，就可以進(jìn)行整合，整合后的代碼必須通過測試。同一時間，只允許一個pair進(jìn)行整合。(整合失敗是不是要退回原有狀態(tài)，供其他pair整合？？)
7) 共同擁有代碼
鼓勵每個人對項目中的任何人提出新的想法，任何開發(fā)人員對項目中的任何代碼都可以進(jìn)行增加功能，改正錯誤和重構(gòu)。沒有代碼或開發(fā)人員成為瓶頸。（我的想法：這確實很難理解，但是這確實是我夢想的目標(biāo)）。為了達(dá)到這個目標(biāo)，任何的代碼都必須有相應(yīng)的測試代碼，任何代碼的修改必須100%通過測試。必須加強(qiáng)開發(fā)人員的交流和知識共享，必須堅持統(tǒng)一編碼標(biāo)準(zhǔn)。Pair programming可以經(jīng)常交換伙伴。
8）優(yōu)化工作放在最后
先使系統(tǒng)能夠正常工作，不要猜測系統(tǒng)的瓶頸，要實際測量
9）NO overtime
不要長時間的加班，大多數(shù)加班并不能挽回已有的延遲，連續(xù)超過兩個星期的加班說明有問題存在。向一個已經(jīng)延遲的項目填加人員也不是一個好的選擇。
4.Testing
1)所有的代碼都有單元測試
單元測試是XP的基石，XP中的單元測試應(yīng)該是可以自動進(jìn)行的，所以可以很快的進(jìn)行所有的單元測試，單元測試應(yīng)該在編碼之前創(chuàng)建。單元測試的代碼和代碼一起release，沒有單元測試的代碼不能夠release。使用自動單元測試可以系統(tǒng)整合時節(jié)省大量的發(fā)現(xiàn)錯誤和改正的時間。單元測試越完善，節(jié)省的時間越多。對面向?qū)ο?/a>的編程來說，應(yīng)該對每個類都有單元測試。完善的單元測試也是共同擁有代碼的保證。單元測試也是可以經(jīng)常重構(gòu)的保證，每次重構(gòu)后的代碼都要重新進(jìn)行測試
（這里的unit test好象不只限于測試某個模塊的功能？？？，應(yīng)該可以測試整合起來的整個系統(tǒng)，這樣才能保證整合的正確性。）
2）代碼在release前必須通過所有的單元測試
3) 發(fā)現(xiàn)bug后，首先增加測試
在實際運(yùn)行中發(fā)現(xiàn)bug,首先增加acceptance test，然后增加unit test，在增加完測試后在查找和修改代碼，增加的測試保證同樣的錯誤不會再出現(xiàn)
4) acceptance test
acceptance test根據(jù)user stories在iteration plan會議上創(chuàng)建，它也應(yīng)該可以自動運(yùn)行以便可以經(jīng)常運(yùn)行。User stories是否完成是以是否通過acceptance test為檢驗標(biāo)準(zhǔn)。
XP中的角色：
1 customer 用戶
在XP中，用戶是項目組的一部分，用戶負(fù)責(zé)編寫use stories，確定優(yōu)先級，和開發(fā)人員討論需求，編寫accept test，運(yùn)行accept test，用戶驅(qū)動iteration(release plan, iteration plan)
2 開發(fā)人員
與用戶討論user stories，估計開發(fā)時間，將user stories細(xì)化成programming task
編寫unit test
編碼
進(jìn)行重構(gòu)
整合及測試，保證100通過
3 manager
負(fù)責(zé)對外聯(lián)系，組織團(tuán)隊，獲取必要的資源，管理團(tuán)隊
4 tracker
跟蹤release plan/iteration plan/acceptance test
5 coach
起顧問指導(dǎo)作用，mentor, monitor and help
A Coach is respected, but also respectful. They’re willing to talk, but also willing to listen. They let the team explore, but provide a guard-rail in case of danger.
監(jiān)督進(jìn)展，確保過程和規(guī)則，必要時改變過程，幫助解決問題，也可以參加pair programming。
二、敏捷開發(fā)的設(shè)計原則
關(guān)于敏捷開發(fā)的設(shè)計原則：
單一職責(zé)原則SRP：Single Responsibility Principle
開放封閉原則OCP：Open－Close Principle
Liskov替換原則LSP：Liskov Substitution Principle
依賴倒置原則DIP：Dependency Invertion Principle
接口隔離原則ISP：Interface Separate Principle
關(guān)于包的設(shè)計原則：
重用發(fā)布等價原則REP：Reuse Equivalence Principle
共同重用原則CRP：Common Resue Principle
共同封閉原則CCP：Common Close Principle
無環(huán)依賴原則ADP：Acyclic Dependency Principle
穩(wěn)定依賴原則SDP：Stabilization Dependency Principle
穩(wěn)定性度量公式：I＝Ce/(Ca+Ce) (I:不穩(wěn)定度，Ce:輸入耦合度，Ca：輸出耦合度)
I取值范圍在【0，1】，I＝0表示具有最大穩(wěn)定度；iI＝1標(biāo)識具有最大不穩(wěn)定度
穩(wěn)定抽象原則SAP：Stabilization Abstract Principle
GOF說－－基于對象組合的設(shè)計會有更多的對象（而有較少的類）。
如果單純的看這里，你會明白似乎類較少符合面向?qū)ο蟮倪壿嫛?br />
但是且慢，我們知道面向?qū)ο笥幸粭l原則叫單一職責(zé)原則－－SRP。
這樣好像類多又是面向?qū)ο笏枷氲捏w現(xiàn)。
其實最重要的是GOF中的這句話－－且系統(tǒng)的行為將依賴對象間的關(guān)系而不是被定義在某個類中。
所以類的多少并不是問題的關(guān)鍵，是否職責(zé)單一也不是大問題，
最重要的是你現(xiàn)在的那些職責(zé)是都多少是不能被別的職責(zé)通過某種方式所代替的。
在BOB大叔那里定義職責(zé)是變化的原因，因此就可以認(rèn)為這些變化的原因應(yīng)該是不可代替的，
也可以說你不能由這個原因推導(dǎo)出別的原因。
只要這個原因間可以做到相互關(guān)聯(lián)，那么你就可以把由于這些變化而引起變化的類組合起來，
而不是把他們規(guī)定在新的類中。
開放封閉原則OCP：Open－Close Principle
一個模塊在擴(kuò)展性方面應(yīng)該是開放的而在更改性方面應(yīng)該是封閉的。
因此在進(jìn)行面向?qū)ο笤O(shè)計時要盡量考慮接口封裝機(jī)制、抽象機(jī)制和多態(tài)技術(shù)。
該原則同樣適合于非面向?qū)ο笤O(shè)計的方法，是軟件工程設(shè)計方法的重要原則之一。
我們以收音機(jī)的例子為例，講述面向?qū)ο蟮拈_閉原則。
我們收聽節(jié)目時需要打開收音機(jī)電源，對準(zhǔn)電臺頻率和進(jìn)行音量調(diào)節(jié)。
但是對于不同的收音機(jī)，實現(xiàn)這三個步驟的細(xì)節(jié)往往有所不同。
比如自動收縮電臺的收音機(jī)和按鈕式收縮在操作細(xì)節(jié)上并不相同。
因此，我們不太可能針對每種不同類型的收音機(jī)通過一個收音機(jī)類來實現(xiàn)（通過重載）這些不同的操作方式。
但是我們可以定義一個收音機(jī)接口，提供開機(jī)、關(guān)機(jī)、增加頻率、降低頻率、增加音量、降低音量六個抽象方法。
不同的收音機(jī)繼承并實現(xiàn)這六個抽象方法。
這樣新增收音機(jī)類型不會影響其它原有的收音機(jī)類型，收音機(jī)類型擴(kuò)展極為方便。
此外，已存在的收音機(jī)類型在修改其操作方法時也不會影響到其它類型的收音機(jī)。
圖1是一個應(yīng)用OCP生成的收音機(jī)類圖的例子：
Liskov替換原則LSP：Liskov Substitution Principle
子類應(yīng)當(dāng)可以替換父類并出現(xiàn)在父類能夠出現(xiàn)的任何地方。
我們以學(xué)生為例，夜校生為學(xué)生的子類，因此在任何學(xué)生可以出現(xiàn)的地方，夜校生均可出現(xiàn)。
這個例子有些牽強(qiáng)，
一個能夠反映這個原則的例子時圓和橢圓，圓是橢圓的一個特殊子類。
因此任何出現(xiàn)橢圓的地方，圓均可以出現(xiàn)。但反過來就可能行不通。
運(yùn)用替換原則時，我們盡量把類B設(shè)計為抽象類或者接口，
讓C類繼承類B（接口B）并實現(xiàn)操作A和操作B，
運(yùn)行時，類C實例替換B，這樣我們即可進(jìn)行新類的擴(kuò)展（繼承類B或接口B），
同時無須對類A進(jìn)行修改。
依賴倒置原則DIP：Dependency Invertion Principle
在進(jìn)行業(yè)務(wù)設(shè)計時，與特定業(yè)務(wù)有關(guān)的依賴關(guān)系應(yīng)該盡量依賴接口和抽象類，而不是依賴于具體類。
具體類只負(fù)責(zé)相關(guān)業(yè)務(wù)的實現(xiàn)，修改具體類不影響與特定業(yè)務(wù)有關(guān)的依賴關(guān)系。
在結(jié)構(gòu)化設(shè)計中，我們可以看到底層的模塊是對高層抽象模塊的實現(xiàn)（高層抽象模塊通過調(diào)用底層模塊），
這說明，抽象的模塊要依賴具體實現(xiàn)相關(guān)的模塊，
底層模塊的具體實現(xiàn)發(fā)生變動時將會嚴(yán)重影響高層抽象的模塊，顯然這是結(jié)構(gòu)化方法的一個"硬傷"。
面向?qū)ο蠓椒?/a>的依賴關(guān)系剛好相反，具體實現(xiàn)類依賴于抽象類和接口
為此，我們在進(jìn)行業(yè)務(wù)設(shè)計時，應(yīng)盡量在接口或抽象類中定義業(yè)務(wù)方法的原型，
并通過具體的實現(xiàn)類（子類）來實現(xiàn)該業(yè)務(wù)方法，業(yè)務(wù)方法內(nèi)容的修改將不會影響到運(yùn)行時業(yè)務(wù)方法的調(diào)用
接口隔離原則ISP：Interface Separate Principle
采用多個與特定客戶類有關(guān)的接口比采用一個通用的涵蓋多個業(yè)務(wù)方法的接口要好。
ISP原則是另外一個支持諸如COM等組件化的使能技術(shù)。
缺少ISP，組件、類的可用性和移植性將大打折扣。
這個原則的本質(zhì)相當(dāng)簡單。如果你擁有一個針對多個客戶的類，
為每一個客戶創(chuàng)建特定業(yè)務(wù)接口，然后使該客戶類繼承多個特定業(yè)務(wù)接口將比直接加載客戶所需所有方法有效。
以下展示了一個擁有多個客戶的類。
它通過一個巨大的接口來服務(wù)所有的客戶。
只要針對客戶A的方法發(fā)生改變，客戶B和客戶C就會受到影響。
因此可能需要進(jìn)行重新編譯和發(fā)布。這是一種不幸的做法。
所展示的技術(shù)。每個特定客戶所需的方法被置于特定的接口中，這些接口被Service類所繼承并實現(xiàn)。
如果針對客戶A的方法發(fā)生改變，客戶B和客戶C并不會受到任何影響，也不需要進(jìn)行再次編譯和重新發(fā)布。
三、敏捷開發(fā)技術(shù)在電子商務(wù)軟件中的應(yīng)用
第一章 背景介紹
1.1 電子商務(wù)背景
隨著企業(yè)信息化的不斷進(jìn)步，電子商務(wù)在中國也越來越得到更多的認(rèn)可，電子商務(wù)的應(yīng)用也越來越多，但是很多企業(yè)對電子商務(wù)的概念和應(yīng)用還不是很清楚，行業(yè)內(nèi)對電子商務(wù)的研究模式和實施方法也存在很多問題。因此很多企業(yè)在實施電子商務(wù)系統(tǒng)的過程中都處在探索和摸索當(dāng)中，對于項目開發(fā)方來說也有著極大的風(fēng)險性和挑戰(zhàn)性。
1.2 電子商務(wù)軟件開發(fā)存在的問題
由于電子商務(wù)軟件開發(fā)存在很大的風(fēng)險性，而且電子商務(wù)的應(yīng)用也出在不斷摸索當(dāng)中，沒有很多成熟的模式可以參考，所以沒有實踐的指導(dǎo)可能會導(dǎo)致的項目噩夢。缺乏有效的實踐會導(dǎo)致不可預(yù)測性、重復(fù)的錯誤以及努力的白白浪費。延期的進(jìn)度、增加的預(yù)算和低劣的質(zhì)量致使客戶對我們喪失信心。更長時間的工作卻生產(chǎn)出更加低劣的軟件產(chǎn)品，也使得開發(fā)人員感到沮喪。我們希望這些方法這次還會有效，從而消除我們的恐懼。然而，項目并沒有簡單到使用一些約束和人為制品就能夠可靠地防止錯誤的地步。當(dāng)連續(xù)地犯錯誤時，我們會對錯誤進(jìn)行診斷，并在過程中增加更多的約束和人為制品來防止以后重犯這樣的錯誤。一個大而笨重的過程會產(chǎn)生它本來企圖去解決的問題。它降低了團(tuán)隊的開發(fā)效率，使得進(jìn)度延期，預(yù)算超支。它降低了團(tuán)隊的響應(yīng)能力，使得團(tuán)隊經(jīng)常創(chuàng)建錯誤的產(chǎn)品。
1.3 敏捷開發(fā)技術(shù)概述
敏捷式開發(fā)采用適應(yīng)性方法，而傳統(tǒng)的軟件工程學(xué)采用的是預(yù)測性方法。敏捷式開發(fā)是以人為主的，而傳統(tǒng)的工程學(xué)是以過程為主的。
1.4 敏捷開發(fā)的現(xiàn)實意義
適應(yīng)性和預(yù)測性的區(qū)別存在于軟件工程學(xué)對軟件開發(fā)過程的描述中。在傳統(tǒng)的工程學(xué)里，核心的概念就是把設(shè)計和構(gòu)建這兩個過程分開進(jìn)行。在軟件開發(fā)的過程中，我們很難想象，如何真正把設(shè)計和編程完全區(qū)分過來。軟件工程學(xué)領(lǐng)域，所有在這里從事工作的人員，都把設(shè)計的過程想象成用圖表、圖象的方式來描述結(jié)果的過程。還有一個更重要的問題就是說，軟件本身的需求是在變化的。一個項目在開發(fā)過程中需求會出現(xiàn)變化，需求的變化從根本上推翻了工程學(xué)方法所建立的一個基礎(chǔ)。當(dāng)工程學(xué)的人盡量減少或者控制系統(tǒng)將來發(fā)生變化的可能，他越這樣做問題就越容易出現(xiàn)。既然我們沒辦法避免變化的發(fā)生，那么我們就想找到一種新的方法能夠更有效地適應(yīng)這種變化現(xiàn)象。這也就是敏捷式開發(fā)方法所要達(dá)到的效果。
第二章 敏捷開發(fā)技術(shù)的應(yīng)用
2.1 敏捷開發(fā)技術(shù)的幾種主要類型
1.XP（Extreme Programming －－ 極限編程
2.Cockburn的水晶系列方法
3.開放式源碼
4.Highsmith的適應(yīng)性軟件開發(fā)方法〔ASD〕
2.2 敏捷開發(fā)技術(shù)的特點和優(yōu)勢
1．個體和交互勝過過程和工具
人是獲得成功的最為重要的因素。如果團(tuán)隊中沒有優(yōu)秀的成員，那么就是使用好的過程也不能從失敗中挽救項目，但是，不好的過程卻可以使最優(yōu)秀的團(tuán)隊成員失去效用。如果不能作為一個團(tuán)隊進(jìn)行工作，那么即使擁有一批優(yōu)秀的成員也一樣會慘敗。團(tuán)隊的構(gòu)建要比環(huán)境的構(gòu)建重要得多。許多團(tuán)隊和管理者就犯了先構(gòu)建環(huán)境，然后期望團(tuán)隊自動凝聚在一起的錯誤。相反，應(yīng)該首先致力于構(gòu)建團(tuán)隊，然后再讓團(tuán)隊基于需要來配置環(huán)境。
2．可以工作的軟件勝過面面俱到的文檔
沒有文檔的軟件是一種災(zāi)難。代碼不是傳達(dá)系統(tǒng)原理和結(jié)構(gòu)的理想媒介。團(tuán)隊更需要編制易于閱讀的文檔，來對系統(tǒng)及其設(shè)計決策的依據(jù)進(jìn)行描述。然而，過多的文檔比過少的文檔更糟。編制眾多的文檔需要花費大量的時間，并且要使這些文檔和代碼保持同步，就要花費更多的時間。如果文檔和代碼之間失去同步，那么文檔就會變成龐大的、復(fù)雜的謊言，會造成重大的誤導(dǎo)。雖然從代碼中提取系統(tǒng)的原理和結(jié)構(gòu)信息可能是困難的，但是代碼是惟一沒有二義性的信息源。在團(tuán)隊成員的頭腦中，保存著時常變化的系統(tǒng)的脈絡(luò)圖（road map）。人和人之間的交互是把這份脈絡(luò)圖傳授給他人的最快、最有效的方式。
3．客戶合作勝過合同談判
不能像訂購日用品一樣來訂購軟件。你不能夠僅僅寫下一份關(guān)于你想要的軟件的描述，然后就讓人在固定的時間內(nèi)以固定的價格去開發(fā)它。所有用這種方式來對待軟件項目的嘗試都以失敗而告終。有時，失敗是慘重的。告訴開發(fā)團(tuán)隊想要的東西，然后期望開發(fā)團(tuán)隊消失一段時間后就能夠交付一個滿足需要的系統(tǒng)來，這對于公司的管理者來說是具有誘惑力的。然而，這種操作模式將導(dǎo)致低劣的質(zhì)量和失敗。成功的項目需要有序、頻繁的客戶反饋。項目的需求基本處于一個持續(xù)變化的狀態(tài)。大的變更是很平常的。在這期間，也會出現(xiàn)整個功能塊被減掉，而加進(jìn)來另外一些功能塊。然而，合同和項目都經(jīng)受住了這些變更，并獲得成功。成功的關(guān)鍵在于和客戶之間真誠的協(xié)作，并且合同指導(dǎo)了這種協(xié)作，而不是試圖去規(guī)定項目范圍的細(xì)節(jié)和固定成本下的進(jìn)度。
4．響應(yīng)變化勝過遵循計劃
響應(yīng)變化的能力常常決定著一個軟件項目的成敗。當(dāng)我們構(gòu)建計劃時，應(yīng)該確保計劃是靈活的并且易于適應(yīng)商務(wù)和技術(shù)方面的變化。計劃不能考慮得過遠(yuǎn)。
2.3 敏捷開發(fā)技術(shù)的12個原則
1．我們最優(yōu)先要做的是通過盡早的、持續(xù)的交付有價值的軟件來使客戶滿意。
2．即使到了開發(fā)的后期，也歡迎改變需求。
3．經(jīng)常性地交付可以工作的軟件，交付的間隔可以從幾周到幾個月，交付的時間間隔越短越好
4．在整個項目開發(fā)期間，業(yè)務(wù)人員和開發(fā)人員必須天天都在一起工作。
5．圍繞被激勵起來的個人來構(gòu)建項目。
6．在團(tuán)隊內(nèi)部，最具有效果并且富有效率的傳遞信息的方法，就是面對面的交談。
7．工作的軟件是首要的進(jìn)度度量標(biāo)準(zhǔn)。
8．敏捷過程提倡可持續(xù)的開發(fā)速度。
9．不斷地關(guān)注優(yōu)秀的技能和好的設(shè)計會增強(qiáng)敏捷能力。
10．簡單使未完成的工作最大化。
11．最好的構(gòu)架、需求和設(shè)計出自于自組織的團(tuán)隊。
12．每隔一定時間，團(tuán)隊會在如何才能更有效地工作方面進(jìn)行反省，然后相應(yīng)地對自己的行為進(jìn)行調(diào)整。
2.4 敏捷開發(fā)技術(shù)的適用范圍
1.項目團(tuán)隊的人數(shù)不能太多
2.項目經(jīng)常發(fā)生變更
3.高風(fēng)險的項目實施
4.開發(fā)人員可以參與決策
第三章 敏捷開發(fā)技術(shù)在電子商務(wù)軟件的實際應(yīng)用案例
3.1 案例說明：鋼鐵貿(mào)易企業(yè)的網(wǎng)上期貨訂貨系統(tǒng)開發(fā)實施
項目背景：國內(nèi)某大型國有鋼鐵貿(mào)易企業(yè)，其業(yè)務(wù)形式大部分采用期貨訂貨，客戶群也比較廣泛，訂貨時間相對比較穩(wěn)定，一般集中在月底的10天左右。該企業(yè)原來開發(fā)了一套適合自己企業(yè)運(yùn)作的貿(mào)易企業(yè)ERP系統(tǒng)，但是僅僅是在公司內(nèi)部使用，功能也很有限，不能夠很好的和客戶進(jìn)行信息交流，往往客戶在集中訂貨的時候，因為訂貨量巨大，而且時間集中，所以造成該企業(yè)的業(yè)務(wù)人員忙的團(tuán)團(tuán)轉(zhuǎn)，而且經(jīng)常會發(fā)生排隊訂貨的現(xiàn)象，同時由于是期貨訂貨，所以該企業(yè)還得向上游供應(yīng)商訂貨，這樣一來一去，給工作帶來極大的不便，也容易造成混亂和漏洞。
因此，介于用戶這樣的情況，需要開發(fā)一套網(wǎng)上期貨訂貨系統(tǒng)，將訂貨的整個環(huán)節(jié)都打通，真正實現(xiàn)24小時訂貨。減少人工干預(yù)，通過和幾個系統(tǒng)之間的集成，做到實時的信息流通。但是這樣一個系統(tǒng)對于該企業(yè)來說，畢竟是第一回，國內(nèi)也沒有相關(guān)成熟的案例和模型，所以實施存在極大的風(fēng)險性。而且其他同行業(yè)的競爭對手也在著手打造這樣的一個系統(tǒng)，所以盡早建立網(wǎng)上訂貨系統(tǒng)，對于提高顧客的忠誠度和滿意度都是大有裨益的，所以對工期的要求也非常嚴(yán)格。
根據(jù)以上情況，決定采用敏捷開發(fā)技術(shù)來實施這個項目。
3.2 項目組織機(jī)構(gòu)
建立聯(lián)合實施團(tuán)隊，由電子商務(wù)公司的項目實施人員和客戶方的關(guān)鍵用戶一起構(gòu)成，統(tǒng)一受客戶方的常務(wù)副總指揮。
工作方式：在客戶現(xiàn)場辦公，在調(diào)研的同時做需求，根據(jù)系統(tǒng)架構(gòu)和功能劃分，邊做設(shè)計邊做開發(fā)。
溝通方式：每天下班前半個小時，所有項目組成員必須座在一起溝通交流，對每天的工作進(jìn)行總結(jié)和經(jīng)驗交流。每周召開一次推進(jìn)和培訓(xùn)會議，在不斷的開發(fā)過程中進(jìn)行對用戶的業(yè)務(wù)知識，系統(tǒng)知識，和操作的培訓(xùn)，為將來系統(tǒng)的運(yùn)行維護(hù)打下更好的基礎(chǔ)。
3.3 項目實施過程
第一輪循環(huán)實施周期兩個月，不但搭建了整個應(yīng)用的整體框架，還實現(xiàn)了兩大品種的單向期貨訂貨流程。
第二輪循環(huán)實施周期兩個月，打通了向供應(yīng)商的期貨訂貨環(huán)節(jié)，并且實現(xiàn)了另外兩個品種的訂貨。同時逐步將前期做好的系統(tǒng)向用戶做推廣使用，在不斷完善的過程中，對本階段的項目開發(fā)實施做修正。
第三輪循環(huán)實施周期三個月。由開發(fā)人員和客戶方的關(guān)鍵用戶對期貨訂貨系統(tǒng)進(jìn)行完善和優(yōu)化。
3.4 項目實施效果
1. 客戶方由于實施了該項目，給訂貨用戶和公司業(yè)務(wù)員帶來很大的便利，效率大大提高，再也沒有排隊訂貨的狀況，再也沒有業(yè)務(wù)員通宵達(dá)旦的處理訂貨需求，再也不會和供應(yīng)商之間發(fā)生信息失真的現(xiàn)象。系統(tǒng)的快速實施和推進(jìn)，使得客戶對該系統(tǒng)也越來越依賴，同時該公司的銷售業(yè)績也率攀新高。
2.由于采用了敏捷開發(fā)技術(shù)，極大的降低了開發(fā)成本，大大提高了開發(fā)的效率。盡管在整個項目實施過程中存在大量的變更和修正，但是這樣的開發(fā)方式可以很有效的避免帶來更多負(fù)面的扯皮現(xiàn)象。
3.因為項目成員由高水平的開發(fā)人員參加，所以對客戶的業(yè)務(wù)理解非常深入，在實際的項目開發(fā)當(dāng)中，不但承擔(dān)了具體開發(fā)的工作，還向客戶方提出很多很好的建議改進(jìn)措施，以便業(yè)務(wù)更加優(yōu)化，操作更加順暢。一方面，客戶方從中收益，另外一方面，開發(fā)人員的能力也得到了極大的提高。
第四章 敏捷開發(fā)技術(shù)在電子商務(wù)軟件的推廣
1. 電子商務(wù)軟件實施的高風(fēng)險性
軟件開發(fā)行業(yè)目前同時存在兩種情況，它既是一個非常成功的又是具有很多問題的行業(yè)。
2. 在跨平臺系統(tǒng)的移植上的應(yīng)用
電子商務(wù)系統(tǒng)經(jīng)常會出現(xiàn)跨平臺的移植。重要的一點就是從功能角度講，移植前后是否一致。一些敏捷開發(fā)中的最佳實踐也是可以使用的，比如你可以把所有的需求以測試的方式提煉出來。很多項目都是使用這種方式而且非常成功。而且使用這種疊蓋式方式，也能夠從項目進(jìn)程的角度看移植進(jìn)程有多快。
3. 在電子商務(wù)軟件外包公司的應(yīng)用
軟件外包是非常普遍的。在實踐中發(fā)現(xiàn)敏捷式開發(fā)對外包也是非常有效的方法。實踐中敏捷式開發(fā)比一般的開發(fā)方式估算的方法更快，而且用的人要少一些。
希望中國更多的軟件公司可以采用敏捷開發(fā)技術(shù)，使我們的軟件產(chǎn)業(yè)能夠得到更加快速的提高和發(fā)展！（作者： 徐祎 就職于東方鋼鐵電子商務(wù)有限公司，職務(wù)為首席項目經(jīng)理。目前就讀上海交通大學(xué)MBA班 ）
四、敏捷開發(fā)常用工具
工欲擅其事，必先利其器，能利用工具是人與動物的最大區(qū)別。然而，大多數(shù)商業(yè)化工具價格不菲，已經(jīng)加入WTO好幾年了，再用盜版會給企業(yè)帶來很大的不確定性，并且盜版用多了，往往會失去一種程序員的自豪感，丟掉一種文化。經(jīng)過幾個月的摸索，本著以下原則，偶選擇了一些適合中小企業(yè)開發(fā)的工具，當(dāng)作自己的工具箱：
（1）適用于中小型企業(yè)，中小型項目（<500萬），功能適度
（2）易用性好，具備必要的文檔
（3）免費或低價
基于這些工具，慢慢形成了一套敏捷開發(fā)過程。
（一）、工具簡介
下面簡單介紹這些工具，這些工具有些偶已經(jīng)有相當(dāng)?shù)氖褂媒?jīng)驗，有些正在使用，有些只是剛選定。除直接用于.net開發(fā)的工具中外，還包括一些開發(fā)相關(guān)的軟件設(shè)計、項目管理工具。偶的主要開發(fā)經(jīng)驗是Web開發(fā)，桌面開發(fā)和原型開發(fā)，對Mobile開發(fā)不熟悉，也就沒這方面的推薦了。
1，運(yùn)行平臺
常用的也就.net framework 1.1, 2.0, 和mono了，都是免費的。從功能、性能及安裝基礎(chǔ)來講，自然.net framework要優(yōu)于mono了。mono是開源的，.net framework類庫可以反編譯，從透明的角度講兩者都差不多。如果你想在非windows平臺上開發(fā)，或者想研究運(yùn)行時的實現(xiàn)，可以研究mono，否則還是用.net framework吧。
2，服務(wù)器
我用過的也就IIS5.0，IIS6.0，Apache加一個mod，還有mono的xsp，這也沒啥好比較的，自然首選IIS6.0了。不過IIS雖然免費，但是至少得windows server版本才運(yùn)行得爽，至少得花幾千元。XP上的IIS很不爽，據(jù)說也能裝全版IIS6.0，不過還是得折騰。開發(fā)用的話，用Apache加一個.net的mod，或者mono的xsp，還是挺好用的。Apache的缺點是對新版.net framework的支持較IIS6.0滯后。
3，IDE
tnnd，這個選擇空間也很小。首選自然是VS 2003或2005，如果VS 2005速成版將來免費的話，偶就選定這個了，或者選價格并不算高的VS 2005 專業(yè)版?？蓯核俪砂妗I(yè)版中沒單元測試，在這里BS微軟10000遍。堅決抵制VSTS版！
其它可選的有SharpDevelop和mono develop。對于不開發(fā)Web程序的初學(xué)者來說，用SharpDevelop其實也挺不錯的，集成的Nant，NDoc，NUnit都是很有用的工具。SharpDevelop沒斷點調(diào)試功能，但熟用NUnit的話可以彌補(bǔ)這一不足。如果對類庫理解得比較深入的話，采用SharpDevelop，生產(chǎn)力其實也挺高的――即使是進(jìn)行Web開發(fā)。SharpDevelop的缺點之一是暫時沒重構(gòu)功能，在下一個版本里會有。缺點之二是內(nèi)存占用比較大，還有性能比VS低得多，大項目，大程序可能不爽。我測試過，用SharpDevelop打開一個大于3M的C#源文件（嘿嘿！是csgl還是tao的，忘了），掛了；用VS 2003打開大概要花幾十秒。
btw，我個人認(rèn)為其實就用記事本寫中小型（<3000行）的C#程序，效率其實也挺高的，這時候會更加注意類的設(shè)計，思路會更清晰一些，當(dāng)然，速度會慢一些。
4，類庫和文檔
類庫是.net平臺的資產(chǎn)。目前.net下成熟的類庫比較少，和java比，最大的不足就是這里了。最常用的類庫當(dāng)然是.net framework了，其它各方面的類庫在網(wǎng)上都能搜索到一些。類庫的關(guān)鍵資產(chǎn)要素是dll和文檔?？次臋n要看一手資料，第一手資料就是源代碼或反編譯過來的代碼，然后就是各類的原始文檔，一般是chm格式的。如果看源代碼習(xí)慣的話，效率會很高，并且，建議用反編譯工具看代碼，不建議直接看源文件，原因其一是反編譯工具提供了很多有用的附加功能，其二是反編譯的代碼比源文件更真實。常用的反編譯工具是Reflector。
.net下的文檔是爽死了，比javadoc的pp多了。因此在寫代碼的時候應(yīng)該注意，多寫///注釋，然后用Ndoc自動生成chm文檔，多爽呀。
很多開源項目提供源代碼和少量的文檔，但它的源代碼中有大量的///注釋，可用NDoc自動生成chm文檔。即使沒有///注釋，采用NDoc生成文檔也是很值的。
5，數(shù)據(jù)庫
MS SQL Server Express版應(yīng)該是免費的，但標(biāo)準(zhǔn)版和企業(yè)版價格還是不低的，還是用開源的好。對功能有要求就用PostgreSql，沒要求就用MySql。偶現(xiàn)在是GIS項目用PostgreSql，一般項目用MySql。數(shù)據(jù)庫管理用EMS MySQL Manager Lite和EMS PostgreSql Manager Lite，免費，好用，界面很豪華，性能還行。
6，設(shè)計與建模
偶選定的UML建模工具是JUDE，2M大，免費但不開源，比ArgoUML功能多、好用。比Visio 的UML功能不知道強(qiáng)大多少倍，比Together也好用。缺點就是只是建模工具，和代碼不同步。另一個缺點就是不能自動生成文檔。不過偶喜歡這樣的工具，強(qiáng)大，體積小，靈活，方便。并且偶覺得它在設(shè)計時用就行了，具體的類的文檔用NDoc生成。JUDE是基于java的，得安裝java虛擬機(jī)。好像它跨平臺也不怎么樣，我在linux下沒運(yùn)行成功過。
開源或免費的數(shù)據(jù)庫建模工具試過很多，感覺都不成熟不好用，最后選擇了一個商業(yè)軟件――CASE Studio 2，價格100-300美元，功能很實用，支持很多數(shù)據(jù)庫，生成的文檔也很pp。
7，敏捷開發(fā)工具
NUnit――單元測試。
NAnt――build工具。前面已經(jīng)提及。
NDoc――文檔生成。前面已經(jīng)提及。
CruiseControl.Net ――持續(xù)集成，暫時還沒用過。
NUnit，NAnt，NDoc用的好的話，感覺非常爽，寫程序會有藝術(shù)家的感覺。
8，團(tuán)隊協(xié)作工具
版本管理：CVS和SVN，推薦SVN。客戶端推薦用TortoiseSVN――非?？蓯鄣男觚?。
Bug管理：偶選用的是BugTracker.NET，簡單，用ASP.Net寫的，小項目夠用了。
需求管理、項目管理、日程、經(jīng)費計算與管理：還是在用Word、Outlook、Excel。要免費的話可用永中Office試用版，一樣好用。
（二）、優(yōu)勢
1，性價比高。對于10人規(guī)模的團(tuán)隊，看看軟件成本：
運(yùn)行平臺：.net framework 1.1或2.0，免費
服務(wù)器：1套windows 2003 server版，數(shù)千元
IDE：1套VS 標(biāo)準(zhǔn)版或?qū)I(yè)版，數(shù)千元，其它用express版就行了
類庫和文檔：免費
數(shù)據(jù)庫：免費。用商業(yè)數(shù)據(jù)庫，讓客戶掏錢。
設(shè)計與建模：1套CASE Studio 2就行了，數(shù)千元
敏捷開發(fā)工具：免費
團(tuán)隊協(xié)作工具：1套MS Office（帶Visio的）就行了，數(shù)千元，其它人用永中。
整個下來，不足20000元。
2，易用性好
反正我的感覺是和商業(yè)軟件差不多或者稍差
3，易擴(kuò)展
上面工具大部分是開源的，并且很多工具之間協(xié)作性比較好，這樣可以用來定制適合自己的生產(chǎn)線。老外的那一套生產(chǎn)線，比如RUP，MSF及其相關(guān)工具，除價格貴外，其靈活性也不高，別人的生產(chǎn)線不一定適合自己用。這時上面工具的優(yōu)勢就出來了。
（三）、搭建軟件生產(chǎn)線
流程1：項目管理流程
用Office管理需求。用SVN進(jìn)行源代碼管理和文檔管理，BugTracker.NET進(jìn)行 Bug管理和事務(wù)管理。盡量將程序、文件、文檔的維護(hù)自動化。
流程2：開發(fā)管理流程
開發(fā)過程中所維護(hù)的文件越少越好。偶覺得應(yīng)該盡量少用UML圖寫文檔，只寫最關(guān)鍵的部分。類的文檔最好由NDoc直接生成。偶用UML工具的時間很少。寫代碼的過程就是類設(shè)計過程。不妨比較這兩個流程：（1）用例分析－>采用UML工具設(shè)計類－>由UML工具生成代碼或撰寫代碼－>重構(gòu)代碼，自動更新UML文檔。（2）用例分析－>撰寫代碼－>重構(gòu)代碼。第一個流程只有一個優(yōu)勢，就是人對圖形的理解比對代碼的理解更加直觀，但是多了很對累贅工作。第二個流程少了很多步驟，并且可以隨時根據(jù)代碼逆向工程出類圖出來，
我還是喜歡以代碼為基礎(chǔ)的流程。撰寫代碼也可分為2個過程，第一個過程是寫出一個代碼框架，所有的方法都是UNDO，寫出屬性，接口，寫出///文檔。這應(yīng)該是設(shè)計過程。這個過程基本上只產(chǎn)生、維護(hù)源文件。類圖可以通過visio逆向工程，類設(shè)計文檔可以通過NDoc自動生成，并且提供了一個測試基礎(chǔ)，可以根據(jù)這個測試基礎(chǔ)寫測試代碼了。測試代碼最好也只寫個框架，但是要寫好///注釋，然后生成測試文檔。這應(yīng)該是設(shè)計過程。第二個過程是實現(xiàn)過程，把類文檔和代碼框架提交給相關(guān)人，實現(xiàn)、測試、重構(gòu)......一切都自動進(jìn)行......整個過程中只有一份東西，就是源代碼，開發(fā)過程中的交付件應(yīng)該都從源代碼中自動生成。
數(shù)據(jù)庫腳本和文檔用CASE Studio 2維護(hù)。最后提交、上線、驗收都很好辦，所要的東西biaji一下子都出來了。要申報著作權(quán)直接從源代碼和chm文檔中弄一部分出來就夠了。
開發(fā)的核心是源代碼，所有文檔應(yīng)該體現(xiàn)在源代碼的結(jié)構(gòu)、關(guān)系和注釋中。控制整個開發(fā)流程的核心工具是Nant。要是能把用例分析過程體現(xiàn)在源代碼中就好了！