問題分析

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

• 第一家企業(yè)在第一個迭代認領(lǐng)了15個故事，團隊很容易就完成了；老板覺得以團隊的能力可以做到每個迭代完成30個故事，于是后續(xù)每個迭代都希望團隊認領(lǐng)30個故事，團隊認領(lǐng)30個任務(wù)后，累死累活只能完成20左右的故事；
• 第二家企業(yè)研發(fā)團隊8人，每個迭代總有兩個成員工作完不成：團隊每天早會正常開，但是總感覺那兩個成員整個迭代都在做那一兩個故事，做的功能也沒啥進展，有時候還做不完；
• 第三家企業(yè)使用了一個新框架，近兩個迭代團隊按以往的速率進行任務(wù)認領(lǐng)，結(jié)果由于團隊對框架不熟，每個迭代只完成了沖刺待辦列表中一半的故事。

筆者結(jié)合交流結(jié)果及以往經(jīng)驗，對需求延期交付的原因進行了如下分析：

需求延期交付通常有兩方面原因——團隊主觀原因以及客觀原因?？陀^原因通常是由過程方面的阻塞造成的，比如團隊需要購買一批云資源，公司規(guī)定資源采購需要老板最終審批簽字方可實施，正巧趕上老板出差無法簽字，導(dǎo)致工作卡在最終審批環(huán)節(jié)無法交付。

沒有客觀因素干擾，需求無法按時交付通常就是指團隊手頭工作在迭代結(jié)束前無法全部完成，這是主觀原因。造成團隊手頭工作完不成的原因有很多，背景中提到的原因可概括為以下三種：

沖刺待辦列表故事過多

沖刺待辦列表是計劃會議的輸出之一，計劃會議上團隊根據(jù)團隊速率認領(lǐng)故事，形成沖刺待辦列表；如果團隊速率被高估或者個別故事估值偏小，則沖刺待辦列表中的故事點數(shù)相對團隊真實速率就會偏多，最終導(dǎo)致工作過多，迭代結(jié)束時部分需求無法按時交付。

沖刺待辦列表中故事過多還有一種可能：計劃會議輸出的沖刺待辦列表是合理的，可是由于一些突發(fā)因素，產(chǎn)品負責(zé)人向迭代插入了新的任務(wù)，導(dǎo)致沖刺待辦列表故事太多。

工作技術(shù)難度較高

項目使用了新的框架、語言、工具等，團隊之前沒接觸過，需要一定時間去磨合，所以前期難免出現(xiàn)延遲交付。工作技術(shù)難度較高是相對于團隊平均水平來說的，如果團隊整體技能水平偏薄弱，比如都是團隊成員都是剛?cè)胄械男氯耍胀ㄑ邪l(fā)工作相對這個團隊來說都很困難，這種情況也很容易出現(xiàn)延遲交付。

個別員工工作完不成

團隊某位成員請假了，原本計劃完成的工作因為請假只做到一半，所以最后無法按時交付；另外如果團隊成員沒做到自組織，在項目中出工不出力，也容易導(dǎo)致迭代結(jié)束手頭工作沒有完成；最后如果團隊成員工作遇到障礙被卡住，該成員不向團隊暴露障礙，而是一直自己孤軍奮戰(zhàn)，也會導(dǎo)致需求延期交付。

除請假外，其他兩種情況都可以通過敏捷的風(fēng)險管控方法（如每日站會）避免發(fā)生，所以這種情況也可以總結(jié)為團隊風(fēng)險管控沒有做好。

解決措施

針對分析中客觀原因部分，團隊可以通過建立Backup的形式進行避免。以采購為例，項目經(jīng)理或老板秘書做老板的Backup，當(dāng)老板由于自身原因無法親自審批時，Backup可向老板匯報，征得老板同意后代替老板審批，避免流程方面的因素影響團隊交付，也體現(xiàn)了敏捷宣言中的“個體與交互勝過流程與工具”。

針對團隊主觀原因部分，本文基于合理開展敏捷活動給出如下措施。

針對沖刺待辦列表故事過多

沖刺待辦列表故事過多的主要原因是高估團隊速率，故事大小估算錯誤以及迭代中有新需求插入。針對這三種情況，給出如下解決方案：

合理估算團隊速率，按照速率認領(lǐng)故事

團隊速率是團隊在迭代中認領(lǐng)多少故事的依據(jù)。

在敏捷轉(zhuǎn)型初期，由于團隊沒有歷史數(shù)據(jù)做參考，很容易估算錯團隊速率，導(dǎo)致沖刺待辦列表中故事過多或過少——故事過多則可能導(dǎo)致延期交付；故事過少，則會浪費開發(fā)資源。如何估算團隊速率呢？

確定開發(fā)團隊每天在開發(fā)工作上投入的時間（刨除會議，接打電話，收發(fā)郵件等時間），將時間乘以迭代天數(shù)，即可得出迭代中團隊用于開發(fā)沖刺任務(wù)的生產(chǎn)力。然后團隊從產(chǎn)品待辦列表中選擇一系列故事，預(yù)估這些故事的完成時間和用于開發(fā)沖刺任務(wù)的生產(chǎn)力相近，然后統(tǒng)計這些故事的點數(shù)，即可估算出團隊速率。起初估算結(jié)果可能不準確，但是通常團隊對速率的估算會隨著迭代進行而愈加準確。

舉個例子：團隊5個開發(fā)人員，其中三個人每天有6.5小時用來工作，其余二人每天有6小時可以工作，迭代兩周（10 工作日），那么團隊可工作的時間總和就是（6.5×3+6×2）×10=315。我們從產(chǎn)品待辦列表中選擇315小時左右的故事放入沖刺待辦列表。沖刺待辦列表詳細信息如下（本文故事由華為云DevCloud進行管理）：

由圖可看出團隊速率大概是33左右。也就是說，計劃會議中團隊從產(chǎn)品待辦列表中選擇30個故事點的故事放到?jīng)_刺待辦列表，進行開發(fā)，團隊有可能全部交付，而選擇50個，則全部交付是有困難的。

根據(jù)團隊速率認領(lǐng)故事，可以讓團隊量力而行，有效地減少延期交付。

正確估算故事大小

除了對團隊速率估算錯誤，對故事大小估算錯誤也容易導(dǎo)致延遲交付，關(guān)于故事大小的估算方法可以參考【DevCloud · 敏捷智庫】如何估算第二篇：利用核心概念解決估算常見問題

需求置換

敏捷迭代中由于時間盒和工作量都固定，如果有新需求加入迭代——比如生產(chǎn)環(huán)境突然發(fā)現(xiàn)一個之前沒測出的Bug，需要修復(fù)，迭代工作量可能會超出團隊生產(chǎn)力，導(dǎo)致延遲交付。

出現(xiàn)這種情況時，團隊?wèi)?yīng)該如何應(yīng)對？

• 首先團隊需要向產(chǎn)品負責(zé)人確認新需求是否應(yīng)納入本輪迭代，做到需求來源唯一；
• 當(dāng)確定需求要做，產(chǎn)品負責(zé)人將新需求以用戶故事形式放入沖刺待辦列表中，然后和團隊一起重新梳理沖刺待辦列表；
• 將工作量與新故事相近的低優(yōu)先級故事移出本輪迭代，放回產(chǎn)品待辦列表，以確保當(dāng)前迭代團隊工作總量不變，形成需求置換。

Tips

團隊在計劃會議領(lǐng)取任務(wù)時，不要領(lǐng)取的太滿，最好預(yù)留一些緩沖時間，以便于應(yīng)對突發(fā)情況。

如果產(chǎn)品負責(zé)人迫于領(lǐng)導(dǎo)或客戶壓力，不允許需求置換，只能向沖刺待辦列表中硬塞故事，這時候應(yīng)該怎么辦呢？在敏捷中，Scrum Master作用之一是扮演團隊的“保護傘”，讓團隊集中精力去完成迭代目標(biāo)。如果產(chǎn)品負責(zé)人強制的向迭代中添加故事，Scrum Master可與對方溝通，弄清楚對方為什么向迭代中插入故事——之前整理故事有遺漏或者發(fā)現(xiàn)了以前未測出的Bug，還是對方不知道Scrum不建議向進行中的迭代插故事。如果是需求遺漏，應(yīng)該在回顧會議上總結(jié)經(jīng)驗，日后避免；如果對方不了解Scrum，可以通過講解Scrum相關(guān)知識，讓對方理解為什么Scrum不建議向進行中的迭代加入新故事，以后避免這種情況發(fā)生。

加班也是一個應(yīng)對突發(fā)問題的選擇，但是研究表明短期加班會提高效率，長期加班團隊成員會因休息不足，注意力不集中等原因降低效率。長期加班除了不利于團隊建設(shè)之外，不定時的加班對團隊速率也有很大影響，而敏捷提倡可持續(xù)發(fā)展，所以加班解決突發(fā)問題屬下策。

針對工作技術(shù)難度較高

對于項目技術(shù)難度要求超出團隊能力，成員無法估算工作量或無從下手導(dǎo)致項目交付延期的情況，可以利用“探針（Spike）”技術(shù)評估項目。

探針是一種敏捷實踐。當(dāng)遇到無法估算，或無從下手的故事時，團隊可以從這個大故事中分割出一個小故事，然后對小故事進行開發(fā)，這個小故事就是探針。探針的開發(fā)完成時間可作為估算整個故事完成時間的依據(jù)，后續(xù)估算有了依據(jù)，就會準確很多，延遲交付的風(fēng)險也會隨之減少。

當(dāng)然除了探針技術(shù)，團隊成員的技術(shù)培訓(xùn)也是必不可少的——團隊內(nèi)技術(shù)分享或培訓(xùn)，可以提高團隊整體技術(shù)水平，從而提高研發(fā)效率、減少特性延遲交付的風(fēng)險。

針對個別員工工作完不成

每日站會是一個很好的風(fēng)險管控工具。迭代中的每一天都可以看成是一個小迭代，每日站會通過保證小迭代正常運行，進而保證整個迭代的穩(wěn)定進行。每日站會如果只匯報工作，通常會變得浮于形式，各種風(fēng)險可能也無法被確認，最后導(dǎo)致每日站會發(fā)揮不了自身作用。認真開好每日站會可以預(yù)防延遲交付。

團隊成員在每日站會“前一天做了什么”，“今天要做什么”的基礎(chǔ)上，陳述工作詳細情況以及具體進度，這樣可以讓團隊的工作狀態(tài)更加透明。從團隊風(fēng)險管控角度來看“我昨天用了5小時開發(fā)A功能，目前A功能開發(fā)了50%，今天預(yù)計再投入5小時，開發(fā)至80%”比“我昨天開發(fā)了A功能，今天要繼續(xù)開發(fā)A功能”要好得多。

另外借用一些項目管理工具，可以更直觀的看出員工的工作狀態(tài)。以華為云DevCloud項目管理功能為例，在故事中，可以清楚地看到員工的實際工時和故事的完成度，便于了解和把控故事延遲交付的風(fēng)險。

沒做好風(fēng)險管控會影響故事的按時交付，每日站會通過“我遇到什么風(fēng)險”識別團隊遇到的風(fēng)險。遇到風(fēng)險時，首先團隊成員可以指定團隊中某一成員，讓其幫忙清楚風(fēng)險；當(dāng)然團隊成員也可以主動幫忙清除風(fēng)險。如果團隊內(nèi)沒有人能夠清除風(fēng)險，這時候Scrum Master就應(yīng)該發(fā)揮“清道夫”的作用，通過協(xié)調(diào)內(nèi)部或外部資源來解決風(fēng)險，幫助團隊掃清障礙，以確保項目可以按時交付。

以上就是詳解敏捷過程中的需求管理的詳細內(nèi)容，更多關(guān)于敏捷過程中的需求管理的資料請關(guān)注腳本之家其它相關(guān)文章！

最新評論