淺談軟件工程項目管理原則

時間 2019-11-19

標籤淺談軟件工程項目管理原則简体版

原文原文鏈接

　　在軟件工程飛速發展今天，軟件項目管理，與其稱之爲一項工程，倒更不如說是一門藝術。在這個過程當中，不只要根據軟件項目的具體環境中巧妙整合軟件技術，經濟學和人際關係，更好考慮到高人員密集度，長時期跨度下可能出現的各類風險和問題。最近，根據對600多家公司的調查代表，35%的公司至少有一個失控的軟件項目。一方面，順序的，經典的流程驅動的瀑布模型使得人們在理解其風險和影響以前，過分地提出具備約束力的需求規範中的軟件功能。另外一方面，代碼主導的開發過程，每每誘使企業過度注重功能複雜和代碼實現，而忽略了需求，工期，質量，資源等因素間的平衡。工做時"用程序代替用戶需求"，其結果必然如目前媒體"程序員生存情況"所言，以開發人員在時間的犧牲爲代價來換取項目的結束。無數軟件開發的殘酷的現實告訴咱們：沒有規則的軟件開發過程帶來的只多是沒法預料的結果。如何改善咱們的軟件開發管理，其實有許多的原則和經驗值得咱們爲之借鑑。程序員

　　一.平衡原則工具

　　在咱們討論軟件項目爲何會失敗時能夠列出不少的緣由，如管理問題、技術問題、人員問題等，可是有一個根本的思想問題是最容易忽視的，也是軟件系統的用戶、軟件開發商、銷售代理商最不想正視的，那就是：需求、資源、工期、質量這四個要素之間的平衡關係問題。結合實際，咱們能夠通俗地理解這四者之間彼此的聯繫，需求的增多，必然會帶來資源消耗的增多和工期的延長；而用戶的需求又與工期密切關聯，用戶不但願工程交付過晚；相對而言，追求更高的質量，須要咱們投入更多的人力物力資源，甚至更長的工期；一樣，一個高質量的產品，也不是盲目得趕工期，多投入就能夠完成的。這就要求咱們在實際中考慮平衡需求，資源，工期，質量並獲得各方面均衡的一個最優解。在軟件項目中咱們不只僅是關注項目的進度，質量，範圍和成本四要素的平衡。還須要關注人員角色分工的平衡，冒險和保守的平衡，外部和內部的平衡，紀律和靈活性間的平衡等等。任何一個方面失去平衡，項目均可能處於危險中。性能

　　這就要求咱們在軟件開發伊始，就創建細緻長遠的開發和管理計劃，平衡各要素間的分配。沒有計劃，就無從知道何時控制和變動。制定一個詳盡的計劃，以詳細到開發人員能夠理解的程度爲宜。計劃可以告訴你何時應該作什麼。因爲沒有計劃或是計劃太粗糙、不切實際，不少項目1/3甚至1/2的時間花在返工上面。由於計劃中遺漏了某一項關鍵任務，或者由於計劃太過簡陋，就會出如今實際開發過程當中，一旦遇到大的問題，急於解決的過程當中就會使得本來設計好的需求，資源，工期與質量間的平衡被打破，隨之帶來的，不管是工期上的延長，仍是質量上的紕漏，均可能致使項目最終宣告失敗。學習

　　二.高效原則網站

　　記得看過一篇facebook創始人扎克伯格回憶本身創業之初的故事，有一句話讓我印象深入，「真正決定人生高度的，是你作事的速度」。當初，心血來潮的扎克伯格從產生想法，到實現一款簡單的應用--大頭照對比評分應用FaceMash，僅用了6個小時。在短短的時間內，他獨自一人完成了產品的設計，開發，上線....這在當時多是一個小型企業兩天的平常工做量。而他的對頭，在哈弗就讀的Winklevoss兄弟，總說扎克伯格抄襲了他們的創意，纔有了後來的facebook，而事實呢？在Winklevoss兄弟在猶豫是否要投入作社交網站時，扎克伯格的facebook已經覆蓋了29所學校，7.5萬註冊用戶。促成他們之後差距的，正是兩者執行力的差距。也只有像這樣在短期內完成高質量的任務才能稱之爲高效。google

　　在實際狀況中，軟件項目的人力資源分配大體符合Norden-Rayleigh曲線分佈。①區域表明開始階段，人力過剩；②區域表示開發的中後期，人手不足；③區域表示後來的補償時間過晚，反而會出現Brooks定律的狀況:「向一個已經拖延的項目追加新的開發人員，可能會使這個項目完成得更晚」。由於做爲新加入的員工來講，相關培訓、環境熟悉和人員之間的溝統統路的增長，迫使項目的工做效率急劇下跌。工做效率降低須要加班來進行彌補，但加班形成的疲勞會再次使工做效率下降。同時工做成本卻不斷的向上攀升。spa

　　基於高效性原則，須要對項目管理考慮如下幾個方面：1.選擇精英成員，雖然現實中開發人員不可能，也作不到像扎克伯格那樣擁有天才般的速度和執行力，但總能夠從現有人力資源中挑選出其中精英，對不一樣專長的人安排不一樣分工；2.目標要明確，範圍要清楚，明確開發目標和功能的覆蓋範圍，並在實際操做過程當中堅決地保持始終如一；3.溝通要及時、充分，溝通管理是對項目過程當中產生的各類信息進行收集、存儲、發佈和最終處理，由溝通計劃編制、信息發送、性能報告和階段的結束構成。溝通，不只包括項目組內部程序員和項目經理的溝通，還須要客戶與項目組的溝。溝通的不足會致使效率的下降；4.要在激勵成員上下工夫，經過評估咱們能夠激勵人員，保證績效。良好的績效管理能夠一目瞭然地反映項目成員的業績，一切以數聽說話，更能體現公平。績效考覈分項目績效和我的績效兩個部分，項目績效從項目成本、利潤、完成計劃狀況、項目質量、規範程度、文檔水平、技術、產品化和共享度方面評價項目效果。設計

　　三.優先原則
代理

　　在軟件工程中存在這樣的PARETO定律：在實際中企業80%的問題能夠用20%的投資解決，而20%的次要問題則須要花費80%的投資的。在軟件項目中，若是出現了過多的需求，一般會致使項目超出預算和預約進度，最終致使軟件項目的失敗，此時需求的優先級可能比需求自己更爲重要。仔細分析一下，這些項目要求分爲必須的非必須的，所以咱們建議是壓縮非必須的部分或是暫時將其放在一邊沒必要過重視。軟件項目開發事實告訴咱們，開發人員在非必須的項目要求上耗費了太多的精力，用戶的需求變動的大部分出如今"最好有"這一部分，實際上用戶並不看重這些需求（即便去除這些需求），而咱們所作的，每每是捨本求末。blog

　　在實際狀況中，軟件開發負責人員每每會面臨需求方提出的一系列繁複的需求，在實施過程當中必定要將需求劃分爲不一樣的優先級，創建項目開發的需求優先級隊列，對於一個管理良好的軟件工程必不可少。反之，盲目追求對細枝末節的全覆蓋，反而會極大拖慢工期進度，甚至影響產品質量。

　　四.分解原則

　　「分而治之」是計算機領域的一個重要思想，對於軟件項目來說，能夠將大的項目劃分紅幾個小項目來作，將週期長的項目化分紅幾個明確的階段。在需求管理中首先要進行分類管理，將軟件需求分出層次，不一樣層次需求的側重點、描述方式和管理方式是不一樣的。對於管理層而言，提出的需求可能會更加偏向於全局性的目標需求，對於底層實現和分工並不關心；而中層須要將具體的操做，代碼分配給不一樣部分，人員進行實現，同時須要考慮各部分之間的相互銜接。項目越大對項目組的管理人員、開發人員的要求越高，參與的人員越多，須要協調溝通的渠道越多，週期越長，開發人員也容易疲勞，將大項目拆分紅幾個小項目，能夠下降對項目管理人員的要求，減小項目的管理風險，並且可以充分地將項目管理的權力下放，充分調動人員的積極性，目標會比較具體明確，易於取得階段性的成果，使開發人員有成就感。

　　五.風險原則

　　某家知名軟件公司曾總結出排行前幾的爲軟件管理埋下風險的罪魁禍首，分別是：

　　1.人爲缺陷；2.不切實際的時間表和預算；3.開發錯誤的功能和屬性；4.開發錯誤的用戶交互；5.多此一舉；6.持續的需求更改.....

　　軟件項目管理的過程當中，惟一不變的就是"變化"。風險管理也是始終貫穿於軟件項目管理之中的重要元素，在項目中不考慮可能發生的變化是難以想象的。不過在面對項目可能發生變化而帶來的項目風險時，項目管理人員每每會懷有逃避的態度。經濟學裏大名鼎鼎的風險規避原則即是項目管理人員心理的有效描述。做爲項目管理人員來講，應該及早預測可能出現的風險，作好風險儲備。雖然風險儲備不能解決全部的問題，但預防勝於治療"。經過學習項目管理知識掌握風險識別、量化、對策研究、反應控制的工具和方法，掌握項目風險管理所必備的知識。經過增強對項目規劃中風險管理計劃的審覈提升項目組的風險管理意識。

　　小結：

　　隨着軟件開發的深刻、各類技術的不斷創新以及軟件產業的造成，人們愈來愈意識到軟件過程管理的重要性，管理學的思想逐漸融入軟件開發過程當中，項目開發的管理日益受到重視。然而，實施切實有效的軟件項目管理在實際操做中絕非易事，瞭解和運用上述原則是不夠的，若要達成軟件工程管理的最終目標——保證軟件項目可以按照預約的成本，進度，質量定期，順利地交付用戶使用，還必須深刻學習項目管理、管理心理學、質量管理學、組織變革、系統論等方面的知識，並在工做中不斷的總結和實踐。

參考文獻:

[1]BARRY W. BOEHM，SENIOR MEMBER.Theory-W Software Project Management: and Examples，IEEE

[2]Software project management，維基百科詞條

[3]BARRY W. BOEHM，Defense Advanced Research Projects Agency.Software Risk Management: Principles and Practices，IEEE

[4]曾祥鵬.淺談軟件開發項目管理，今日科苑

[5]孫鴻飛，武慧娟.淺談軟件開發項目管理的意義和原則，商場現代化