從需求到交付——論敏捷過程當中的需求管理

摘要：企業在作敏捷轉型中，需求沒法按時交付的困擾你是否也遇到過呢？

背景

在以前組織的一次敏捷線下活動中，有家企業問道：「咱們公司剛作敏捷轉型不久，遇到一個比較頭疼的問題——團隊天天都很忙，從轉型到如今已經兩個多月了，基本沒有一個迭代能作徹底部任務，問題出在哪？」該問題一提出後，引起了激烈討論：

「咱們公司也是，總有那麼幾我的完不成手頭任務，每次拖後腿讓客戶不滿意」；

「最近咱們項目用了個新框架，不少人他沒用過啊，不知道從哪下手，項目評審的時候一片慘淡」。

其實上述幾種狀況歸根到底都屬於需求沒法按時交付，相似這樣的困擾你是否也遇到過呢？

問題分析

在交流中，筆者瞭解到每家公司的狀況：

• 背景中第一家企業在第一個迭代認領了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 敏捷軟件開發實踐——估算與計劃 北京：清華大學出版社

點擊關注，第一時間瞭解華爲雲新鮮技術~