問題分析

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

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

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

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

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

沖刺待辦列表故事過多

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

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

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

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

個別員工工作完不成

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

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

解決措施

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

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

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

沖刺待辦列表故事過多的主要原因是高估團(tuán)隊(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ù)做參考，很容易估算錯團(tuán)隊(duì)速率，導(dǎo)致沖刺待辦列表中故事過多或過少——故事過多則可能導(dǎo)致延期交付；故事過少，則會浪費(fèi)開發(fā)資源。如何估算團(tuán)隊(duì)速率呢？

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

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

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

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

正確估算故事大小

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

需求置換

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

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

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

Tips

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

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

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

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

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

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

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

針對個別員工工作完不成

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

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

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

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

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

最新評論