摘要：企業在做靈活轉型中，需求無法按時傳遞的困擾你是否也遇到過呢？
在之前組織的一次靈活線下活動中，有家企業問道：“我們公司剛做靈活轉型不久，遇到一個比較頭疼的問題——團隊每天都很忙，從轉型到現在已經兩個多月了，基本沒有一個疊代能做完全部任務，問題出在哪？”該問題一提出後，引發了激烈讨論：
“我們公司也是，總有那麼幾個人完不成手頭任務，每次拖後腿讓客戶不滿意”；
“最近我們項目用了個新架構，很多人他沒用過啊，不知道從哪下手，項目評審的時候一片慘淡”。
其實上述幾種情況歸根到底都屬于需求無法按時傳遞，類似這樣的困擾你是否也遇到過呢？
在交流中，筆者了解到每家公司的情況：
背景中第一家企業在第一個疊代認領了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 · 靈活智庫】如何估算第二篇：利用核心概念解決估算常見問題
【DevCloud · 靈活智庫】如何玩轉每日站會？
Mike Cohn 靈活軟體開發實踐——估算與計劃 北京：清華大學出版社
點選關注，第一時間了解華為雲新鮮技術~