由FLUX1.1

生成版權所有??2025僅限于本教材的教學使用同濟大學朱少民《軟件項目管理》第4章項目計劃木工與主管

總管手下新來了一個非常厲害的木工，就是對主管有點不服氣。一次主管讓他負責做大梁。新來的木工決定要難為木工總管，他做好了一根大梁，非常的漂亮，就是把大梁少做了一米。

第二天，準備上梁，此時木工喊道：總管房梁短了一米。沒想到，主管很悠閑的說，那我們倆把這梁拉長一米。

木工一拉，嘿，真是神了，這梁真的就長了一米，一時間掌聲雷動，大家都說主管是個神仙，大梁都能拉長一米。木工更是驚奇不已，沒想到主管這么厲害。從此以后，木工就跟著主管，走南闖北，干下了許多大工程。

過了幾年，木工實在忍不住了，就好酒好菜宴請主管，非要他說出那天拉梁的秘密來不可。主管微微一笑說：我每天在你們都回去休息的時候，都去檢查、測量，后來發現您將大梁少做了一米，為了不耽誤第二天上梁，我連夜趕工重做了一根，將您那個大梁給拆了，第二天，我們倆抬梁上房的時候，就知道您會叫少了一米，我就特意要拉長一米，事情就是這么簡單。監督與控制10.1項目過程度量-10.1.1內容-10.1.2過程-10.1.3方法-10.1.4規則過程度量的內容軟件過程能力度量（CMM/CMMI過程和敏捷成熟度模型）過程度量的內容-2軟件過程性能的度量過程效率度量和質量度量的有機結合過程度量的流程流程的主要流動方向，即從確認過程問題到實施過程行動的全過程和過程強關聯、過程度量受過程控制性的影響。虛線表示弱關聯，相互參考。過程度量的階段識別目標和度量描述定義度量過程搜集數據數據分析與反饋過程改進正態分布法在正態曲線中，均值±1σ只能給出68.26%的覆蓋程度，而使用均值±2σ、±3σ則可以界定正態曲線中95.44%、910.73%的覆蓋程度。6σ則說明樣本觀測值非常集中，過程能力很強，所以被用來表示高質量的生產水平S曲線分析法過程度量定義規則制定度量參數時應盡可能考慮組織的受用性和通用性。度量的目標是改進軟件過程，提高質量和效率，因此不要使用度量去片面地評價個人和組織團隊，這樣會違背度量的初衷，并影響團隊成員的積極性。利用專門的系統或者專人進行統計度量工作，以確保數據的一致性和準確性。避免度量指標太多或者太少．．．．．．10.2數據收集-10.2.1數據收集方式-10.2.2數據質量數據收集方式1.被動接收如：日報、周報、月報等方式2.主動收集項目組長/負責人/經理通過各種手段主動地進行數據的收集。確保數據信息的質量1.

數據的真實性：基于真實數據的分析才更可靠，從而可以做出正確的決策。2.

數據的及時性：在軟件開發過程中，有些數據是要求及時收集的，如果不能及時上報這些數據和解決數據所反映的問題，將會對軟件項目的進度甚至質量、成本造成很大的威脅。3.

數據的有效性：有效的數據才有價值去做分析。10.3可視化管理-10.3.1全程可視化-10.3.2進度可視化監控方法-10.3.3研發質量看板-10.3.4研發效能看板全程可視化1.項目前期調查時期（原型設計）2.項目啟動時期，確定組織結構是可視化的首要任務。3.項目計劃時期工作分解WBS和角色責任矩陣團隊可視化全程可視化4.項目執行時期展示進度信息，可以選用甘特圖、時間線；展示代碼質量，可以利用一些代碼審查結果和缺陷分析圖表；……5.項目收尾總結時期總結信息用表格、圖形、Powerpoint文件等可視化形式呈現給大家分析結果。6.項目后期維護時期針對維護過程中遇到的問題進行匯總和可視化分析。甘特圖延遲圖時間線計劃與實際對比圖燃盡圖完美軟件項目燃盡圖

實際項目的燃盡圖其他進度可視化方法預警提示代碼審查可視化分析缺陷分析及時戰報……研發質量看板質量看板將產品質量和過程質量指標以可視化的形式呈現出來，幫助研發團隊及時了解質量狀況，及時發現質量風險，理清關鍵路徑，集中解決關鍵問題，保證項目得以順利進行示例：每周缺陷趨勢看板研發效能看板軟件的研發效能就是軟件研發交付能力和效果，而效果體現在所交付的價值大小和速度。研發效能關注軟件的交付質量、交付效率，以及整個團隊的工程交付能力示例：各開發者平均需求交付周期10.4數據分析-10.4.1設定不同階段-10.4.2分析方法數據分析實踐是最好的老師，但是，如果不能從中學習，再多的實踐也沒有用。摘自人月神話數據分析的階段1、觀察探索性分析2、模型選定分析3、推斷分析4、分析改進排列圖關聯圖法KJ法親和圖法（AffinityDiagram）

PDPC法過程決策程序圖（ProcedureDecisionProgramChart）LeanCoffee法LeanCoffee是一種Agile討論會，所有被討論的議題都是參與者現場提出并投票選出的。這樣在很大程度上保證了參與者的積極性和討論的有效性。10.5優先級控制-10.5.1優先級設定與處理-10.5.2缺陷優先級和嚴重性多項目并行優先級處理任務/問題優先級處理核心功能或核心模塊的任務。關鍵路徑上的任務。有相互依賴關系的前導任務。影響范圍大的問題。阻礙進度的問題。嚴重影響項目質量的問題。……協調工作優先級處理團隊>個人缺陷嚴重性缺陷嚴重性是指軟件缺陷對軟件質量的破壞程度、對客戶使用產品或服務的影響程度。A類：致命錯誤B類：嚴重錯誤C類：一般性錯誤D類：較小錯誤E類：建議性問題（非缺陷）缺陷優先級優先級是指表示處理和修正軟件缺陷的先后順序的指標。最高優先級，立即修復，否則阻礙進一步測試。較高優先級，在產品發布之前必須修復。一般優先級，如果時間允許就修復。低優先級，可能會修復，但是不影響正常發布。區分缺陷的優先級和重要性從客戶的角度考慮：當評估缺陷優先級的時候，要常考慮這個缺陷是否對客戶造成很大的負面影響。負面影響大，優先級就高。遵照二八原則：任何一組事物中，最重要的只占其中約20%，其余的80%雖然是多數，但是卻是次要的。所以抓住重要的部分來處理很重要，只有先抓住了重要的關鍵缺陷，測試效率和測試質量才能提高，同時也能產生最大的效益。四象限原則：效仿時間管理四象限法則，把缺陷按輕重緩急進行分類，優先處理重要和緊急的缺陷。

10.6變更控制-10.6.1流程-10.6.2策略變更控制流程變更控制策略變更預防變更控制委員會變更執行管理變更適應—敏捷開發變更經驗收集與總結10.7

DevOps實踐-10.7.1需求與計劃-10.7.2編碼與構建-10.7.3持續集成-10.7.4持續測試-10.7.5持續部署-10.7.6持續監測與反饋DevOps生命周期DevOps生命周期包括需求與計劃（計劃）、編碼（代碼）、持續構建/持續集成（構建）、持續測試（測試）、持續交付（發布）、持續部署（部署）、運維、持續監控等多個階段需求與計劃編碼與構建構建版本控制過程制定分支策略持續集成持續測試測試可以隨時開展起來，且具有連續性測試和開發、運維能很好地融合、匹配和同步起來以最少的測試、最快的速度覆蓋交付所面臨的業務風險持續測試的特點足夠快整個測試過程要快，一方面高度自動化測試，另方面業務端到端的探索式測試準確且有效被測系統往往很復雜，不可能做全回歸測試，而是要推行精準測試平滑有序打通整個測試過程：測試左移到測試右移、單元測試到系統測試、靜態測試到動態測試與CI/CD集成與研發的持續構建、持續集成、持續部署、運維等環境的集成持續部署持續監測與反饋10.8合同履行控制合同履行控制制定科學完整的合同管理制度制定合理完善的合同履行控制系統加強合同變更的管理強化企業法律顧問的職責組織企業職工的法律培訓小結一份完美的圖紙并不等于一幢堅實的大樓對數據信息進行度量、收集和整理，而且為了有效地反映數據信息的進度，最好以直觀的、醒目的可視化方式來展現項目的進度