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