在Scrum中，如何在冲刺结束时处理争用/工作量

我的团队几年前开始使用Scrum。我们的项目涉及构建与物理设备（例如机器人和传感器）接口的软件，而我们典型的产品积压订单通常表示向整个系统添加控制设备。

我们将任务分解为接近此处的示例。每个设备集成功能都分为代码，测试，集成测试，同行评审等。显然，每个产品待办事项都有固有的顺序。通常，我们的冲刺持续2周，团队中有4至6名成员。

在冲刺结束时遇到了两个问题：

• 首先是在冲刺结束时让每个人都忙。
• 第二个（相关的）是系统争用。在冲刺的最后几天，我们几乎完成了集成。我们只有一个集成系统，因此人们通常无法继续工作，因为他们无法访问该系统。由于这是sprint的结尾，因此sprint积压工作中没有太多工作要做。这些人应该做什么工作？由于当前项目尚未完成，因此产品所有者无法很好地从产品待办事项列表的顶部提取项目。处理技术债务将对整个项目有所帮助，但不会帮助完成冲刺。

是否有任何最佳实践可用于构建sprint以避免这些问题？与产品负责人进行谈判的技巧？

从某些方面来说，最好是在冲刺结束时保持缓慢，这意味着您的估计不错，而且不要忙于忙碌，我一直在为我工作过的Scrum团队投入精力，我们总是会为接下来的工作添加研究任务短跑。

这可能是在为即将发生的事情做概念证明，或者是在哪里重构现有代码，努力在代码上获得更好的测试覆盖率，等等。

您应该修复集成系统，以便您的团队可以在完成每个任务后立即集成他们的工作，而不是在冲刺结束时等待大爆炸。

我建议使用足够短的用户故事，以便几天之内完成。此处完成表示代码已完成，经过测试和集成。

记住，交付团队本身而不是单个成员是整个团队的责任，就有可能让所有四到六个成员一起完成每个任务-将每个任务推进整个过程，然后转移到下一个任务。起初听起来效率低下，但是如果您看到的瓶颈很严重，则可能是有效的选择。

另外，您可能希望研究约束理论（Goldratt的The Goal），并了解如何最好地分析这些集成瓶颈的原因和位置。

我们通过采用看板方法解决了这一问题。

跟踪软件（Jira）中的最大值和最小值都有队列。

我们根据需要进行修饰。可能每周一次，可能是3次，取决于限制和完成的工作。

这将帮助您使产品负责人专注于使您的队列有很多工作要做，并且可以减少单个票证的微观管理。请记住，与往常一样，改变将需要时间。

我们仍然每两周进行一次演示，并且每周发布一次。

哇，如果您不说机器人，我想您现在就在我的团队中。我们有确切的同样的问题。在完成了许多敏捷项目后，他们对宣言的忠诚度和成功程度都不同，我的分析是，我们的问题是冲刺太短了。我们正在进行两个星期的冲刺，这会导致一些问题。其中之一是，我们最终会在计划上过分谨慎，并最终以无聊的日子结束。其次是巨大的审查，回顾和计划听闻，每两周需要1-2天。正如您所说，另一个问题是必须在检查的最后一刻进行整合，并且经常需要数小时才能完成。我的第一个也是最成功的敏捷项目有四个星期的冲刺，按照行业标准，我收集到的冲刺相当大，但这对我们来说非常有用。

编辑：还记得第一个项目的另一个好处。我们始终有一个完全优先的产品待办事项列表，如果开发人员的冲刺任务已完成且没有其他冲刺任务可用，则给予开发人员自由处理任务的能力。

第二个问题可能是尝试解决非问题1的结果。您应该让不忙的人来帮助他们的同龄人。而不是执行非冲刺任务，这会导致有限集成方面的争执。

另外，您不应该在sprint的末尾进行集成，而应持续进行集成。

您才刚刚开始。让团队有机会通过回顾过程自己解决这个问题。

其次，您的产品所有者应该信任团队，以最好地了解如何组织和优化自己。作为回报，团队相信采购订单可以最好地了解客户的需求。

对于新的敏捷团队来说，这些是非常普遍的挑战。很高兴看到团队何时开始打破自己的孤岛并成长。