軟體開發項目管理的模式概述

軟體開發項目管理的模式概述

出處：CSDN

作者：不詳

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模式相似的結論，就是在項目管理實施過程中沒有一個一成不變的規章制度，而要根據項目的規模的大小和開發團隊規模靈活确定，當一個項目比較小時，事先的構架設計和計劃就可以比較少，而當一個項目比較大時，事先的構架設計和計劃以及規章制度就要相對增大，才能更有利于項目的順利實施。

管理流程設計的一些準則和指南

團隊成員之間的融洽交往是任何項目管理不可缺少的。有時非得用面對面的交流

規章制度太多會變成繁重的負擔。選擇對開發的靈活性和軟體品質最有利的規章去執行

通常情況下大型的團隊管理規章可以多些

将自我調節的能力設計利用到流程管理中去

總結

不同大小的項目可以采取不同的、能夠最佳适合于它的管理方法

靈活性模式有很多傳統模式所沒有的靈活性

靈活性模式對建立團隊文化很有效

靈活性模式也有它的局限性

采用時可以考慮逐漸采取其中的一部分先執行，根據效果再做調整