4个破坏你的冲刺的不健康过程

在我之前的文章中，我开始讨论在一个Scrum团队内部的某个环节会导致交付失败的问题。在这篇文章中，我想再扩展一下这个话题，现在重点关注团队内的功能性流程。

这些流程和团队的技术卓越一样重要。即使团队内的人员对即将交付的工作非常熟练，仍然有一些因素可能会破坏他们的完美努力。这不完全是他们的错，更多的是项目管理决策的直接责任，以及他们提供适合团队的流程来支持团队的明确意图和可预测的活动的能力。

技能集严重分离的团队

想象一下，团队有着技能娴熟的开发人员，他们完全独立，并有能力履行承诺，在迭代结束之前按时交付协商好的内容。即使在这种完美的场景下（实际上很难实现），如果团队成员之间的技能严格分离，团队在跟进（不断增长的）需求背景下会遇到问题。

几个例子

团队有1或2个DevOps工程师，他们可以对自动化流程进行任何更改，或者负责平台内的服务，但其他团队成员对此一无所知。在像需求评审这样的会议上讨论这些需求将导致大部分团队浪费时间，因为他们在会议上没有参与，反之亦然-DevOps开发人员对于其他功能相关的需求没有兴趣，会议上的时间也会大部分浪费。
整个团队只有一个数据库专家。根据系统中数据解决方案的复杂性和使用情况，这个人可能会不断被任务超载，尤其是考虑到他们的优先级。更糟糕的是，其他需求也必须等待，因为它们依赖数据库故事提供的数据源。
当一个产品主要面向后端开发时，只有一个前端开发人员只是备用（因为偶尔需要对UI应用进行一些小的更改）。在这种情况下，大部分Scrum仪式对于这个团队成员来说都是浪费时间，因为他们的知识仅限于前端，其他方面无关紧要。

问题解决

在上述任何情况下，结果要么是人们浪费时间，要么是他们无法跟上需求背景。他们阻碍了团队其他成员开始下一个任务的工作，或者有效降低了Scrum团队的整体效率，因为迭代期间有太多未被利用的时间。

然而，团队仍然有相同数量的开发人员。从外部来看（甚至不想暴露），团队内部的人员无法承担某些任务，因为他们过于侧重于某些特定的技能。因此，即使他们的工作量允许，故事的优先级也有利于这样做，他们也无法帮助其他团队成员完成任务。

对于产品负责人来说，为团队组织一些有意义的迭代内容甚至也很困难，因为产品负责人必须始终考虑到每个故事有多少人可以工作，如果同时将更多类似的故事带入迭代，团队的资源将被耗尽，即使实际上也有人可能可以处理这些故事，但他们没有开始处理这些故事的技能。

解决困境

这是一个需要解决的困境，项目经理应该意识到选择的路线。具体来说，需要在以下选择之间进行抉择：

拥有许多全栈开发人员，他们能够处理更广泛的内容，但在许多主题上并不是真正的专家。所以他们可以广泛而不是深入。这样交付速度可以快，但质量可能会受到影响。
为每个技术领域都有专门的专家，但同时接受限制，并更加努力地提供更适合的打印内容。这样人们可以深入并构建精彩的故事，但这些故事需要按顺序处理，因此交付时间会较长。

薄弱的产品负责人

这个问题并不一定是“流程问题”，但我把它当作流程问题来处理，因为创建扎实的故事可以被理解为一个团队应该具备的流程，与开发团队兼容。

我所说的“薄弱”并不需要指的是一个人的知识属性，而是指产品负责人在服务于团队故事方面的能力，这让开发人员能够理解，并从产品路线图的角度清晰地理解。这两点对于一个成功的Scrum团队都非常重要。

如果故事缺乏细节，使得开发人员无法明确理解目的、功能价值或技术期望，那么基本上会发生两种情况：

开发人员会构建与产品负责人实际想要的不同的东西。这在Sprint本身中很难发现，因为大多数情况下，产品负责人无法以如此详细的水平追踪故事的进展，而且产品负责人通常只会期望事情会发生（像魔术一样）。
开发人员将会花费太多的时间澄清故事，并反复讨论，而不是开始构建它们。这涉及到许多额外的电话、重复的协议，并将工作推迟到迟期的Sprint阶段。到了一定程度，原来的故事估计不能再被认为是准确的，而且故事不可能在Sprint内关闭，并将滚入下一个Sprint。在最坏的情况下，情况会在后续的Sprint中重复发生。

自我反思的时刻

通常很难承认，但产品负责人应该找时间进行反思，查看创建的待办故事，并与产品路线图进行比较，看看这两者之间是否仍然存在合理的联系 – 如果有的话。如果没有，那是首要解决的问题。有时，解决方案是承认产品负责人与团队相距太远，离自己的目标太远。

在这种情况下，应该解决团队中的产品负责人部分。如果没有其他办法，为团队引入一个更加注重团队内容而不是业务内容的坚实业务分析师可能是一个可行的选择，即使需要增加团队总成本。

没有固定时间表的测试流程

如果测试活动与Scrum Sprint中的具体时间表无关，会发生什么情况？

乍一看，这可能看起来是敏捷/Scrum团队所期望的好事。灵活性总是受欢迎的，并在外部介绍时听起来不错。

我的经验表明，这种自由带来的结果更多的是混乱而不是灵活性。这并不意味着解决这个问题的方法应该是在开发完成后紧接着创建“Sprint内的瀑布”，并紧随其后进行专门的测试阶段。在这种情况下，你可以在我的帖子中阅读更多关于此的内容：scrum testing strategy和agile testing life cycle。

我们仍然可以允许一些灵活性，并根据当前的开发团队和给定的产品属性选择测试时间表。然而，这个选择应该实现两个主要目标：

在测试活动期间尽量减少对开发进程的干扰。
使之成为团队内部一个坚实（从内容角度）、可靠（从发生角度）、可预测（从可预测性角度）的活动。

如果满足了这些条件，团队将自然而然地适应适应进程，并且交付时间表不会受到未计划的延长测试活动的影响。

最重要的是可靠和可预测的迭代发布，这使我想到了本文的最后一点。

未定义的发布流程

现在，对于每个Scrum团队来说，这是一个如此明显的事情。然而，奇怪的是，它通常也是最被低估的流程之一。

很多时候，一个Scrum团队只会说每个迭代后都会发布，但这并没有一个坚实的流程支持。然后，实际上，许多混乱、不可预测的活动将在发布时间出现。突然间，所有人都忙于“发布任务”，没有人能够继续开发新的迭代故事。迭代指标出现偏差，从第三人（通常是客户）的角度来看，发布看起来像是随机、不可预测的活动。

人们如此专注于积压、迭代内容、开发、测试和最终展示结果，以至于他们忘记了一旦完成了所有这些工作，下一个迭代已经开始，并且他们已经失去了时间。

寻找一个合适的发布时间点

那么团队应该在什么时候实际发布到生产环境？这是最后最重要的事情。

答案在于流程，假设你有一个流程。根据：

团队在迭代中产生的内容的复杂程度，
迭代的持续时间，
受系统影响的组件数量，
使用和请求更改的人数，

应建立并遵循一个重复的发布流程。流程的具体规则可以再次定义时具有灵活性。但与测试活动一样，将其作为一个坚如磐石的习惯，可以预测并计划未来具体日期的活动，使其成为可靠的依据和参考。

选择发布的方式

这样一个流程的可能形式可以是以下任何一种或其他形式：

在下一个迭代期间完成对当前迭代功能的测试，并在该迭代结束时发布内容（一旦测试完成）。这意味着每个发布将不包含来自最后一个迭代的任何内容，但它将包含来自前两个迭代的故事。
- 在发布之前的最后一个迭代始终用于测试之前两个迭代的内容。
- 这并不意味着“测试迭代”期间的开发将停止；它只是说在该测试迭代中开发的内容不会立即包含在下一个发布中。
如果已经有足够的自动化测试活动，努力在每个迭代结束后进行发布。然后，这必须是一个非常严格的流程，专门有人全身心投入几天时间来处理。它在任何方式上仍不能影响开发团队的其他工作。
您还可以选择每月发布一次或每N个月发布一次，主要是从最终用户的角度来看是否合适。这将增加每个迭代测试方面的工作量（因为每个发布的内容将更多）。但另一方面，这将意味着随着时间的推移，重复活动的数量将减少，这在这种情况下对团队有益处。因此，这将使团队能够在各个发布之间构建更多的新功能，尽管这些功能实际上会以较慢的速度进入生产环境。

但正如之前已经多次提到的，选择这些流程并不是很重要。更重要的是团队能够如何坚持执行这个流程，并使其成为一种持久的习惯。

您也可以阅读这个指南：release management process and practices。