sprint計劃不一定是一場斗爭。了解無效沖刺的四個警告標(biāo)志以及如何解決它們，以便您的團(tuán)隊保持正軌。 sprint計劃不一定是一場斗爭。了解無效沖刺的四個警告標(biāo)志以及如何解決它們，以便您的團(tuán)隊保持正軌。

sprint在敏捷中有著神圣的地位，經(jīng)常被用作精簡工程團(tuán)隊的承諾工具。這些為期兩周的限時活動將您的產(chǎn)品愿望清單轉(zhuǎn)化為可操作的任務(wù)，將頭腦風(fēng)暴轉(zhuǎn)化為具體結(jié)果，甚至營造一種評論和回顧的文化。

(相關(guān)資料圖)

Sprint 不僅可以加速項目交付，還可以營造一種問責(zé)文化，尤其是在分散在不同地域的團(tuán)隊中。雖然沖刺一直是快速推進(jìn)項目管理的可靠方法，但如果做得不好，它們會造成嚴(yán)重的流程不平衡。

沖刺永遠(yuǎn)不會讓我們失望，我們讓沖刺失敗。

運行一個新的沖刺就像主持一個項目，同時為改進(jìn)創(chuàng)造空間。由于沖刺是持續(xù)時間較短的事件，因此團(tuán)隊通常難以識別沖刺何時偏離其最初接受的目標(biāo)。幸運的是，有幾個關(guān)鍵指標(biāo)可以在沖刺計劃失敗時發(fā)出信號。

1. 沖刺期間更多的計劃外工作

在一個完美的世界里，沖刺應(yīng)該是關(guān)于計劃你的工作和執(zhí)行你的計劃。但是產(chǎn)品開發(fā)是一個持續(xù)的過程，涉及多次迭代，存在太多的外部依賴性。計劃外的工作在沖刺中是不可避免的，大多數(shù)團(tuán)隊甚至?xí)橛媱澩獾墓ぷ黝A(yù)留大量非核心時間。但是，如果團(tuán)隊將超過 10% 的有效編碼時間花在計劃外工作上，這就是沖刺失敗的完美因素。

計劃外的工作是任何阻礙開發(fā)人員進(jìn)行實際工作的事情——從讓燈一直亮著到因為不穩(wěn)定的構(gòu)建而卡住。還記得你因為代碼補丁沒有重構(gòu)而失敗而不得不暫停你的代碼嗎？這就是計劃外工作的作用。它使開發(fā)人員不斷交火，甚至分散了他們對實際沖刺任務(wù)的注意力。

大量計劃外工作是當(dāng)前沖刺的首要反模式。

如果團(tuán)隊沒有正確估計計劃工作所需的工作量，或者沒有考慮可能出現(xiàn)的潛在問題，則可能導(dǎo)致計劃外工作的增加。此外，它還可能會影響開發(fā)人員的生產(chǎn)力和團(tuán)隊士氣，因為額外的工作可能會妨礙預(yù)先確定的沖刺目標(biāo)。

如何解決計劃外工作

事實上，計劃外的工作會一直存在，無法完全消除。但是我們可以做一些事情來限制意外和偏離你的 sprint 工作，并壓倒你的 sprint 積壓。

數(shù)據(jù)是解決工程團(tuán)隊計劃外工作挑戰(zhàn)的一種方法。在你的下一個沖刺回顧中，抽出 15 分鐘的時間來討論計劃外工作與計劃故事點的份額。這樣，團(tuán)隊可以在即將到來的沖刺中擠出一些空閑時間來進(jìn)行計劃外的工作。

良好的文檔為工程團(tuán)隊解決了許多交付挑戰(zhàn)，其中之一就是計劃外工作。支持資源、任何把關(guān)信息、培訓(xùn)支持或特定構(gòu)建失敗的更多上下文在減少一些計劃外工作方面大有幫助。

2. Bug vs. 故事 vs. 問題

確保工作一致性與通過沖刺目標(biāo)確保團(tuán)隊一致性一樣重要。每個沖刺的每個開發(fā)人員的錯誤、故事和問題日志的健康組合可以幫助實現(xiàn)它。

錯誤疲勞是真實存在的。當(dāng)開發(fā)人員將太多時間花在調(diào)試上而不是交付故事點時，就會發(fā)生這種情況。錯誤是不可避免的，就像計劃外的工作一樣。但是，如果開發(fā)人員花費太多時間——甚至超過他們總沖刺時間的 20% 來解決代碼問題——這是下一個危險信號團(tuán)隊?wèi)?yīng)該警惕的。

在 bug 上投入過多的資源有時會以錯過有價值的功能為代價。此外，如果一個團(tuán)隊過度優(yōu)先考慮錯誤，那么他們就處于協(xié)作中斷和沖刺速度低下的邊緣。當(dāng)團(tuán)隊沒有正確估計工作的復(fù)雜性時，通常會發(fā)生這種情況。

如何最大程度地減少錯誤疲勞

快速修復(fù)是為每個不屬于實際沖刺的錯誤創(chuàng)建一個單獨的故事點。然而，創(chuàng)建新的故事點并不能解決沖刺中錯誤過多的實際問題。

現(xiàn)在讓我們談?wù)劯沙掷m(xù)的方式。

使用工程分析工具可視化您的沖刺問題分解。為所有問題類型創(chuàng)建優(yōu)先級部分——錯誤、故事點，甚至事件。嘗試記錄您的工程團(tuán)隊可能遇到的所有問題。在計劃會議期間優(yōu)先過濾這些問題。

3. 團(tuán)隊健康狀況下降

開發(fā)人員的滿意度總是與沖刺效率成正比，但大多數(shù)經(jīng)理未能將開發(fā)人員的辛勞與沖刺失敗聯(lián)系起來。大多數(shù)工程團(tuán)隊都遵循“開發(fā)人員在性能下工作得最好”的方法。這是沖刺表現(xiàn)不佳甚至失敗的完美秘訣。

EM 比任何人都更了解他們的開發(fā)人員——他們的能力、缺點以及他們在什么情況下表現(xiàn)出色。向開發(fā)人員分配超出其工作能力的任務(wù)可能會破壞團(tuán)隊的交付能力。

大多數(shù)開發(fā)人員都在包容內(nèi)向的人，實際上他們每次負(fù)擔(dān)過重時都很難開口說話。高估工作負(fù)載帶寬可能會導(dǎo)致開發(fā)人員很快精疲力竭，甚至導(dǎo)致他們辭職或產(chǎn)生無效率的工作。

如何確保開發(fā)人員的生產(chǎn)力

在這里，工程經(jīng)理有責(zé)任為每個開發(fā)人員創(chuàng)建健康的問題組合。如果開發(fā)人員在 sprint 的最初幾天被事件警報過多地呼叫，管理人員可以及時切斷他們的一些燈，并將開發(fā)人員轉(zhuǎn)移到功能發(fā)布上。

有時，甚至為開發(fā)人員分配空閑時間也可以幫助他們在即將到來的沖刺中恢復(fù)活力并更好地重建。

4. 跳過 Sprint 回顧

進(jìn)行 sprint 回顧的想法是記錄本次 sprint 哪些有效，哪些無效，以及挑戰(zhàn)和障礙。sprint 回顧會議是團(tuán)隊討論反饋和編制可操作改進(jìn)列表的理想場所，但大多數(shù)團(tuán)隊成員故意跳過它們。

大多數(shù)開發(fā)人員討厭復(fù)古。對他們來說，回顧是單調(diào)的，缺乏支持沖刺結(jié)果的數(shù)據(jù)，甚至不能給下一個沖刺帶來任何真正的改變。有時，這些回顧是半心半意地進(jìn)行的，而在其他時候，缺乏對沖刺績效的可見性阻礙了可操作的回顧。如果回顧一直在沒有任何明確結(jié)果的情況下進(jìn)行，它們可能會浪費時間并失去效力。

如何進(jìn)行有效的 Sprint Retros

將 Scrum 回顧視為工程團(tuán)隊反思其績效的機會。工作分析可以提高對 sprint 趨勢的可見性，這樣團(tuán)隊就可以對這個 sprint 中所有有效/無效的事情有一個真實的了解。

借助數(shù)據(jù)驅(qū)動的洞察力，團(tuán)隊可以輕松解決沖刺挑戰(zhàn)，甚至可以找出阻礙因素的根本原因。這些數(shù)據(jù)鼓勵針對尋找長期解決方案的富有成效的討論。例如，如果團(tuán)隊意識到由于高周期時間他們發(fā)布的功能較少，他們可以更深入地挖掘?qū)е路逯档脑?，并在下一?sprint 計劃會議之前解決它。

結(jié)論

安迪·希爾斯 (Andy Hiles) 將每個沖刺稱為實驗，以查看“我們是否回答了我們打算解決的問題”，這很有道理。讓沖刺正確是邁向成功的項目交付和卓越產(chǎn)品開發(fā)的第一步。

讓你的整個團(tuán)隊參與到這個過程中，從計劃到?jīng)_刺中期的干擾，再到回顧。設(shè)定可衡量和可實現(xiàn)的目標(biāo)，分配足夠的緩沖時間，并專注于鉆取數(shù)據(jù)以獲取可能改變團(tuán)隊執(zhí)行沖刺方式的洞察力。

健康的沖刺對整個業(yè)務(wù)周期中的每個人都是雙贏的：從客戶到 CTO、CEO、工程經(jīng)理和個人貢獻(xiàn)者。