度管控與迭代管理：敏捷迭代+CMMI流程融合的輕量開發(fā)模式)
07-進(jìn)度管控與迭代管理敏捷迭代CMMI流程融合的輕量開發(fā)模式前兩篇講完了立項規(guī)劃和WBS拆解任務(wù)拆好了接下來就是怎么管好執(zhí)行過程。很團(tuán)隊在CMMI和敏捷之間糾結(jié)選CMMI嫌重選敏捷嫌散。其實這倆不是非此即彼融合起來用才是正解。一、敏捷與CMMI3不是選A還是選B1.1 兩個常見誤區(qū)誤區(qū)一“小微企業(yè)就該用敏捷CMMI太重了不適合。”CMMI不是讓你寫1000頁文檔CMMI的核心是過程可重復(fù)、結(jié)果可追溯、問題可改進(jìn)。小微企業(yè)完全可以輕量化落地。誤區(qū)二“敏捷就是不用寫文檔、不用做計劃?！泵艚莶皇菬o政府主義敏捷強調(diào)的是擁抱變化、快速反饋、持續(xù)改進(jìn)但這不等于沒有過程紀(jì)律。1.2 融合思路CMMI做骨架敏捷做肌肉維度CMMI提供什么敏捷提供什么融合方式過程規(guī)范標(biāo)準(zhǔn)流程定義、過程域要求—CMMI定義必須做什么執(zhí)行節(jié)奏里程碑檢查點Sprint迭代周期敏捷定義怎么一步步做質(zhì)量保障配置管理、質(zhì)量審計、度量分析持續(xù)集成、自動化測試兩者結(jié)合文檔輕量化但過程不丟改進(jìn)機制組織級過程改進(jìn)(OPF/OPA)Sprint回顧會議回顧會的輸出納入過程改進(jìn)庫一句話總結(jié)CMMI保證過程完整性敏捷保證執(zhí)行靈活性。1.3 融合后的開發(fā)節(jié)奏以2周一個Sprint為例融合后的節(jié)奏如下項目啟動 → 立項評審(CMMI) → 需求基線(CMMI) → 架構(gòu)設(shè)計(CMMI) → Sprint 0(敏捷) → Sprint 1 → Sprint 2 → ... → Sprint N → 里程碑評審(CMMI) → 驗收交付(CMMI) ↓ 每個Sprint內(nèi)部 Sprint規(guī)劃 → 開發(fā) → 每日站會 → Sprint評審 → Sprint回顧CMMI的關(guān)鍵檢查點立項、需求基線、設(shè)計評審、驗收作為大門敏捷的Sprint作為門之間的路。二、迭代計劃制定2.1 Sprint規(guī)劃會議每個Sprint開始前開一次Sprint規(guī)劃會議時長建議2-4小時。會議輸入產(chǎn)品待辦列表Product Backlog團(tuán)隊歷史速率VelocitySprint可用工時考慮請假、會議等扣除會議輸出Sprint待辦列表Sprint BacklogSprint目標(biāo)一句話描述本迭代要達(dá)成什么2.2 故事點估算故事點Story Point是敏捷中估算工作量的方法不用天而用相對值。故事點估算步驟選一個中等復(fù)雜度的任務(wù)作為基準(zhǔn)故事賦值2點其他任務(wù)與基準(zhǔn)對比差不多復(fù)雜就2點簡單就1點復(fù)雜就3-5點用斐波那契數(shù)列1、2、3、5、8、13避免中間值讓團(tuán)隊糾結(jié)估算方法——規(guī)劃撲克每人發(fā)一副撲克牌1/2/3/5/8/13PO講一個故事團(tuán)隊提問澄清每人同時出牌最高分和最低分的人分別解釋理由討論后重新出牌直到收斂故事點不是精確值是相對值。別糾結(jié)3點到底是1.5天還是2天關(guān)注相對大小就好。2.3 Sprint容量計算Sprint容量 團(tuán)隊人數(shù) × 每人可用天數(shù) × 投入比例 × 專注系數(shù)(0.7)舉例3人團(tuán)隊2周Sprint10個工作日投入比例80%專注系數(shù)0.7容量 3 × 10 × 0.8 × 0.7 16.8 → 取16點專注系數(shù)0.7的意思人不可能8小時純寫代碼開會、溝通、處理線上問題、摸魚劃掉都要算進(jìn)去。0.7是比較合理的經(jīng)驗值。2.4 Sprint待辦列表示例編號故事故事點負(fù)責(zé)人優(yōu)先級SP-01用戶手機號注冊登錄5張三P0SP-02商品信息CRUD接口3李四P0SP-03柜機心跳上報3張三P0SP-04小程序掃碼頁面5王五P1SP-05微信支付對接5李四P1三、看板管理讓進(jìn)度可視化3.1 看板的本質(zhì)看板的核心不是一塊白板而是可視化工作流 限制在制品(WIP)。標(biāo)準(zhǔn)看板列| 待辦(To Do) | 進(jìn)行中(In Progress) | 測試中(Testing) | 完成(Done) |3.2 工具選擇工具適合場景優(yōu)點缺點物理白板便利貼5人以下團(tuán)隊同地辦公直觀、低成本、儀式感強無法遠(yuǎn)程、無法留痕Teambition國內(nèi)中小團(tuán)隊中文友好、操作簡單、免費版夠用功能不如Jira豐富Jira有CMMI審計需求功能強大、報表豐富、可定制學(xué)習(xí)成本高、國內(nèi)訪問慢GitLab Issue Board開發(fā)團(tuán)隊已有GitLab與代碼倉庫集成、無需額外工具項目管理功能較弱小微企業(yè)建議5人以下用物理白板Teambition組合白板做日常可視化Teambition做記錄和遠(yuǎn)程協(xié)作。有審計需求再上Jira。3.3 WIP限制WIPWork In Progress限制是看板區(qū)別于普通任務(wù)板的關(guān)鍵。規(guī)定每列最多放幾個任務(wù)強制團(tuán)隊完成再開始新的。建議設(shè)置進(jìn)行中(In Progress)每人最多2個任務(wù)測試中(Testing)最多3個任務(wù)WIP限制的哲學(xué)少即多。同時做5個任務(wù)不如一次只做2個做完做好。減少上下文切換的開銷反而更快。四、進(jìn)度跟蹤方法4.1 燃盡圖Burndown Chart燃盡圖是敏捷最經(jīng)典的進(jìn)度可視化工具。橫軸是Sprint天數(shù)縱軸是剩余故事點理想曲線是一條從左上到右下的直線。故事點 16 |* | * --- 理想曲線 12 | * | * 8 | * | * --- 實際曲線 4 | * | * 0 ---|---|---|---|--→ 天數(shù) 1 5 8 10看燃盡圖的三個信號實際曲線在理想曲線上方 → 進(jìn)度落后需要調(diào)整實際曲線在理想曲線下方 → 正?；虺皩嶋H曲線不降反升 → 范圍在擴大有新增需求進(jìn)入Sprint4.2 每日站會時間每天早上15分鐘以內(nèi)形式圍著看板站著開每人說三句話昨天做了什么今天計劃做什么有什么阻礙站會的三個禁忌禁止變成技術(shù)討論會有問題會后單獨拉人討論禁止只匯報不協(xié)作不是給老板匯報是給團(tuán)隊同步禁止超時超過15分鐘說明跑偏了4.3 周報CMMI要求過程可追溯周報是輕量級的追溯手段。周報模板一頁紙搞定【項目名稱】第X周周報 一、本周完成 - 后端用戶服務(wù)接口開發(fā)完成通過單元測試 - 安卓攝像頭JNI封裝完成可正常采集圖像 - 小程序掃碼頁面完成已聯(lián)調(diào)后端 二、本周計劃偏差 - 商品服務(wù)接口延期1天原因數(shù)據(jù)庫表結(jié)構(gòu)調(diào)整 - 影響無已通過加班補回 三、下周計劃 - 后端完成柜機服務(wù)和交易服務(wù) - 安卓完成YOLO推理引擎封裝 - 小程序完成購物車頁面 四、風(fēng)險與問題 - R01風(fēng)險觸發(fā)RK3588到貨延遲3天已啟用RK3566備選方案五、偏差處理與計劃調(diào)整5.1 偏差判定標(biāo)準(zhǔn)偏差程度判定標(biāo)準(zhǔn)處理方式正常偏差≤5%無需處理繼續(xù)執(zhí)行關(guān)注5%偏差≤10%PM標(biāo)記關(guān)注在周報中說明預(yù)警10%偏差≤20%召開偏差分析會制定糾偏措施重大偏差偏差20%重新規(guī)劃可能需要變更基線偏差百分比 |實際進(jìn)度 - 計劃進(jìn)度| / 計劃進(jìn)度 × 100%5.2 糾偏措施五板斧趕工加人或加班花更多資源換時間成本增加快速跟進(jìn)把原本串行的任務(wù)改成并行風(fēng)險增加縮減范圍砍掉低優(yōu)先級功能需要客戶同意調(diào)整質(zhì)量標(biāo)準(zhǔn)降低非核心功能的質(zhì)量要求需要謹(jǐn)慎評估資源置換把能力強的人換到關(guān)鍵路徑上5.3 什么時候該重新規(guī)劃不是所有偏差都需要重新規(guī)劃。以下情況建議重新制定計劃關(guān)鍵路徑上的任務(wù)延期超過Sprint長度的50%多個Sprint連續(xù)未達(dá)成目標(biāo)出現(xiàn)計劃時未預(yù)料到的重大風(fēng)險客戶需求發(fā)生重大變更重新規(guī)劃要走變更控制流程更新項目計劃基線通知所有干系人。5.4 Sprint回顧會持續(xù)改進(jìn)的發(fā)動機每個Sprint結(jié)束時開回顧會回答三個問題做得好的這個Sprint哪些做法有效要繼續(xù)保持做得不好的哪些地方出了問題根因是什么下次改進(jìn)的具體改什么誰負(fù)責(zé)改下次怎么驗證回顧會的關(guān)鍵原則對事不對人不追責(zé)改進(jìn)項要具體、可執(zhí)行不要加強溝通這種廢話每個Sprint只選1-2個改進(jìn)項別貪多改進(jìn)項納入下個Sprint的待辦列表真正落地CMMI的組織級過程改進(jìn)OPF過程域要求從項目中收集改進(jìn)經(jīng)驗。Sprint回顧會就是最好的經(jīng)驗收集渠道。把回顧會的改進(jìn)項記錄到組織過程資產(chǎn)庫OPA跨項目復(fù)用。小結(jié)敏捷和CMMI的融合不是簡單的11而是用CMMI保證過程紀(jì)律用敏捷保證執(zhí)行效率。核心要點回顧融合思路CMMI做骨架立項/基線/評審/驗收敏捷做肌肉Sprint/站會/回顧迭代規(guī)劃故事點估算是相對估算Sprint容量用0.7專注系數(shù)看板管理可視化WIP限制少即多進(jìn)度跟蹤燃盡圖看趨勢、站會看日常、周報留痕跡偏差處理5%以內(nèi)正常10%以上預(yù)警20%以上重新規(guī)劃持續(xù)改進(jìn)Sprint回顧會是CMMI過程改進(jìn)的數(shù)據(jù)來源 07-進(jìn)度管控與迭代管理：敏捷迭代+CMMI流程融合的輕量開發(fā)模式
07-進(jìn)度管控與迭代管理敏捷迭代CMMI流程融合的輕量開發(fā)模式前兩篇講完了立項規(guī)劃和WBS拆解任務(wù)拆好了接下來就是怎么管好執(zhí)行過程。很團(tuán)隊在CMMI和敏捷之間糾結(jié)選CMMI嫌重選敏捷嫌散。其實這倆不是非此即彼融合起來用才是正解。一、敏捷與CMMI3不是選A還是選B1.1 兩個常見誤區(qū)誤區(qū)一“小微企業(yè)就該用敏捷CMMI太重了不適合。”CMMI不是讓你寫1000頁文檔CMMI的核心是過程可重復(fù)、結(jié)果可追溯、問題可改進(jìn)。小微企業(yè)完全可以輕量化落地。誤區(qū)二“敏捷就是不用寫文檔、不用做計劃?！泵艚莶皇菬o政府主義敏捷強調(diào)的是擁抱變化、快速反饋、持續(xù)改進(jìn)但這不等于沒有過程紀(jì)律。1.2 融合思路CMMI做骨架敏捷做肌肉維度CMMI提供什么敏捷提供什么融合方式過程規(guī)范標(biāo)準(zhǔn)流程定義、過程域要求—CMMI定義必須做什么執(zhí)行節(jié)奏里程碑檢查點Sprint迭代周期敏捷定義怎么一步步做質(zhì)量保障配置管理、質(zhì)量審計、度量分析持續(xù)集成、自動化測試兩者結(jié)合文檔輕量化但過程不丟改進(jìn)機制組織級過程改進(jìn)(OPF/OPA)Sprint回顧會議回顧會的輸出納入過程改進(jìn)庫一句話總結(jié)CMMI保證過程完整性敏捷保證執(zhí)行靈活性。1.3 融合后的開發(fā)節(jié)奏以2周一個Sprint為例融合后的節(jié)奏如下項目啟動 → 立項評審(CMMI) → 需求基線(CMMI) → 架構(gòu)設(shè)計(CMMI) → Sprint 0(敏捷) → Sprint 1 → Sprint 2 → ... → Sprint N → 里程碑評審(CMMI) → 驗收交付(CMMI) ↓ 每個Sprint內(nèi)部 Sprint規(guī)劃 → 開發(fā) → 每日站會 → Sprint評審 → Sprint回顧CMMI的關(guān)鍵檢查點立項、需求基線、設(shè)計評審、驗收作為大門敏捷的Sprint作為門之間的路。二、迭代計劃制定2.1 Sprint規(guī)劃會議每個Sprint開始前開一次Sprint規(guī)劃會議時長建議2-4小時。會議輸入產(chǎn)品待辦列表Product Backlog團(tuán)隊歷史速率VelocitySprint可用工時考慮請假、會議等扣除會議輸出Sprint待辦列表Sprint BacklogSprint目標(biāo)一句話描述本迭代要達(dá)成什么2.2 故事點估算故事點Story Point是敏捷中估算工作量的方法不用天而用相對值。故事點估算步驟選一個中等復(fù)雜度的任務(wù)作為基準(zhǔn)故事賦值2點其他任務(wù)與基準(zhǔn)對比差不多復(fù)雜就2點簡單就1點復(fù)雜就3-5點用斐波那契數(shù)列1、2、3、5、8、13避免中間值讓團(tuán)隊糾結(jié)估算方法——規(guī)劃撲克每人發(fā)一副撲克牌1/2/3/5/8/13PO講一個故事團(tuán)隊提問澄清每人同時出牌最高分和最低分的人分別解釋理由討論后重新出牌直到收斂故事點不是精確值是相對值。別糾結(jié)3點到底是1.5天還是2天關(guān)注相對大小就好。2.3 Sprint容量計算Sprint容量 團(tuán)隊人數(shù) × 每人可用天數(shù) × 投入比例 × 專注系數(shù)(0.7)舉例3人團(tuán)隊2周Sprint10個工作日投入比例80%專注系數(shù)0.7容量 3 × 10 × 0.8 × 0.7 16.8 → 取16點專注系數(shù)0.7的意思人不可能8小時純寫代碼開會、溝通、處理線上問題、摸魚劃掉都要算進(jìn)去。0.7是比較合理的經(jīng)驗值。2.4 Sprint待辦列表示例編號故事故事點負(fù)責(zé)人優(yōu)先級SP-01用戶手機號注冊登錄5張三P0SP-02商品信息CRUD接口3李四P0SP-03柜機心跳上報3張三P0SP-04小程序掃碼頁面5王五P1SP-05微信支付對接5李四P1三、看板管理讓進(jìn)度可視化3.1 看板的本質(zhì)看板的核心不是一塊白板而是可視化工作流 限制在制品(WIP)。標(biāo)準(zhǔn)看板列| 待辦(To Do) | 進(jìn)行中(In Progress) | 測試中(Testing) | 完成(Done) |3.2 工具選擇工具適合場景優(yōu)點缺點物理白板便利貼5人以下團(tuán)隊同地辦公直觀、低成本、儀式感強無法遠(yuǎn)程、無法留痕Teambition國內(nèi)中小團(tuán)隊中文友好、操作簡單、免費版夠用功能不如Jira豐富Jira有CMMI審計需求功能強大、報表豐富、可定制學(xué)習(xí)成本高、國內(nèi)訪問慢GitLab Issue Board開發(fā)團(tuán)隊已有GitLab與代碼倉庫集成、無需額外工具項目管理功能較弱小微企業(yè)建議5人以下用物理白板Teambition組合白板做日常可視化Teambition做記錄和遠(yuǎn)程協(xié)作。有審計需求再上Jira。3.3 WIP限制WIPWork In Progress限制是看板區(qū)別于普通任務(wù)板的關(guān)鍵。規(guī)定每列最多放幾個任務(wù)強制團(tuán)隊完成再開始新的。建議設(shè)置進(jìn)行中(In Progress)每人最多2個任務(wù)測試中(Testing)最多3個任務(wù)WIP限制的哲學(xué)少即多。同時做5個任務(wù)不如一次只做2個做完做好。減少上下文切換的開銷反而更快。四、進(jìn)度跟蹤方法4.1 燃盡圖Burndown Chart燃盡圖是敏捷最經(jīng)典的進(jìn)度可視化工具。橫軸是Sprint天數(shù)縱軸是剩余故事點理想曲線是一條從左上到右下的直線。故事點 16 |* | * --- 理想曲線 12 | * | * 8 | * | * --- 實際曲線 4 | * | * 0 ---|---|---|---|--→ 天數(shù) 1 5 8 10看燃盡圖的三個信號實際曲線在理想曲線上方 → 進(jìn)度落后需要調(diào)整實際曲線在理想曲線下方 → 正?；虺皩嶋H曲線不降反升 → 范圍在擴大有新增需求進(jìn)入Sprint4.2 每日站會時間每天早上15分鐘以內(nèi)形式圍著看板站著開每人說三句話昨天做了什么今天計劃做什么有什么阻礙站會的三個禁忌禁止變成技術(shù)討論會有問題會后單獨拉人討論禁止只匯報不協(xié)作不是給老板匯報是給團(tuán)隊同步禁止超時超過15分鐘說明跑偏了4.3 周報CMMI要求過程可追溯周報是輕量級的追溯手段。周報模板一頁紙搞定【項目名稱】第X周周報 一、本周完成 - 后端用戶服務(wù)接口開發(fā)完成通過單元測試 - 安卓攝像頭JNI封裝完成可正常采集圖像 - 小程序掃碼頁面完成已聯(lián)調(diào)后端 二、本周計劃偏差 - 商品服務(wù)接口延期1天原因數(shù)據(jù)庫表結(jié)構(gòu)調(diào)整 - 影響無已通過加班補回 三、下周計劃 - 后端完成柜機服務(wù)和交易服務(wù) - 安卓完成YOLO推理引擎封裝 - 小程序完成購物車頁面 四、風(fēng)險與問題 - R01風(fēng)險觸發(fā)RK3588到貨延遲3天已啟用RK3566備選方案五、偏差處理與計劃調(diào)整5.1 偏差判定標(biāo)準(zhǔn)偏差程度判定標(biāo)準(zhǔn)處理方式正常偏差≤5%無需處理繼續(xù)執(zhí)行關(guān)注5%偏差≤10%PM標(biāo)記關(guān)注在周報中說明預(yù)警10%偏差≤20%召開偏差分析會制定糾偏措施重大偏差偏差20%重新規(guī)劃可能需要變更基線偏差百分比 |實際進(jìn)度 - 計劃進(jìn)度| / 計劃進(jìn)度 × 100%5.2 糾偏措施五板斧趕工加人或加班花更多資源換時間成本增加快速跟進(jìn)把原本串行的任務(wù)改成并行風(fēng)險增加縮減范圍砍掉低優(yōu)先級功能需要客戶同意調(diào)整質(zhì)量標(biāo)準(zhǔn)降低非核心功能的質(zhì)量要求需要謹(jǐn)慎評估資源置換把能力強的人換到關(guān)鍵路徑上5.3 什么時候該重新規(guī)劃不是所有偏差都需要重新規(guī)劃。以下情況建議重新制定計劃關(guān)鍵路徑上的任務(wù)延期超過Sprint長度的50%多個Sprint連續(xù)未達(dá)成目標(biāo)出現(xiàn)計劃時未預(yù)料到的重大風(fēng)險客戶需求發(fā)生重大變更重新規(guī)劃要走變更控制流程更新項目計劃基線通知所有干系人。5.4 Sprint回顧會持續(xù)改進(jìn)的發(fā)動機每個Sprint結(jié)束時開回顧會回答三個問題做得好的這個Sprint哪些做法有效要繼續(xù)保持做得不好的哪些地方出了問題根因是什么下次改進(jìn)的具體改什么誰負(fù)責(zé)改下次怎么驗證回顧會的關(guān)鍵原則對事不對人不追責(zé)改進(jìn)項要具體、可執(zhí)行不要加強溝通這種廢話每個Sprint只選1-2個改進(jìn)項別貪多改進(jìn)項納入下個Sprint的待辦列表真正落地CMMI的組織級過程改進(jìn)OPF過程域要求從項目中收集改進(jìn)經(jīng)驗。Sprint回顧會就是最好的經(jīng)驗收集渠道。把回顧會的改進(jìn)項記錄到組織過程資產(chǎn)庫OPA跨項目復(fù)用。小結(jié)敏捷和CMMI的融合不是簡單的11而是用CMMI保證過程紀(jì)律用敏捷保證執(zhí)行效率。核心要點回顧融合思路CMMI做骨架立項/基線/評審/驗收敏捷做肌肉Sprint/站會/回顧迭代規(guī)劃故事點估算是相對估算Sprint容量用0.7專注系數(shù)看板管理可視化WIP限制少即多進(jìn)度跟蹤燃盡圖看趨勢、站會看日常、周報留痕跡偏差處理5%以內(nèi)正常10%以上預(yù)警20%以上重新規(guī)劃持續(xù)改進(jìn)Sprint回顧會是CMMI過程改進(jìn)的數(shù)據(jù)來源