70年代基本上一個軟件在項目規模上比較小，一兩個人基本可以勝任一個軟件的開發，這樣的人被稱為hero,認為是英雄主導著一個軟件項目的進度，但隨著業界對軟件依賴的增加，軟件在規模、復雜度上都有較大的增加，一兩個人已經無法勝任工作的需要，而且，開發人員一旦離開公司，那么整個項目甚至整個公司可能會陷入癱瘓的地步。所以，在80年代初，軟件公司開始重視軟件開發的項目管理，把其他行業成功的項目管理經驗開始引入軟件開發領域。

美國PMI，Project Management Institute(項目管理研究所)在軟件工程項目管理方面起到了很大的推動作用，每年發行一本PM book。微軟在軟件開發管理上也是基本參照傳統的軟件開發模式來做的。
除企業對軟件開發項目管理的推動作用外，學術界也推出了有關的管理模式，如CMM（軟件成熟度模型）。CMM在部分軟件企業得到了推崇，但是并不是所有的軟件企業都采用CMM，微軟本身就沒有采用。盡管如此，微軟本身的管理方法與CMM也有異曲同工的地方。
業界也在推行自己的管理模式，RUP,Six Sigma,ISO,etc.關鍵是軟件開發管理中的關鍵的部份要掌握好。
傳統模式在美國很多公司都使用過，對這些開發模式不能盲目崇拜。
--------------------------------------------------------------------------------------------------
傳統的和其他的管理模式受到挑戰
被認為太死板和官僚
效率高低受到質疑
太重規章制度項被認為是開發的枷鎖
在執行起來太過于繁重
可能違背需要智力高度集中的軟件開發工程管理的特性
因此這幾年來開始有人唱反調

軟件開發具有自己的特點

*********************************************************
傳統的項目管理模式

根據PMI觀點，傳統的項目管理通常具有幾個固定的階段：
第一項目啟動階段，第二計劃階段，項目的規模、項目的需求、項目的估算，第三階段設計規范書(軟件開發的藍圖)，第四項目時間表(schedule)。樣品的試開發。第五執行階段，編程開發。同時fix bugs.第六控制階段，對發現的錯誤進行回車重新開發。第七結束階段。

啟動、計劃、執行、控制、結束
這五個階段的傳統的項目管理模式在業界使用的比較普遍。

靈活性模式的概念和實踐
1、輕型的計劃(Light Weight Planning)
信奉改變(Embrace Change):從整個的項目的開始起就期望計劃、需求、和設計都會改變。
整個開發過程有客戶的經常參與，甚至邀請客戶來到開發團隊的工作處，對正在進行開發的半成品使用、審核、提意見。
客戶直接參加項目的計劃的修改
整個開發計劃是個不斷更新的過程

輕型計劃的象征：沒有事先的計劃
加州大學俄凡分校在校園的時候，他們只蓋了大樓，鋪了墓地，卻不建筑人走路的路邊人行道。第二年，建校的人回來，在草地上由人們走出來的路徑上，修建了讓走路的人行道。Perl語言就是這樣一類的語言，它并沒有事先全設定好的規則，Perl語言就是那些在墓地上由人們走出來的人行道。

計劃是一個連續性的過程，而不是一個一次性的過程。

2、經常性的發行(Rrequent Releases)
短期的重復開發周期
采取所謂的“時間盒”方法--將預定的周期鎖定為一個發行周期
保持產品接近發行的狀態

好處是：
第一為團隊提供一種完成任務的快樂和成就感；
第二給用戶提供了在開發早期進行回饋的機會。

3、簡化的設計(Simple Design)
先對那些已經確定了的功能進行設計
使用YAGNI(You aren't going to need it)
意識到任何多余的功能，一旦加入到軟件產品中，會增加修改和維護的費用。
好處是便于返車重新設計和開發。每次改動都可能會影響其他部分的功能組件。

4、以測試為驅動的開發(Testing Driven Development--TDD)
編寫產品的程序前先寫測試的程序
單元測試(Unit Test)應該全部自動化
單元測試的運行應該成為開發的日常工作

好處是：
第一保證測試部分能保質保量完成
第二以這種方法寫出的程序質量較高

5、重新組合(Refactoring)
重組：在不改變功能和行為的前提下，對軟件的內部結構為更容易理解和更方便修改而進行設計和編程上的改動。
采用漸進式的設計方式來逐漸完善程序

好處是：
第一幫助推動漸進式的設計方式，使得軟件的避免一次性做完，卻又帶有費用昂貴的必需的改動
第二常常重組，再加上利用TDD，改動的費用會降低

何時進行重組？
Martin Fowler:
當你發現你必須在一個軟件程序里加一個新的功能、但現有的程序的結構卻無法讓你奶方便地加入這個新的功能的時候，你應該先重新組合現有的程序，使得經能夠讓你方便地加任何新的功能，然后再加入你想加的新功能。

6、連續性的整合(Continuous Integration)
將開發團隊多人開發的各功能組件進行整合，最后生成完整的軟件系統或產品，應該是一個經常進行的、連續不斷的過程。
每天或每幾個小時進行總匯編和產品建造(Daily Build)

好處：
第一幫助開發團隊及時發現Build Breaker并采取糾正措施
第二對任何由于設計差錯無法完善地與整個系統進行整合的功能組件能及時進行設計改動

7、及時文件編輯(Just-In-Time Documentation)
將產品或系統的使用手冊、維護條例、使用參考等等一系列文檔根據各功能開發的進展進行編輯
趁著概念新鮮明確，將它們寫入文檔

好處是：
第一避免編輯多余的不必要的文檔或不必要的內容
第二，但是也要注意不要將文檔工作放到最后，而造成文件內容缺乏或遺漏。

軟件開發管理模式的簡單介紹和比較

Traditional(Waterfall)
RUP
CMM
Scrum
ASD
Crystal
eXtreme(XP)
DSDM
MSF(Microsoft Solution Framework)
自scrum后為靈活性模式

SCRUM

由Ken Schwaber和Jeff Sutherland提出和倡導
是一種極為輕型的靈活性模式的翻版
非完整的：沒有整個流程的定義
采用所謂的"sprints"，即一般是一個月為周期，來進行循環式的短期性的開發和發行管理
每天進行15分鐘的團隊“scrum會議”
采用每天進行項目的最新狀態匯報，發表“burn down graph”
適合于整個開發團隊在同一個大房間里一塊工作

scrum本意是指橄欖球在開賽前的手拉手聚在一起商議進攻方案，在這里是指項目管理的模式，指每天在開始工作前要所有團隊成員在一起開會，商討當天的工作和遇到的問題。

Adaptive Software Development(ASD)
由Jim Highsmith提出和倡導
也是一種輕型的靈活性模式，強調在混亂的邊緣上爭取平衡
不要求執行者完全按照流程規則來做
在項目周期里安排一個學習階段，具體解決哪些是重要的開發任務
將項目的歷程分成3個階段：思索、合作、學習(speculate,collaborate,and learn)
講究在合作階段進行循環式的重復漸進，采取“時間盒”(TimeBoxed)的方法

Crystal
由Alistaire Cockburn提出和倡導
靈活性模式的一種，尊重不同大小的項目在管理上需要有不同程度的正式性管理規章，強調在完成目前的開發項目的同時，要將眼光放在開發團隊和企業未來的位置
使用幾個不同的管理方式：透明、黃色、桔黃、紅色等模式
采用輕型化的規章制度
比較注重項目文檔的用途，要求管理人員使用各種文件來幫助管理

eXtreme Programming(XP)
由Kent Beck,Ward Cunningham,Ron Jeffries提出和倡導
在所有的靈活性管理模式中是最著名的
使用所謂的故事卡進行項目的計劃規劃
要求在開發過程中一直有客戶的參與
很短的開發周期：任何一個開發分段都不超過3個星期
群體式負責制：任何人可以參與任何部分的開發
使用重組(Refactoring)來進行漸進式設計
采用TDD和連續性整合
要求每周40小時工作時間

Dynamic Systems Development Method(DSDM)
是一個通常由來推動的管理方法
將開發周期分成5個部分：可行性認證、商業需求認證、功能模式循環、設計和建造循環、以及最終的開發
是一種偏向于繁重規章制度的模式
開發的計劃和設計采取漸進式的
目前有一些商業工具可以用來幫助使用這種方法進行項目管理
類似RUP，但是有明確的風險管理指南，能達到較好的靈活性
這個方法不是很常用，與其他幾種方式相比知名度較小，使用較少。

MSF-Microsoft Solutions Framework
由Randy Miller,Paul Haynes提出，微軟倡導
是基于傳統模式的基礎上發展起來的
屬于比較正式的模式，但最新版本包含了靈活性的模板，加入了使用者角色(Personals)的概念
推行一個從角色到使用方案的設計流程
開發過程采用循環型的3星期的周期
要求單元測試的程序與開發程序的原代碼一起提交
要求100%的原代碼執行測試(Code coverage)

How Much architecting is enough?(到底應該做多少事先的構架設計和計劃？)
靈活性與紀律性(指規章制度的嚴肅性嚴謹性)的平衡，兩位作者做了一個調查，發現了與crystal模式相似的結論，就是在項目管理實施過程中沒有一個一成不變的規章制度，而要根據項目的規模的大小和開發團隊規模靈活確定，當一個項目比較小時，事先的構架設計和計劃就可以比較少，而當一個項目比較大時，事先的構架設計和計劃以及規章制度就要相對增大，才能更有利于項目的順利實施。

管理流程設計的一些準則和指南
團隊成員之間的融洽交往是任何項目管理不可缺少的。有時非得用面對面的交流
規章制度太多會變成繁重的負擔。選擇對開發的靈活性和軟件質量最有利的規章去執行
通常情況下大型的團隊管理規章可以多些
將自我調節的能力設計利用到流程管理中去

總結
不同大小的項目可以采取不同的、能夠最佳適合于它的管理方法
靈活性模式有很多傳統模式所沒有的靈活性
靈活性模式對建立團隊文化很有效
靈活性模式也有它的局限性
采用時可以考慮逐步采取其中的一部分先執行，根據效果再做調整