溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
這篇文章主要介紹“軟件項目管理的知識有哪些”，在日常操作中，相信很多人在軟件項目管理的知識有哪些問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”軟件項目管理的知識有哪些”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！
本文所說的傳統項目管理模式，是指歷史較長、更注重框架與方法論、同時也相對更嚴格的項目管理框架。比較典型的傳統軟件項目管理模式是瀑布流開發模式（Waterfall），這是很多傳統軟件項目采用的開發模式，其中涉及到的工具甘特圖也是廣為人知，甚至成為了項目管理的標志；另外比較流行的傳統項目管理框架有美國的 PMBOK（全稱 Project Management Body of Knowledge），這是一本項目管理指南，是由全球項目管理會員組織 PMI 編輯發布，也是專業項目管理認證 PMP 的基礎，它基本上可以看作是項目管理中的 “駕駛執照”；英國政府發布的 IT 項目管理認證 PRINCE2 跟 PMBOK 一樣，也是全球權威的軟件項目管理框架，比較適合大型項目；此外，還有注重質量管理的 6 Sigma，這是跟其他方法論完全不一樣的方法論，強調質量優先，比較適合于制造業等需要高精度質量控制的行業。 本文不打算介紹所有的項目管理方法論，想詳細了解的讀者可以參考 Project Manager 相關介紹。
所謂瀑布流開發模式（Waterfall），從字面上很容易理解：整個開發項目由很多任務及子任務組成；每個任務有對應計劃的開始和結束時間；任務之間通常有依賴關系以及先后順序；如果將任務的計劃執行時間在 甘特圖（Gantt Chart）上可視化出來，長得就跟瀑布流一樣。下面是一個典型的項目管理甘特圖。
上面的甘特圖反映了軟件項目的系統開發生命周期（SDLC，全稱 System Development Lifecycle），其中包含需求分析（Requirements Analysis）、系統設計（System Design）、開發（Development）、測試（Testing）、驗收（Closing）等多個階段。需求分析通常在軟件項目的最初始階段，而測試與驗收一般在項目的最后階段。在瀑布流開發模式中，項目任務一環扣一環，緊密聯系，項目管理者可以在甘特圖中一目了然的看到看到項目的全貌。通過規劃項目任務和設計甘特圖，我們似乎期待可以準確預測項目周期與完成時間。
然而，“理想很豐滿，現實很骨感”。瀑布流開發模式最大的問題來自于它對不確定性的低容忍度。如今市場環境快速變化，商業機會轉瞬即逝，企業的生存壓力已經不允許開發團隊花大量的時間在需求分析和系統設計上。很多傳統軟件企業花幾個月甚至一年的時間在分析和設計階段，又花幾個月甚至幾年的時間開發、測試和上線產品，最后卻發現終端用戶不滿意甚至拒絕使用，大量的時間成本和人工成本打了水漂。這是很多 IT 企業用血換來的教訓。現在的企業更希望有更靈活的軟件項目管理框架來滿足業務發展。
前面說過，PMBOK 支撐的 PMP 認證是項目管理行業中的 “駕駛執照”，這是因為 PMBOK 中定義的管理框架幾乎適用于任何一個行業。它誕生于上個世紀 70 年代，經過幾十年的發展到如今已經發布到第 6 版，到如今可以說是最知名和最權威的項目管理指南。簡單來說，PMBOK 把項目管理概括為 10 個領域，通過對這 10 個領域的系統管理，可以有效的控制整個項目的進度、成本、資源等因素，保證項目成功，最大限度控制風險。希望詳細了解 PMBOK 的讀者可以參考 PMI 官網。
PMBOK 不只是適用于 IT 行業，各行各業都可以運用它的項目管理框架，因此是一個大而全的方法論。包括像之前提到的瀑布流開發模式，也是 PMBOK 中部分領域的實現方法而已。它們二者并不互斥。同樣，PMBOK 的方法論涉及的概念較多，因此也顯得比較正式，其中的工作說明（SOW，全稱 Statement of Work）、Charter、Closing Report 都可以作為項目的正式文檔，因此在大型項目中使用得較多。
筆者沒有深入接觸過 PRINCE2 和 6 Sigma，因此就不詳細展開了。
在如今 IT 行業快速發展的大背景下，已經很少有 IT 從業者沒聽說過敏捷開發（Agile Development）了。敏捷開發也如字面上的意思，是非常注重靈活性和交互性的項目管理方法。在實踐敏捷管理的過程中，項目團隊可以跳出傳統項目管理框架中條條框框，變得更加 “敏捷”。那些看似不可變更的目標、截止日期甚至是交付物，在敏捷框架下都可以隨實際情況靈活調整。就像沒有重型鎧甲和大規模輜重束縛的蒙古射騎兵，敏捷開發團隊可以快速適應戰場環境的變化，從而靈活而輕松的攻破敵人的防線。
敏捷開發有三個比較大的特點。
由開發周期驅動。每個周期通常持續 1-4 周，從而保證每個周期的交付物都可以被頻繁評估，從而讓開發精力聚焦于產品優化。
基于迭代周期。每個迭代周期通常是固定的，因此周期結束時總會有一個有效的交付物。
對客戶開放。客戶可以在周期結束后看到半成品，從而提高了透明性與交互性。
敏捷開發與傳統開發模式的最大不同點，是敏捷開發不要求在項目執行前提前安排整個項目任務的執行計劃。在敏捷開發中，整個項目被分割成多個更可控的階段，在階段完成處設定項目里程碑（Milestone），而在里程碑達成時客戶（Customer）及相關干系人（Statekholder）可以根據階段交付物對半成品（WIP，全稱 Work in Progress）提供反饋，為下一個階段的開發提供參考意見。在這樣不斷的 “規劃 -> 開發 -> 反饋 -> 規劃 -> ...” 周期性的開發模式中，最終交付的產品有很大可能會跟客戶期待的更加接近，從而提高客戶的滿意度，也避免了大量的資源浪費。在全球暢銷書《精益創業》中，作者提到：企業的最大浪費是來自于 “返工”。因此，采用敏捷開發的模式，項目團隊可以有效規避需求變化帶來的風險。這讓實踐敏捷開發的企業具有反脆弱性，能夠在不斷的迭代和學習中獲得適應環境不確定性的能力。
敏捷開發中的一個核心概念是迭代（Iteration），也叫時期（Phase）或沖刺（Sprint）。這是敏捷開發中的最小時間單元，通常持續 1-4 周。反復迭代的過程其實也就是一個不斷優化產品的過程。在迭代周期結束時，項目組通常會完成一部分或整個（可能不太完善的）產品，同時也會收到來自客戶或相關干系人的反饋，從而為下一次迭代提供參考。例如，在一個廣告投放后臺管理系統開發項目中，第一階段開發團隊根據初期的簡單需求開發出了一個非常基本的后臺系統，只有投放廣告和查看數據的核心功能；項目組將第一階段的交付物在Sprint 1 總結會上呈現給終端用戶，并且告知這不是最終成品；終端用戶根據實際使用場景提出一些改進意見，或匯報一些 Bug；在接下來的階段中，項目組就可以根據 Sprint 1 的反饋進行調整，將優化任務和 Bug 修復任務安排在 Sprint 2；然后這樣不斷迭代下去。這樣一來，每個迭代完成之后，最終的交付產品會越來越接近最優的狀態。
在敏捷開發中，有幾個重要角色。
產品負責人（Product Owner）。主要負責與客戶、相關干系人以及開發團隊溝通，制定用戶故事（User Stories），以及需要持續與開發團隊一起協作，保證開發進度。
開發團隊成員（Development Team Members）。項目任務實施者，通常是開發者、設計師、測試人員等。
流程管理員（Scrum Master）。負責整個 Scrum 流程在項目中順利實施和開發，解決客戶與開發者的溝通障礙。這個角色可以是跟產品負責人重疊的。
相關干系人（Stakeholders）。不一定直接負責產品，但可能間接參與到產品的使用流程中。
每日站會（Daily Stand Meeting）是項目組成員每日面對面溝通的一個持續大約 15 分鐘的短會，主要目的是追蹤項目開發任務進度，解決任務執行過程中遇到的問題，以及協調資源等。不要簡單的以為站會就是 “站著開會”。首先，大家站在一起，能夠讓項目組成員集中注意力，將重心聚焦于項目任務上來；其次，較短的會議時間能夠讓整個會議不偏離主題，而且更能夠節省時間，提高工作效率；另外，每日站會要求項目組成員每人都需要發言，這提高了團隊成員的參與度。下圖是一個每日站會的例子。
看板（Kanban）是豐田 JIT （Just in Time）精益生產中的管理工具。它為項目任務設置了不同的狀態，通常是 Backlog、To Do、In Progress、Testing、Done 這幾個狀態。而每個任務會預估一個完成所需時間，通常是按小時計。另一個重要的任務屬性是優先級，在積壓階段（Backlog），開發團隊成員需要根據各自的經驗和專業知識判斷該任務所需要的時間，以及定義任務的優先級。不同類別的任務用不同的顏色標記。這樣的看版在每日站會中能發揮很大作用，因為它清晰直觀，能夠一目了然。當任務改變狀態時，例如開發者從 Backlog 取出一個任務卡片，將會被直接放在 To Do 中。下圖是一個看板示意圖。
當然，我們現在有更現代化的工具來管理看板的流程，不用人工設計一個看板或購買大量的貼紙。一些比較熱門的工具包括 Trello、禪道、Teambition等。
燃盡圖（Burndown Chart）是一個追蹤項目進度的有效工具。它是一個隨時間遞減的曲線。橫軸是持續時間，縱軸是剩余故事價值總數、任務預計總工時等。燃盡圖通常有兩個曲線：一個是預估的理想下降曲線，通常是隨時間線性下降的；另一個是實際下降曲線，表示在某個時間實際剩余的價值或工時等。如果實際曲線在某時刻高于理想曲線，則表示目前進度是落后的；相反，如果實際曲線低于理想曲線，說明進度是領先的。下圖是一個燃盡圖示意圖。
在敏捷開發中，用戶故事（User Story）跟項目任務（Project Task）比較容易混淆。它們分別是站在不同角色的角度上描述的。用戶故事簡單來就是的終端用戶的使用場景。它通常是由項目負責人向客戶或終端用戶收集整理而成，并會站在業務的角度制定各個故事的價值（Value）以及優先級（Priority）。而項目任務是開發團隊根據用戶故事的描述，結合實際系統架構、技術環境等因素，分解出來的實際開發任務，相對于用戶故事來說更加具有落地性。因此，可以說項目任務是為了實現用戶故事而制定的。用戶故事的價值和優先級通常需要結合實際業務背景以及商業價值，因此需要由產品負責人來主導制定；項目任務通常更加偏技術層面，因此需要由對技術模塊比較了解的開發人員制定。這些通常都可以在初期會議以及里程碑總結會議來完成。
對于了解過敏捷開發的讀者來說，可能已經聽說過 Scrum，甚至將 Scrum 等同于敏捷。這個看法從技術層面上來說是不確切的。Scrum，包括之后會聊到的極限編程（XP，全稱 Extreme Programming），只是敏捷開發方法論下的一種指導框架。它們的目標都是在保證項目質量的條件下，盡可能增強靈活性；很多專業術語，例如用戶故事、項目任務、迭代，都是一致的。它們不同點主要在于如何執行每一次迭代或沖刺。
在 Scrum 中，每一個迭代中的項目計劃通常是不允許變更的，一旦在迭代初期決定后，用戶故事和項目任務就不允許改變了。只有當該迭代結束之后，才可以根據實際反饋做相應調整。這樣做的好處在于，項目團隊成員可以在每一次迭代中集中精力完成各自的任務，保證實現功能的質量和效率，以追求該迭代周期完成之后產品的穩定性和可靠性。但這樣做也有缺點，那就是相對來說不夠 “敏捷”，因為一旦項目計劃確定，就不允許加入新的需求或更改已有需求。另外，Scrum 的迭代周期一般是 2-4 周，相對來說比較長。
而在 XP 中，未實現的用戶故事則是可以被新的用戶故事替換的，前提是實現這兩個用戶故事的工時是相等的。而在用戶故事的優先級上，XP 更加嚴格，它要求實際項目任務要嚴格遵守用戶故事的優先級。另外，XP 在軟件實施過程要求也更為嚴格，一般需要采用測試驅動開發（TDD，全稱 Test Driven Development）、自動化測試（Automated Testing）、結對編程、重構等相對嚴格的質量控制措施。因此，雖然 XP 在用戶故事上顯得比較靈活，但在軟件實施流程上要求非常嚴格，因此對開發團隊的技術和經驗要求也更高。
敏捷開發還包括不少其他方面的元素，本文限于篇幅原因就不深入介紹了。
在實際工作中，我們會遇到大大小小的項目需求，如何選擇項目管理模式是一個重要問題。但可惜的是，目前來說沒有一個完美的解決方案，能夠適應所有軟件類項目。本文雖然花了大量的篇幅介紹敏捷開發，但并不意味著敏捷開發是全能的。傳統的瀑布流開發模式有很多弊端，但它也有不少適用場景，例如政府 IT 項目，或一些專業性很強的開發項目。而且，在做項目管理模式的選擇前，還需要充分了解一些表面上看不那么明顯的隱性因素，例如企業文化、組織架構、行業背景、人力資源、團隊經驗等等。因此，筆者認為，敏捷開發并不是解決一切問題的萬能鑰匙。我們在做實際選擇前應該三思而后行。甚至在一些情況下，還需要根據實際情況綜合各種管理模式做一定程度的調整，讓其變得更加適合當前的項目背景。
敏捷開發的優勢非常明顯，它能夠更加適應快速變化的商業和市場環境，幫助企業克服一些不確定性因素，從而能夠交付更多對用戶有價值的產品。而且，敏捷開發通常比起傳統的瀑布流開發來說，省略了很多不必要的文檔以及繁瑣的溝通流程，因此通常會花更少的時間完成更多的事情。但是，敏捷開發相對于傳統的瀑布流開發來說顯得不那么正式，有點像 “游擊隊” vs “正規軍” 的感覺。傳統項目管理模式，例如 PMBOK，有非常完備的流程管理和文檔管理，對于長期性的大型項目來說是更為合適的。
所以，筆者認為，如果你的市場環境和客戶需求會頻繁變化，而這種不確定性會大幅度影響企業的財務健康，那你千萬不要猶豫，就選敏捷開發。相反，如果市場環境變化沒那么快，而客戶需求相對來說比較固定，另外還具有較高的合規性以及正式文檔要求，例如政府 IT 項目，那么你可以選擇用傳統的項目管理模式，例如瀑布流開發模式。
到此，關于“軟件項目管理的知識有哪些”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
