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

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

沖刺永遠不會讓我們失望，我們讓沖刺失敗。

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

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

在一個完美的世界里，沖刺應該是關于計劃你的工作和執行你的計劃。但是產品開發是一個持續的過程，涉及多次迭代，存在太多的外部依賴性。計劃外的工作在沖刺中是不可避免的，大多數團隊甚至會為計劃外的工作預留大量非核心時間。但是，如果團隊將超過 10% 的有效編碼時間花在計劃外工作上，這就是沖刺失敗的完美因素。

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

大量計劃外工作是當前沖刺的首要反模式。

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

如何解決計劃外工作

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

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

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

2. Bug vs. 故事 vs. 問題

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

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

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

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

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

現在讓我們談談更可持續的方式。

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

3. 團隊健康狀況下降

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

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

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

如何確保開發人員的生產力

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

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

4. 跳過 Sprint 回顧

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

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

如何進行有效的 Sprint Retros

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

借助數據驅動的洞察力，團隊可以輕松解決沖刺挑戰，甚至可以找出阻礙因素的根本原因。這些數據鼓勵針對尋找長期解決方案的富有成效的討論。例如，如果團隊意識到由于高周期時間他們發布的功能較少，他們可以更深入地挖掘導致峰值的原因，并在下一次 sprint 計劃會議之前解決它。

結論

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

讓你的整個團隊參與到這個過程中，從計劃到沖刺中期的干擾，再到回顧。設定可衡量和可實現的目標，分配足夠的緩沖時間，并專注于鉆取數據以獲取可能改變團隊執行沖刺方式的洞察力。

健康的沖刺對整個業務周期中的每個人都是雙贏的：從客戶到 CTO、CEO、工程經理和個人貢獻者。