軟體項目管理
出自 MBA智库百科(https://wiki.mbalib.com/)
軟體項目管理（Software Project Management）
- 該條目對應的頁面分類是軟體項目管理。
目錄 |
所謂軟體項目管理就是為了使軟體項目能夠按照預定的成本、進度、質量順利完成，而對人員（People）、產品（Product）、過程（Process）和項目(Project)進行分析和管理的活動。軟體項目管理先於任何技術活動之前開始，並且貫穿於軟體的整個生命周期。
軟體項目管理的根本目的是為了讓軟體項目尤其是大型項目的整個軟體生命周期（從分析、設計、編碼到測試、維護全過程）都能在管理者的控制之下，以預定成本按期，按質的完成軟體交付用戶使用。而研究軟體項目管理為了從已有的成功或失敗的案例中總結出能夠指導今後開發的通用原則，方法，同時避免前人的失誤。
軟體項目管理的提出是在20世紀70年代中期的美國，當時美國國防部專門研究了軟體開發不能按時提交，預算超支和質量達不到用戶要求的原因，結果發現70%的項目是因為管理不善引起的，而非技術原因。於是軟體開發者開始逐漸重視起軟體開發中的各項管理。到了20世紀90年代中期，軟體研發項目管理不善的問題仍然存在。據美國軟體工程實施現狀的調查，軟體研發的情況仍然很難預測，大約只有10％的項目能夠在預定的費用和進度下交付。
1995年，據統計，美國共取消了810億美元的商業軟體項目，其中31％的項目未做完就被取消，53％的軟體項目進度通常要延長50%的時間，只有9％的軟體項目能夠及時交付並且費用也控制在預算之內。
軟體項目計劃是一個軟體項目進入系統實施的啟動階段,主要進行的工作包括:確定詳細的項目實施範圍、定義遞交的工作成果、評估實施過程中主要的風險、制定項目實施的時間計劃、成本和預算計劃、人力資源計劃等。
軟體項目管理過程從項目計劃活動開始，而第一項計劃活動就是估算：需要多長時間、需要多少工作量、以及需要多少人員。此外，我們還必須估算所需要的資源（硬體及軟體）和可能涉及到的風險。
為了估算軟體項目的工作量和完成期限，首先需要預測軟體規模。度量軟體規模的常用方法有直接的方法——LOC（代碼行），間接的方法——FP（功能點）。這兩種方法各有優缺點，應該根據軟體項目的特點選擇適用的軟體規模度量方法。
根據項目的規模可以估算出完成項目所需的工作量，我們可以使用一種或多種技術進行估算，這些技術主要分為兩大類：分解和經驗建模。分解技術需要劃分出主要的軟體功能，接著估算實現每一個功能所需的程式規模或人月數。經驗技術的使用是根據經驗導出的公式來預測工作量和時間。可以使用自動工具來實現某一特定的經驗模型。
精確的項目估算一般至少會用到上述技術中的兩種。通過比較和協調使用不同技術導出的估算值，我們可能得到更精確的估算。軟體項目估算永遠不會是一門精確的科學，但將良好的歷史數據與系統化的技術結合起來能夠提高估算的精確度。
當對軟體項目給予較高期望時，一般都會進行風險分析。在標識、分析和管理風險上花費的時間和人力可以從多個方面得到回報：更加平穩的項目進展過程；更高的跟蹤和控制項目的能力；由於在問題發生之前已經做了周密計劃而產生的信心。
對於一個項目管理者，他的目標是定義所有的項目任務，識別出關鍵任務，跟蹤關鍵任務的進展情況，以保證能夠及時發現拖延進度的情況。為此，項目管理者必須制定一個足夠詳細的進度表，以便監督項目進度並控制整個項目。
常用的制定進度計劃的工具主要有Gantt圖和工程網路兩種。Gantt圖具有悠久歷史、直觀簡明、容易學習、容易繪製等優點，但是，它不能明顯地表示各項任務彼此間的依賴關係，也不能明顯地表示關鍵路徑和關鍵任務，進度計劃中的關鍵部分不明確。因此，在管理大型軟體項目時，僅用Gantt圖是不夠的，不僅難於做出既節省資源又保證進度的計劃，而且還容易發生差錯。
工程網路不僅能描繪任務分解情況及每項作業的開始時間和結束時間，而且還能清楚地表示各個作業彼此間的依賴關係。從工程網路圖中容易識別出關鍵路徑和關鍵任務。因此，工程網路圖是制定進度計劃的強有力的工具。通常，聯合使用Gantt圖和工程網路這兩種工具來制定和管理進度計劃，使它們互相補充、取長補短。
進度安排是軟體項目計劃的首要任務，而項目計劃則是軟體項目管理的首要組成部分。與估算方法和風險分析相結合，進度安排將為項目管理者建立起一張計劃圖。
對於軟體開發項目而言，控制是十分重要的管理活動。下麵介紹軟體工程式控制制活動中的質量保證和配置管理。其實上面所提到的風險分析也可以算是軟體工程式控制制活動的一類。而進度跟蹤則起到連接軟體項目計劃和控制的作用。
軟體質量保證（SQA，Software Quality Insurance）是在軟體過程中的每一步都進行的“保護性活動”。SQA主要有基於非執行的測試（也稱為評審）、基於執行的測試（即通常所說的測試）和程式正確性證明。
軟體評審是最為重要的SQA活動之一。它的作用是，在發現及改正錯誤的成本相對較小時就及時發現併排除錯誤。審查和走查是進行正式技術評審的兩類具體方法。審查過程不僅步數比走審多，而且每個步驟都是正規的。由於在開發大型軟體過程中所犯的錯誤絕大數是規格說明錯誤或設計錯誤，而正式的技術評審發現這兩類錯誤的有效性高達75%，因此是非常有效的軟體質量保證方法。
軟體配置管理（SCM，Software configuration management）是應用於整個軟體過程中的保護性活動，它是在軟體整個生命周期內管理變化的一組活動。
軟體配置由一組相互關聯的對象組成，這些對象也稱為軟體配置項，它們是作為某些軟體工程活動的結果而產生的。除了文檔、程式和數據這些軟體配置項之外，用於開發軟體的開發環境也可置於配置控制之下。一旦一個配置對象已被開發出來並且通過了評審，它就變成了基線。對基線對象的修改導致建立該對象的版本。版本控制是用於管理這些對象而使用的一組規程和工具。
變更控制是一種規程活動，它能夠在對配置對象進行修改時保證質量和一致性。配置審計是一項軟體質量保證活動，它有助於確保在進行修改時仍然保持質量。狀態報告向需要知道關於變化的信息的人，提供有關每項變化的信息。
軟體項目管理和其他的項目管理相比有相當的特殊性。首先，軟體是純知識產品，其開發進度和質量很難估計和度量，生產效率也難以預測和保證。其次，軟體系統的複雜性也導致了開發過程中各種風險的難以預見和控制。Windows這樣的操作系統有1500萬行以上的代碼，同時有數千個程式員在進行開發，項目經理都有上百個。這樣龐大的系統如果沒有很好的管理，其軟體質量是難以想象的。
軟體項目可以是一個單獨的開發項目，也可以與產品項目組成一個完整的軟體產品項目。如果是訂單開發，則成立軟體項目組即可；如果是產品開發，需成立軟體項目組和產品項目（負責市場調研和銷售），組成軟體產品項目組。公司實行項目管理時，首先要成立項目管理委員會，項目管理委員會下設項目管理小組、項目評審小組和軟體產品項目組。
1、項目管理委員會項目管理委員會是公司項目管理的最高決策機構，一般由公司總經理、副總經理組成。主要職責如下：
（1）依照項目管理相關制度管理項目；
（2）監督項目管理相關制度的執行；
（3）對項目立項、項目撤消進行決策；
（4）任命項目管理小組組長、項目評審委員會主任、項目組組長.
2、項目管理小組項目管理小組對項目管理委員會負責，一般由公司管理人員組成。主要職責如下：
（1）草擬項目管理的各項制度；
（2）組織項目階段評審；
（3）保存項目過程中的相關文件和數據；
（4）為優化項目管理提出建議。
3、項目評審小組項目評審小組對項目管理委員會負責，可下設開發評審小組和產品評審小組，一般由公司技術專家和市場專家組成。主要職責如下：
（1）對項目可行性報告進行評審；
（2）對市場計劃和階段報告進行評審；
（3）對開發計劃和階段報告進行評審；
4、軟體產品項目組軟體產品項目組對項目管理委員會負責，可下設軟體項目組和產品項目組。軟體項目組和產品項目組分別設開發經理和產品經理。成員一般由公司技術人員和市場人員構成。主要職責是：根據項目管理委員會的安排具體負責項目的軟體開發和市場調研及銷售工作。
軟體項目管理的內容主要包括如下幾個方面：人員的組織與管理，軟體度量，軟體項目計劃，風險管理，軟體質量保證，軟體過程能力評估，軟體配置管理等。
這幾個方面都是貫穿、交織於整個軟體開發過程中的，其中人員的組織與管理把註意力集中在項目組人員的構成、優化；軟體度量把關註用量化的方法評測軟體開發中的費用、生產率、進度和產品質量等要素是否符合期望值，包括過程度量和產品度量兩個方面；軟體項目計劃主要包括工作量、成本、開發時間的估計，並根據估計值制定和調整項目組的工作；風險管理預測未來可能出現的各種危害到軟體產品質量的潛在因素並由此採取措施進行預防；質量保證是保證產品和服務充分滿足消費者要求的質量而進行的有計劃，有組織的活動；軟體過程能力評估是對軟體開發能力的高低進行衡量；軟體配置管理針對開發過程中人員、工具的配置、使用提出管理策略。因為大家對人力資源管理和軟體過程能力比較有興趣，下麵就詳細的對這兩方面展開討論。
從軟體工程的角度講，軟體開發主要分為六個階段：需求分析階段、概要設計階段、詳細設計階段、編碼階段、測試階段、安裝及維護階段。不論是作坊式開發，還是團隊協作開發，這六個階段都是不可缺少的。根據公司實際情況，公司在進行軟體項目管理時，重點將軟體配置管理、項目跟蹤和控制管理、軟體風險管理及項目策劃活動管理四方面內容導入軟體開發的整個階段。在20世紀80年代初，著名軟體工程專家B.W.Boehm總結出了軟體開發時需遵循的七條基本原則，同樣，在進行軟體項目管理時，也應該遵循這七條原則。它們是：
- 用分階段的生命周期計劃嚴格管理；
- 堅持進行階段評審；
- 實行嚴格的產品控制；
- 採用現代程式設計技術；
- 結果應能夠清楚地審查；
- 開發小組地人員應該少而精；
- 承認不斷改進軟體工程實踐的必要性。
1、平衡原則
在我們討論軟體項目為什麼會失敗時可以列出了很多的原因，答案有很多，如管理問題、技術問題、人員問題等等，但是有一個根本的思想問題是最容易忽視的，也是軟體系統的用戶、軟體開發商、銷售代理商最不想正視的，那就是：需求、資源、工期、質量四個要素之間的平衡關係問題。
需求定義了“做什麼”，定義了系統的範圍與規模，資源決定了項目的投入（人、財、物），工期定義了項目的交付日期，質量定義了做出的系統好到什麼程度，這四個要素之間是有制約平衡關係的。如果需求範圍很大，要在較少的資源投入下，很短的工期內，很高的質量要求來完成某個項目，那是不現實的，要麼需要增加投資，要麼工程延期；如果需求界定清楚了，資源固定了，對系統的質量要求很高，則可能需求延長工期。
對於上述四個要素之間的平衡關係最容易犯的一個錯誤，就是鼓吹“多快好省”四個字，“多快好省”，多麼理想的境界啊？需求越多越好，工期越短越好，質量越高越好，投入越少越好，這是用戶最常用的口號。
（1）多：需求越多越好嗎？
軟體系統實施的基本原則是“全局規劃，分步實施，步步見效”，需求可以多，但是需求一定要分優先順序，要分清企業內的主要矛盾與次要矛盾，根據PARETO的80-20原則，企業中的80%的問題可以用20%的投資來解決，如果你要大而全，對不起，你那20%的次要問題是需要你花費80%的投資的！而這一點恰恰是很多軟體用戶所不能忍受的。
（2）快：真能快起來嗎？
“快”是用戶、軟體開發商都希望的。傳統企業里強調資金的周轉情況，軟體企業里強調的是人員的周轉情況，開發人員應儘快做完一個項目再做另外一個項目，通過快速的啟動項目、結束項目來承擔更多的項目，來獲利。但是"快"不是主觀的拍腦袋定工期就可以完成的，工期的定義一定要基於資源的狀況、需求的多少與質量的需求來進行推算的。軟體畢竟需要一行代碼一行代碼的寫出來，他的工作量是客觀的，並非? quot;人有多大膽，地有多大產"式的精神鼓動就可以短期完成的。
（3）省：省到什麼程度？
“一分錢一分貨”，這是中國的俗話，他是符合價值規律的。甲方希望少投入，乙方希望降低自己的生產成本，省到乙方僅能保本的時候，再省，乙方就虧損了。
正視這四個要素之間的平衡關係是軟體用戶、開發商、代理商成熟理智的表現，否則系統的成功就失去了一塊最堅實的理念基礎。
企業實施IT系統的首要目標是要成功，而不是失敗，企業可以容忍小的成功，但不一定容忍小的失敗，所以需要真正理解上述四個要素的平衡關係，確保項目的成功。
2、高效原則
在需求、資源、工期、質量四個要素中，很多的項目決策者是將進度放在首位的，現在市場的競爭越來越激烈，"產品早上市一天，就早掙一天錢，掙的就比花的多，所以一定要多掙"，基於這樣一個理念，軟體開發越來越追求開發效率，大家從技術、工具、管理上尋求更多更好的解決之道。
基於高效的原則，對項目的管理需要從幾個方面來考慮：
- 要選擇精英成員
- 目標要明確，範圍要清楚
- 溝通要及時、充分
- 要在激勵成員上下工夫
3、分解原則
“化繁為簡，各個擊破”是自古以來解決複雜問題的不二法門，對於軟體項目來講，可以將將大的項目劃分成幾個小項目來做，將周期長的項目化分成幾個明確的階段。
項目越大對項目組的管理人員、開發人員的要求越高，參與的人員越多，需要協調溝通的渠道越多，周期越長，開發人員也容易疲勞，將大項目拆分成幾個小項目，可以降低對項目管理人員的要求，減少項目的管理風險，而且能夠充分地將項目管理的權力下放，充分調動人員的積極性，目標會比較具體明確，易於取得階段性的成果，使開發人員有成就感。
作者主管過的一個產品開發項目代號為SB，該項目前期投入了5人做需求，時間達3個多月，進入開發階段後，投入了15人，時間達10個月之久，陸續進行了3次封閉開發，在此過程中經歷了需求的裁剪、開發人員的變更、技術路線的調整，項目組成員的壓力極大，大家疲憊不堪，產品上市時間拖期達4個月。項目完工後總結下來的很致命的一個教訓就是應該將該項目拆成3個小的項目來做，進行階段性版本化發佈，以緩解市場上的壓力，減少項目組成員的挫折感，提高大家計程車氣。
4、實時控制原則
在一家大型的軟體公司中，有一位很有個性的項目經理，該項目經理很少談起什麼管理理論，也未見其有什麼明顯的管理措施，但是他連續做成多個規模很大的軟體項目，而且應用效果很好。作者一直很奇怪他為什麼能做的如此成功，經過仔細觀察，終於發現他的管理可以用"緊盯"2字來概括，即每天他都要仔細檢查項目組每個成員的工作，從軟體演示到內部的處理邏輯、數據結構等，一絲不苟，如果有問題，改不完是不能去休息的。正是在他這種簡單的措施下，支撐他完成了很多大的項目，當然他也是相當的辛苦，通常都是在凌晨才去休息。我們並非要推崇這種做法，這種措施也有他的問題，但是，這種實踐卻說明瞭一個很朴實的道理：如果你沒有更好的辦法，就要辛苦一點，實時控制項目的進展，要將項目的進展情況完全的實時的置於你的控制之下。
上述的方法中對項目經理的個人能力、犧牲精神要求是很高，我們需要有一種進行實時控制項目進度的機制，依靠一套規範的過程來保證實時監控項目的進度。如在微軟的管理策略中強調每日構建，這確實是是一種不錯的方法，即每天要進行一次系統的編譯鏈接，通過編譯鏈接來檢查進度、檢查介面、發現進展中的問題、大家互相鼓勵互相監督。
實時控制確保項目經理能夠及時發現問題、解決問題，保證項目具有很高的可見度，保證項目的正常進展。
5、分類管理原則
對於不同的軟體項目其項目目標差別很大，項目規模也是不同的，應用領域是不同的，採用的技術路線差別也很大，因而，針對每個項目的不同特點，其管理的方法、管理的側重點應該是不同的。就像古人講的，"因材施教"，"對症下藥"。對於小項目你肯定不能象管理大項目那樣去做，對於產品開發類的項目，你也不可能象管理系統集成類的項目那樣去做，項目經理需要根據項目的特點，制訂不同的項目管理的方針政策。如，下表是作者為一家應用軟體公司制訂的項目管理的方針：
在該案例中，將項目分成了訂單類項目與非訂單類項目，非訂單類項目是指由公司根據市場的需求開發一個標準產品的項目，而訂單類是指針對某個具體的客戶定製軟體的項目，訂單類的項目根據需要協調的資源的範圍有劃分成了公司級、部門級、個人級三類，非訂單類根據估算的工作量的大小也分成了A、B、C三類，估算的工作量超過720人天的為A類，超過360人天的為B類，360人天以下的為C類。不同類的項目管理的側重點是不同的，從立項手續的完備性、計劃的嚴格層度、周報的完備層度、規範的嚴格層度、跟蹤的實時性、是否進行階段總結、是否核算項目成本、是否嚴格進行階段評審等多個方面來考慮，以確保管理的可行性。
6、簡單有效原則
項目經理在進行項目管理的過程中，往往會得到開發人員這樣的抱怨"太麻煩了，浪費時間，沒有用處 "，這是很普遍的一種現象。當然這樣的抱怨要從2個方面來分析，一方面從開發人員本身可能存在不理解，或者逆反心理的情況，另一方面，項目經理也要反思：我所採取的管理措施是否簡單有效？搞管理不是搞學術研究，沒有完美的管理，只有有效的管理，而項目經理往往試圖堵住所有的漏洞，解決所有的問題，恰恰是這種理想，會使項目的管理陷入一個誤區，作繭自縛，最後無法實施有效的管理，導致項目的失敗。
7、規模控制原則
該原則是和上面提到的其他原則相配合使用的，即要控制項目組的規模，不要人數太多，人數多了，進行溝通的渠道就多了，管理的複雜度就高了，對項目經理的要求也就高了。在微軟的MSF中，有一個很明確的原則就是要控制項目組的人數不要超過10人，當然這不是絕對的，也和項目經理的水平有很大關係。但是人員"貴精而不貴多"，這是一個基本的原則，這和我們上面提到的高效原則、分解原則是相輔相成的。
寫的很好！