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