摘要：企業在做敏捷轉型中，需求無法按時交付的困擾你是否也遇到過呢？
背景
在之前組織的一次敏捷線下活動中，有家企業問道：“我們公司剛做敏捷轉型不久，遇到一個比較頭疼的問題——團隊每天都很忙，從轉型到現在已經兩個多月了，基本沒有一個迭代能做完全部任務，問題出在哪？”該問題一提出后，引發了激烈討論：
“我們公司也是，總有那么幾個人完不成手頭任務，每次拖后腿讓客戶不滿意”；
“最近我們項目用了個新框架，很多人他沒用過啊，不知道從哪下手，項目評審的時候一片慘淡”。
其實上述幾種情況歸根到底都屬於需求無法按時交付，類似這樣的困擾你是否也遇到過呢？
問題分析
在交流中，筆者了解到每家公司的情況：
- 背景中第一家企業在第一個迭代認領了15個故事，團隊很容易就完成了；老板覺得以團隊的能力可以做到每個迭代完成30個故事，於是后續每個迭代都希望團隊認領30個故事，團隊認領30個任務后，累死累活只能完成20左右的故事；
- 第二家企業研發團隊8人，每個迭代總有兩個成員工作完不成：團隊每天早會正常開，但是總感覺那兩個成員整個迭代都在做那一兩個故事，做的功能也沒啥進展，有時候還做不完；
- 第三家企業使用了一個新框架，近兩個迭代團隊按以往的速率進行任務認領，結果由於團隊對框架不熟，每個迭代只完成了沖刺待辦列表中一半的故事。
筆者結合交流結果及以往經驗，對需求延期交付的原因進行了如下分析：
需求延期交付通常有兩方面原因——團隊主觀原因以及客觀原因。客觀原因通常是由過程方面的阻塞造成的，比如團隊需要購買一批雲資源，公司規定資源采購需要老板最終審批簽字方可實施，正巧趕上老板出差無法簽字，導致工作卡在最終審批環節無法交付。
沒有客觀因素干擾，需求無法按時交付通常就是指團隊手頭工作在迭代結束前無法全部完成，這是主觀原因。造成團隊手頭工作完不成的原因有很多，背景中提到的原因可概括為以下三種：
-
沖刺待辦列表故事過多
沖刺待辦列表是計划會議的輸出之一，計划會議上團隊根據團隊速率認領故事，形成沖刺待辦列表；如果團隊速率被高估或者個別故事估值偏小，則沖刺待辦列表中的故事點數相對團隊真實速率就會偏多，最終導致工作過多，迭代結束時部分需求無法按時交付。
沖刺待辦列表中故事過多還有一種可能：計划會議輸出的沖刺待辦列表是合理的，可是由於一些突發因素，產品負責人向迭代插入了新的任務，導致沖刺待辦列表故事太多。
-
工作技術難度較高
項目使用了新的框架、語言、工具等，團隊之前沒接觸過，需要一定時間去磨合，所以前期難免出現延遲交付。工作技術難度較高是相對於團隊平均水平來說的，如果團隊整體技能水平偏薄弱，比如都是團隊成員都是剛入行的新人，普通研發工作相對這個團隊來說都很困難，這種情況也很容易出現延遲交付。
-
個別員工工作完不成
團隊某位成員請假了，原本計划完成的工作因為請假只做到一半，所以最后無法按時交付；另外如果團隊成員沒做到自組織，在項目中出工不出力，也容易導致迭代結束手頭工作沒有完成；最后如果團隊成員工作遇到障礙被卡住，該成員不向團隊暴露障礙，而是一直自己孤軍奮戰，也會導致需求延期交付。
除請假外，其他兩種情況都可以通過敏捷的風險管控方法（如每日站會）避免發生，所以這種情況也可以總結為團隊風險管控沒有做好。
解決措施
針對分析中客觀原因部分，團隊可以通過建立Backup的形式進行避免。以采購為例，項目經理或老板秘書做老板的Backup，當老板由於自身原因無法親自審批時，Backup可向老板匯報，征得老板同意后代替老板審批，避免流程方面的因素影響團隊交付，也體現了敏捷宣言中的“個體與交互勝過流程與工具”。
針對團隊主觀原因部分，本文基於合理開展敏捷活動給出如下措施。
針對沖刺待辦列表故事過多
沖刺待辦列表故事過多的主要原因是高估團隊速率，故事大小估算錯誤以及迭代中有新需求插入。針對這三種情況，給出如下解決方案：
合理估算團隊速率，按照速率認領故事
團隊速率是團隊在迭代中認領多少故事的依據。
在敏捷轉型初期，由於團隊沒有歷史數據做參考，很容易估算錯團隊速率，導致沖刺待辦列表中故事過多或過少——故事過多則可能導致延期交付；故事過少，則會浪費開發資源。如何估算團隊速率呢？
確定開發團隊每天在開發工作上投入的時間（刨除會議，接打電話，收發郵件等時間），將時間乘以迭代天數，即可得出迭代中團隊用於開發沖刺任務的生產力。然后團隊從產品待辦列表中選擇一系列故事，預估這些故事的完成時間和用於開發沖刺任務的生產力相近，然后統計這些故事的點數，即可估算出團隊速率。起初估算結果可能不准確，但是通常團隊對速率的估算會隨着迭代進行而愈加准確。
舉個例子：團隊5個開發人員，其中三個人每天有6.5小時用來工作，其余二人每天有6小時可以工作，迭代兩周（10 工作日），那么團隊可工作的時間總和就是（6.5×3+6×2）×10=315。我們從產品待辦列表中選擇315小時左右的故事放入沖刺待辦列表。沖刺待辦列表詳細信息如下（本文故事由華為雲DevCloud進行管理）：
由圖可看出團隊速率大概是33左右。也就是說，計划會議中團隊從產品待辦列表中選擇30個故事點的故事放到沖刺待辦列表，進行開發，團隊有可能全部交付，而選擇50個，則全部交付是有困難的。
根據團隊速率認領故事，可以讓團隊量力而行，有效地減少延期交付。
正確估算故事大小
除了對團隊速率估算錯誤，對故事大小估算錯誤也容易導致延遲交付，關於故事大小的估算方法可以參考【DevCloud · 敏捷智庫】如何估算第二篇：利用核心概念解決估算常見問題
需求置換
敏捷迭代中由於時間盒和工作量都固定，如果有新需求加入迭代——比如生產環境突然發現一個之前沒測出的Bug，需要修復，迭代工作量可能會超出團隊生產力，導致延遲交付。
出現這種情況時，團隊應該如何應對？
- 首先團隊需要向產品負責人確認新需求是否應納入本輪迭代，做到需求來源唯一；
- 當確定需求要做，產品負責人將新需求以用戶故事形式放入沖刺待辦列表中，然后和團隊一起重新梳理沖刺待辦列表；
- 將工作量與新故事相近的低優先級故事移出本輪迭代，放回產品待辦列表，以確保當前迭代團隊工作總量不變，形成需求置換。
Tips：團隊在計划會議領取任務時，不要領取的太滿，最好預留一些緩沖時間，以便於應對突發情況。
如果產品負責人迫於領導或客戶壓力，不允許需求置換，只能向沖刺待辦列表中硬塞故事，這時候應該怎么辦呢？在敏捷中，Scrum Master作用之一是扮演團隊的“保護傘”，讓團隊集中精力去完成迭代目標。如果產品負責人強制的向迭代中添加故事，Scrum Master可與對方溝通，弄清楚對方為什么向迭代中插入故事——之前整理故事有遺漏或者發現了以前未測出的Bug，還是對方不知道Scrum不建議向進行中的迭代插故事。如果是需求遺漏，應該在回顧會議上總結經驗，日后避免；如果對方不了解Scrum，可以通過講解Scrum相關知識，讓對方理解為什么Scrum不建議向進行中的迭代加入新故事，以后避免這種情況發生。
加班也是一個應對突發問題的選擇，但是研究表明短期加班會提高效率，長期加班團隊成員會因休息不足，注意力不集中等原因降低效率。長期加班除了不利於團隊建設之外，不定時的加班對團隊速率也有很大影響，而敏捷提倡可持續發展，所以加班解決突發問題屬下策。
針對工作技術難度較高
對於項目技術難度要求超出團隊能力，成員無法估算工作量或無從下手導致項目交付延期的情況，可以利用“探針（Spike）”技術評估項目。
探針是一種敏捷實踐。當遇到無法估算，或無從下手的故事時，團隊可以從這個大故事中分割出一個小故事，然后對小故事進行開發，這個小故事就是探針。探針的開發完成時間可作為估算整個故事完成時間的依據，后續估算有了依據，就會准確很多，延遲交付的風險也會隨之減少。
當然除了探針技術，團隊成員的技術培訓也是必不可少的——團隊內技術分享或培訓，可以提高團隊整體技術水平，從而提高研發效率、減少特性延遲交付的風險。
針對個別員工工作完不成
每日站會是一個很好的風險管控工具。迭代中的每一天都可以看成是一個小迭代，每日站會通過保證小迭代正常運行，進而保證整個迭代的穩定進行。每日站會如果只匯報工作，通常會變得浮於形式，各種風險可能也無法被確認，最后導致每日站會發揮不了自身作用。認真開好每日站會可以預防延遲交付。
團隊成員在每日站會“前一天做了什么”，“今天要做什么”的基礎上，陳述工作詳細情況以及具體進度，這樣可以讓團隊的工作狀態更加透明。從團隊風險管控角度來看“我昨天用了5小時開發A功能，目前A功能開發了50%，今天預計再投入5小時，開發至80%”比“我昨天開發了A功能，今天要繼續開發A功能”要好得多。
另外借用一些項目管理工具，可以更直觀的看出員工的工作狀態。以華為雲DevCloud項目管理功能為例，在故事中，可以清楚地看到員工的實際工時和故事的完成度，便於了解和把控故事延遲交付的風險。
沒做好風險管控會影響故事的按時交付，每日站會通過“我遇到什么風險”識別團隊遇到的風險。遇到風險時，首先團隊成員可以指定團隊中某一成員，讓其幫忙清楚風險；當然團隊成員也可以主動幫忙清除風險。如果團隊內沒有人能夠清除風險，這時候Scrum Master就應該發揮“清道夫”的作用，通過協調內部或外部資源來解決風險，幫助團隊掃清障礙，以確保項目可以按時交付。
想了解更多關於每日站會的內容可以參考：【DevCloud · 敏捷智庫】如何玩轉每日站會？
參考附錄
【DevCloud · 敏捷智庫】如何估算第二篇：利用核心概念解決估算常見問題
Mike Cohn 敏捷軟件開發實踐——估算與計划 北京：清華大學出版社