Sprint失败的四个迹象，以及四种修复方法

sprint计划不一定是一场斗争。了解无效冲刺的四个警告标志以及如何解决它们，以便您的团队保持正轨。

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、工程经理和个人贡献者。