問題分析

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

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

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

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

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

沖刺待辦列表故事過多

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

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

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

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

個(gè)別員工工作完不成

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

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

解決措施

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

針對(duì)團(tuán)隊(duì)主觀原因部分，本文基于合理開展敏捷活動(dòng)給出如下措施。

針對(duì)沖刺待辦列表故事過多

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

合理估算團(tuán)隊(duì)速率，按照速率認(rèn)領(lǐng)故事

團(tuán)隊(duì)速率是團(tuán)隊(duì)在迭代中認(rèn)領(lǐng)多少故事的依據(jù)。

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

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

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

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

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

正確估算故事大小

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

需求置換

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

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

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

Tips

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

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

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

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

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

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

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

針對(duì)個(gè)別員工工作完不成

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

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

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

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

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