在前文中，我探讨了 Scrum 团队内部滋生的一些不良习惯，这些习惯最终会导致交付失败。现在，我想继续深入这个话题，将重点转移到团队内部的运作流程上。
这些流程与团队的技术能力同样重要。即使团队成员在他们即将交付的工作上非常熟练，仍然有一些因素可能会破坏他们的努力。这并非他们的过错，而是项目管理决策的直接责任，以及管理层通过合适的流程支持团队的能力，以明确的目标和可预测的活动来帮助团队运作。
技能高度隔离的团队
试想一下，团队中拥有一批技术精湛的开发人员，他们可以完全独立工作，并且有能力按时完成冲刺中承诺的任务。即使在这样一种理想的情况下（当然，这种情况发生的可能性不高），如果团队成员之间的技能被严格分割，团队也很难跟上不断增长的需求列表。
一些实例
- 团队中只有 1 或 2 名 DevOps 工程师，他们可以修改自动化流程或处理平台中的服务，但团队的其他成员对此一无所知。在例如改进会议等 Scrum 活动中讨论这些故事时，大多数团队成员会因为没有参与感而浪费时间，反之亦然，DevOps 工程师会对其他面向功能的故事不感兴趣，导致会议时间被浪费。
- 整个团队只有一名数据库专家。根据团队正在开发的系统中数据解决方案的复杂性和使用频率，此人可能会不断处理无法及时完成的任务，尤其是在考虑到优先级的情况下。更糟糕的是，其他任务也可能不得不等待，因为它们依赖于数据库任务提供的数据。
- 当一个产品主要面向后端开发时，仅保留一名前端开发人员以备不时之需（因为有时可能需要对 UI 应用程序进行一些小修改）。在这种情况下，大多数 Scrum 活动对这位团队成员来说都是浪费时间，因为他们的知识仅限于前端，其他内容都不重要。
结果
在上述任何一种情况下，结果都是要么有人在浪费时间，要么无法赶上积压的需求。他们要么阻碍团队的其他成员开始处理下一个任务，要么因为冲刺中有太多时间没有被充分利用而降低了 Scrum 团队的整体效率。
然而，团队仍然拥有相同数量的开发人员。从外部来看，团队成员无法承担某些任务，只是因为他们过于专注于特定的技能，这一点是不可见的（甚至不愿暴露）。所以，他们无法帮助其他团队成员处理任务，即使他们有能力，而且任务的优先级也可能允许他们这样做。
产品负责人甚至很难为团队制定有意义的冲刺计划，因为产品负责人必须始终考虑有多少人可以处理每个任务，以及是否将更多类似的任务同时添加到冲刺中，最终可能导致团队能力超负荷，即使实际上有人有能力处理这些任务，只是他们不具备开始这些任务所需的技能。
解决方案
这是一个需要解决的难题，项目经理应该明确选择的道路。具体来说，可以选择：
- 培养更多能够处理广泛任务的全栈开发人员，但他们在很多领域可能不是真正的专家。这样，他们可以覆盖更广的范围，但不能深入挖掘。交付速度可能会很快，但质量可能会受到影响。
- 为每项技术配备专门的专家，然后接受这些限制，并更努力地规划适合的冲刺内容。这样，他们可以深入研究并构建出色的任务，但这些任务需要按顺序处理，因此交付所需的时间更长。
弱势的产品负责人
这不一定是一个定义明确的“流程问题”，但我把它放在这里是因为创建扎实的任务可以被视为团队应该拥有的可靠的流程，并且这些流程与开发团队兼容。
我所说的弱势并不一定是指某个人的知识水平，而是指产品负责人服务于团队任务的能力，这些任务应该能够被开发人员理解，并且从产品路线图的角度来看具有清晰的意义。对于一个成功的 Scrum 团队来说，这两者都非常重要。
如果任务缺少开发人员能够清楚理解的目标、功能价值或技术细节，那么基本上会发生两种情况：
- 开发人员会构建与产品负责人实际想要的东西不同的东西。在冲刺期间甚至很难发现这个问题，因为大多数产品负责人没有能力在如此详细的层面上跟踪任务的进度，而且大多数产品负责人只是期望事情会自然发生。
- 开发人员会花费太多时间来澄清任务并反复讨论，而不是开始构建它们。这涉及到许多额外的沟通、反复的协议，以及将工作推迟到冲刺的后期阶段。最终，任务的原始估计不再准确，并且任务无法在冲刺内完成并进入下一个冲刺。在最糟糕的情况下，这种情况会在后续冲刺中反复发生。
自我反省
通常很难承认，但产品负责人应该花时间反思，查看创建的积压任务，并最终将其与产品路线图的愿景进行比较，看看两者之间是否仍然存在合理的联系，前提是实际上存在路线图。如果没有，那就是首先要解决的问题。有时，解决方案是承认产品负责人与团队和自己的目标都相距甚远。
在这种情况下，需要解决团队产品负责人的问题。如果没有任何其他方法，将一名可靠的业务分析师引入团队，更多地关注团队内容而不是业务内容（因为在这种情况下，我们已经有了产品负责人），可能是一个有效的选择，即使会增加团队的总成本。
没有固定时间表的测试流程
如果测试活动没有严格遵守 Scrum 冲刺中的具体时间表，会发生什么情况？
乍一看，这可能看起来像是我们想要的敏捷/Scrum 团队的好习惯。灵活性总是受欢迎的，并且在向外展示时听起来不错。
我的经验表明，这种自由带来的结果是混乱多于灵活性。这并不意味着解决这个问题的方法应该是在开发完成后立即进行专门的测试阶段，从而创建一个“冲刺内的瀑布”模式。在这种情况下，这绝不是正确的方法。您可以在我关于 Scrum 测试策略和敏捷测试生命周期的文章中阅读更多相关信息。
我们仍然可以允许一定的灵活性，并选择最适合当前开发团队和团队正在交付的特定产品特性的测试计划。但是，此选择应实现两个主要目标：
如果满足这些条件，团队自然会适应组装过程，交付时间表不会因计划外、时间过长的测试活动而受到影响。
最后，最重要的是可靠和可预测的冲刺发布，这引出了这篇博客的最后一点。
未定义的发布过程
现在，这对每个 Scrum 团队来说都是显而易见的事情。然而，奇怪的是，它通常也是最被低估的流程之一。
很多时候，Scrum 团队只是说发布将在每次冲刺之后进行，但没有可靠的流程支持。实际上，在发布期间会出现许多混乱、不可预测的活动。突然之间，所有人都忙于“发布任务”，没有人能够专注于继续开发新的冲刺故事。冲刺指标不明确，从第三方（通常是客户）的角度来看，发布看起来像是随机的、不可预测的活动。
人们如此专注于积压工作、冲刺内容、开发、测试和最终展示结果，以至于他们忘记了一旦完成所有这些，下一个冲刺已经在进行中，他们已经在浪费时间了。
寻找合适的发布时间
那么团队应该在什么时候真正发布到生产环境呢？这可能是最后也是最重要的一个问题。
这个问题的答案就在这个过程中，前提是你的团队有发布流程。根据：
- 团队在冲刺中产生的内容的复杂性，
- 冲刺的持续时间，
- 系统中受影响的组件数量，
- 使用和请求更改的人数，
应该建立并遵循一个重复的发布过程。流程的确切规则可以灵活定义。但就像测试活动一样，使其成为一种牢固的习惯，可以预测并安排在未来的具体日子里，从而使其成为可以依赖和参考的流程。
多种选择
这种流程的可能形式可以是以下任何一种或其他形式：
- 在下一个冲刺期间完成当前冲刺的功能测试，并在该冲刺结束时发布内容（一旦测试完成）。这意味着每个版本都不会包含上一个冲刺的任何内容，但会包含之前两个冲刺的故事。
- 发布前的最后一个冲刺始终致力于测试前两个冲刺的内容。
- 这并不意味着“测试冲刺”期间的开发将停止；只是说在该测试冲刺中开发的内容将不会包含在下一个版本中。
- 如果已经有足够多的自动化测试活动，争取在每个冲刺结束后进行发布。那么这必须是一个非常严格的流程，有专门的人员专注于在那几天 100% 的投入。它不会以任何方式影响开发团队的其他成员。
- 您还可以选择每月发布一次或每 N 个月发布一次，主要是在最终用户看来没有问题的情况下。这将增加每个冲刺测试方面的工作量（因为每个版本的内容会更大）。但另一方面，随着时间的推移，这将意味着更少的重复活动，这对团队来说是有好处的。因此，它可以使团队在发布之间构建更多新功能，尽管这些功能实际上会以较慢的速度投入生产。
但正如之前多次指出的那样，选择这些流程中的哪一个并不重要。更重要的是，团队将如何坚持这个流程，并将其养成难以改变的习惯。
您还可以阅读这份发布管理流程和实践指南。