個人的軟件項目管理體會

申請免費試用、咨詢電話：400-8352-114

關鍵字：軟件項目管理，需求管理，進度管理，成本管理，配置管理，風險管理

前言：現(xiàn)在的市場上充斥著各種各樣的關于軟件項目管理的書，我不大喜歡看這一類的書本，一方面這些書本都是國外書籍的中譯本，有的地方翻譯的可能也不是很符合中國用語的習慣，看起來可能會覺得難于理解（大量的晦澀英文學術專用語，不翻譯也就算了，翻譯過來了就完全不知道在說什么了），枯燥乏味，二來也覺得看了也不是很實用，所以我個人不大看這一類的書。
　　經(jīng)過幾年的磨練，從編碼開始終于稍微的了解到了一些軟件項目管理的具體內容，以及軟件項目管理實施步驟，如何實施。以我個人的理解總結了下面幾個部分。

一．需求管理

客戶需求管理

　　天大地大，需求最大。對于我們軟件開發(fā)人員來說，客戶的需求也應該是最大的，不僅僅因為客戶是我們的衣食父母，也是我們軟件開發(fā)人員成長的催化劑。我們不是End-User，所以有的時候關于某個特定系統(tǒng)上的具體細節(jié)可能是我們沒有辦法考慮到的，是在我們的領域里可能沒有辦法想象得到的，這個時候我們就必須要通過實際應用系統(tǒng)的End-User，也就是我們項目的最終客戶來了解具體的客戶需求。對于一個缺乏需求管理的軟件項目而言，必定會導致系統(tǒng)不能實現(xiàn)預期的功能而需要在后期進行昂貴的修正，使得項目拖期、產生嚴重的質量問題與超出項目預算的現(xiàn)象。
　　了解了客戶的需求，可以讓我們在軟件的開發(fā)過程中少走很多的彎路，縮短軟件開發(fā)的周期，了解了客戶的需求，能夠提高軟件的友好性，易操作性，易用性，從而來提升軟件的質量。

需求成本管理

　　對于客戶的需求，我們要盡量地予以滿足，但也不是一味地不顧技術實現(xiàn)上的困難而遷就客戶的無理要求，在需求管理進行的同時，我們也不能忽略了成本問題。因為每一個功能的實現(xiàn)都需要我們花費時間去努力的。做需求管理的人員要和客戶進行很好的溝通，在成本和需求之間找到平衡點。這些話說起來是很輕松的，做起來是絕對的不輕松，面對客戶你必須要保持涵養(yǎng)，而你說面對的客戶可能是一點都了解什么是軟件，或者說是我做這個東西需要多少人力物力，而需求管理人員就是要對客戶的需求進行必要的補充說明（基本上應該站在為減少成本，提高質量的立場上）。

需求內容傳達

　　而在有了具體的需求以后，然后需要和我們的軟件設計人員進行溝通，務必做到使他們清楚地知道客戶需要什么，確定我們的航向。

概括所以在項目管理的組成中，需求管理的位置是很重要的，他們有著橋梁的作用，接通了客戶需求和軟件開發(fā)之間的道路。

二．進度管理

進度管理

　　在進度管理這個呈面上其實有兩點，一點是總體進度，另一點就是個人進度了，而我們的Project 進度卻是建立在個人進度的基礎上的。

　　很多的人可能會以為，進度管理就是leader或者說是Project manager（PM）的事情，而與團隊的其他開發(fā)人員毫無關系，其實，個人認為這樣的認識是非常的錯誤的。開發(fā)人員和所有過程都應該是有關聯(lián)的，并不存在著什么什么是某某人的事情這樣的說法。

　　總體的進度應該由PM來控制和調整，而個人的進度卻是軟件開發(fā)人員個人的責任和職責所在，有很多時候軟件的開發(fā)人員可能會抱怨，在原有工作時間段里，開發(fā)的時間本來就少，每天又讓我們寫這種毫無意義的個人進度報告，這樣難道不是浪費了我們更多的時間嗎！

　　其實不然，一個精英的團隊固然重要，但是沒有良好的管理和溝通，統(tǒng)籌全局的管理，那么擁有再精英的團隊也是白搭。開發(fā)人員在很多時候都是站在自己的模塊里，或者說是以自己出發(fā)點進行思索，他們之間可能存在著相互間的溝通意識，但也只是個別人員之間的交流，并不能從根本上把握全體進度，也無法對進度作必要的分析和調整。而開發(fā)成員的個人開發(fā)進度報告匯總以后，能夠讓PM清楚的知道什么地方存在著問題，從而從工程整體上調整進度，決定相應的對策。

　　建議在軟件開發(fā)的過程中，不管項目的大小我們都應該抽取0.5-1.0小時的時間來寫一份個人的進度報告，而在個人的進度報告上上面應該有清晰的個人進度，存在問題，準備如何解決等等記述，總之，一句話，報告要簡明扼要能夠清楚地反映個人的進度狀況以及存在的問題。

　　進度不是個人的事情，而是整個開發(fā)團隊的事情。個人進度和全體進度只是著眼點不一樣了吧。它所以反映的實質都是一樣的，而個人進度更是全體進度的基礎，沒有了個人進度何談全體進度。同時個人進度管理也是軟件開發(fā)人員的自我管理，是進度控制的最重要組成部分，個人進度的狀況好壞直接影響到團隊全體的進度推進狀況。

成本管理

　　作為PM不僅僅要把握全體的進度，更加要把握住開發(fā)的成本，如果開發(fā)的成本超過了，那對于我們的開發(fā)來說不能盈利，而不能盈利的開發(fā)也就意味著失敗。

　　項目上的反反復復，開發(fā)人員加班費的支出，不僅加大了開發(fā)的費用，同時也給員工帶來了身體、精神上的雙重疲憊，直接導致個人抵抗力、免疫力的下降，更可能會造成員工身體上的隱藏疾病。同時也帶動著相應的管理費用也隨之增加了。這些都會使得我們軟件的成本增加。

問題管理

　　問題管理其實是應該包含在進度管理里面的，但是它又有點特殊，所以把它單獨拉出來了。
　　我們在開發(fā)過程中不可能是一帆風順的，可能不時地會遇到各種各樣的問題，而如何來解決問題，或者說是如何想辦法盡早的解決問題，這個才是關鍵。而其中的最關鍵是不能有了問題而一聲不響，悶頭苦干，結果幾天下來以后，卻發(fā)現(xiàn)自己還是站在原地，而就算是你通過了幾天的努力完成了這個難題。但是這樣就是不是意味著你的成功了呢！不時的，這樣的結果是不但自己的進度沒有辦法完成，更加延誤了整體的開發(fā)進度，別的成員或者是小組就可能因為你一聲不響地沒有成果的努力而不能再繼續(xù)下面的開發(fā)。應該說軟件開發(fā)過程中遇到問題一聲不響、埋頭苦干的做法是很愚蠢的，軟件開發(fā)要求的不是個人英雄主義精神而是團隊的整體合作精神。缺乏團隊的意識的個人和team必定是一個失敗的開始。

　　就開發(fā)人員而言，一旦碰到了難以解決的問題，不僅要自己努力調查，想辦法解決，一方面也要把存在的問題向PM反映，讓PM能夠知道存在的問題，而PM可以在進度會議、或者召開臨時緊急會議，把問題擺出來，通過大家來尋求解決的方案。一個人的力量畢竟是有限的，而個人的英雄主義卻是團隊開發(fā)的極大阻礙。

三．配置管理

是什么

　　關于配置管理（Software Configuration Management-簡稱SCM）的概念在各類書籍中都能夠看到，大部分的書籍都是從英文翻譯過來的，而翻譯書籍的人可能并不一定是和計算機學科有關聯(lián)的，就算是也不一定在配置管理上有一定的經(jīng)驗。所以我想并不是每一個從事軟件開發(fā)的人員都能夠確切的理解它、把握它。概念的東西畢竟都是虛幻的，只有實際的運用了才能夠變成自己的東西。

　　書上的定義我就不想說了，有興趣的話大家可以去看書。我在這里想說說自己對于配置管理的看法和理解。配置管理可以簡單地一句話說成是版本控制管理。而什么是版本控制，我想在使用計算機的人應該都會知道軟件版本的概念，而我們的配置管理就是要對軟件的版本進行控制管理。這個就是我們通常意義上說的配置管理了。而真正在團隊開發(fā)中的配置管理并不僅僅是版本的控制管理，還應該涉及到代碼協(xié)調、履歷追蹤、品質檢查等等細節(jié)的問題。

為什么

　　為什么我們要在軟件的開發(fā)過程中引入配置管理？其實不為什么，只是我們需要所以我們引入。在個人軟件開發(fā)中只要你覺得你的水平夠高，肯定不會發(fā)生Rollback，或者你只是在制作1+1=2這一類的簡單程序時我想你也可能用不到配置管理。

　　在前面我也曾經(jīng)提到過，軟件的開發(fā)是team行為，是合作，而不是個人英雄主義的自我表現(xiàn)，不可否認在小項目上存在著個人軟件開發(fā)，但是我想就算是個人軟件的開發(fā)（簡稱PSP：Personal Software Programming-英文全稱不知道是不是這樣的，不大記得了）也不得不使用到配置管理。

　　有人把配置管理稱為軟件開發(fā)的一種藝術，以前在老外寫的一本書上看到過，N多年以前的事情了，具體是什么書名已經(jīng)不記得了。其實這樣的說法也不算為過，配置管理就是對軟件開發(fā)過程中的產品（這里為什么說產品，而不是代碼，因為我們的軟件開發(fā)還包括各類文檔，會議記錄等等）進行標識、追蹤、控制的過程，目的就是為了減少一些不可預料的錯誤，提高生產率。

怎么做

　　怎么做就是要用到一些軟件開發(fā)過程中使用的配置管理的工具了。大概在七十年代加利福利亞大學的Leon Presser教授就撰寫了一篇論文，提出控制變更和配置的概念，之后他又成立了一家名為軟件工具的公司，開發(fā)了自己的配置管理工具：CCC，這也是最早的配置管理工具之一。之后，隨著軟件開發(fā)規(guī)模的逐漸增大，越來越多的公司和團隊意識到了軟件配置管理的重要性，而相應的軟件配置管理工具也如雨后春筍一般，紛紛涌現(xiàn)，早期比較有代表性的有：Marc Rochkind的SCCS(Source Code Control System)和Walter Tichy的RCS(Revision Control System)，這兩種工具對日后的配置管理工具的發(fā)展做出了重大的貢獻，目前絕大多數(shù)廣泛使用的配置管理工具基本上都是基于這兩者的設計思想和體系架構。而如今我們最為常用的，且使用簡單的要算VSS（Microsoft Virsual Source Safety）、CVS（Configuration Version System）了，此外還有一些價格昂貴、使用復雜的，比如：CCC Harvest、ClearCase等（需要一個專門的配置庫管理員負責技術支持，還需要對開發(fā)人員進行較多的培訓，可以說不適合我國的國情）。

　　VSS可能是國內目前使用的最多的配置管理軟件之一，其實在國外很多的人都喜歡使用CVS。為什么，因為CVS是free的，而微軟的VSS是要money的，為什么國內還是有很多人使用VSS，原因我想大家都明白我就不說了。

　　其實沒有配置管理工具，我們手工也能對軟件的配置進行管理，只不過很繁瑣，浪費了大量的人力物力，所以我們使用配置管理工具，而要成為一個好的配置管理工具應該具備什么樣的功能：
并行開發(fā)支持 - 要求能夠實現(xiàn)開發(fā)人員同時在同一個軟件模塊上工作，同時對同一個代碼部分作不同的修改，即使是跨地域分布的開發(fā)團隊也能互不干擾，協(xié)同工作，而又不失去控制。（對于這一點來說可能CVS比VSS做的更好，如果VSS不使用輔助工具SOS（Source Offsite）的話，那個公司或者是團隊會把自己的VSS庫共享到Internet上）

履歷管理 - 也就是修改的歷史記錄的可追蹤性。能夠明確地知道什么時候，誰作了什么，為什么怎么做。從而達到管理和追蹤開發(fā)過程中危害軟件質量以及影響開發(fā)周期的缺陷和變化。
版本控制 - 版本控制中最重要的一個概念就是Rollback，能夠簡單，明確地取得軟件開發(fā)期間的任何一個歷史版本。
、
過程控制 - 能夠貫徹、實施開發(fā)規(guī)范，包括訪問權限控制、開發(fā)規(guī)則的實施等。
產品發(fā)布管理 - 軟件開發(fā)過程中的一個關鍵活動是提取工件的相關版本，以形成軟件系統(tǒng)的階段版本或發(fā)布版本，我們一般將其稱為穩(wěn)定基線。一個穩(wěn)定基線代表新開發(fā)活動的開始，而一系列定制良好的活動之后又會產生一個新的穩(wěn)定基線。有效地利用此項功能，在項目開發(fā)過程中可以至始至終管理、跟蹤工件版本間的關聯(lián)。

　　本來談一點關于VSS和CVS的配置和應用的，可是想想寫起來會很多，而且還要貼圖什么的，夠麻煩的所以等以后有興趣了再補上。

二．風險管理

是什么

　　項目管理中最容易被忽略而且是最難以管理的環(huán)節(jié)。在很多的情況下，許多人都不知道風險管理到底應該做些什么。其實風險是自始至終貫徹整個軟件的開發(fā)過程的，沒有一個做項目的team可以自豪地聲稱自己的開發(fā)沒有任何風險。

　　什么是軟件開發(fā)過程中所謂的風險，簡單地理解可以認為是對軟件開發(fā)過程中遇到的資金和進度等問題對項目的影響。風險的產生常常會使我們的進度遲緩，成本增加，甚至是軟件項目無法實現(xiàn)。

　　我們可能無法根除風險，但是我們如果加強對風險產生的認識，對項目產生的風險進行有效的管理，就可以從最大限度上減少風險的發(fā)生，而這個就是我們風險管理的主題了。

面對風險的態(tài)度

　　很多的項目組可能不大注重風險管理，往往是到了風險確確實實地發(fā)生了，才回過神來開始面對，采取緊急的補救措施，試圖能夠快速的糾正，而這種被動的“救火”模式的風險認識存在著極大的危險，就是當對于風險的撲救失敗以后可能會使得我們的項目處于水深火熱之中。個人認為這種撲救的行為有點類似于寓言上所說的“亡羊補牢”。這種被動的風險策略是不可取的。

　　既然提到了風險管理，我們就要在風險尚未產生、形成之前，對風險進行辨識，并且評估風險出現(xiàn)的概率已經(jīng)它們能夠產生的影響，按風險有高到底排序，有計劃地管理。這種做法正好和“亡羊補牢”式的被動風險管理方式相反，我們在這里采取了主動出擊，就是這樣做，我們也并不能從根本上防止未知風險的產生，我們能做的只是減少風險發(fā)生的可能，所以說風險的管理和我們的認知以及經(jīng)驗有一點的聯(lián)系。

風險管理的要件

在計劃項目書中寫清如何進行風險管理。
在項目的預算中必須包含風險解決所需要的經(jīng)費，已經(jīng)它們可能產生的影響。
認識到風險在整個項目中是一個連續(xù)的過程，需要在項目進程中不斷地進行。
風險管理計劃（風險如何識別，量化風險，應對策略，風險監(jiān)控）