制作用户故事和操作职责

Question

我正在寻找一些关于如何在一个团队中与DevOps/SCRUM的波涛汹涌的水域导航的建议。

背景:一个团队运作良好，拥有3种产品和2名工程师、1名产品负责人、1名经理(没有scrum大师、团队领导或技术领导)，他们的交付冲刺时间为1周。这个团队遵循“你构建它，你拥有它”，并通过分配给故事的任务来跟踪团队工作时间。

场景:对于1 sprint，一名工程师发现自己正在处理事件(由于上游系统和应用程序本身的混合而影响到应用程序的可用性)。团队决定补救措施不是客户要求的，而是操作工作。

这是我想要解决的现实世界的问题。显然，这种情况可以很好地映射到敏捷原则，但是为了产品映射和跟踪目的，这个部门主要遵循DevOps/SCRUM。

你认为工程师跟踪他们的工作最好的方法是什么？

Answer 1

如果您经常遇到突发事件和其他需要优先处理的弹出工作，Scrum可能不是一个合适的选择。Scrum的核心是Sprint。如果您不能一贯地举行计划会议来选择支持Sprint目标的目标和工作，执行工作，与涉众同步，然后改进Sprint的工作方式，那么您将与Sprint进行斗争。

您的其他上下文也不太适合Scrum。

Scrum是围绕一个支持单个产品的团队构建的，而您的团队支持3。如果您要“执行Scrum"，您将有三个产品负责人和三个产品积压。即使您有较少的产品负责人，您仍然应该有三个产品的积压。然而，除非每个Sprint都能专注于一个单一的产品，否则团队将很难将精力集中在Sprint的一致目标上。如果产品全部投入使用，并需要不断监测和对事故提供潜在支持，情况尤其如此。

对于正式的方法来说，团队规模也是很小的。除非经理也在积极开发该产品，否则您只有两个开发人员。Scrum框架旨在协调团队之间的工作，因此Scrum框架中描述的一些活动可能会过多，甚至会增加额外的开销，而不是让团队的生活变得更容易。

最好的做法是将目光投向Scrum之外，因为那里的实践不适合您当前的环境。但是，如果您被困在Scrum中，您仍然可以选择。

在Sprint中完成的所有工作都必须是可见的。如果有事故，他们需要在你的斯普林特积压，在你的斯普林特董事会，每个人都需要知道，这些事件发生了。当您到达Sprint和Sprint回顾展时，团队需要传达这些事件的影响。在Sprint上，应该能够解释出现的问题以及这些问题如何影响到团队实现Sprint目标的能力。

展望未来，斯普林特计划会议应包括考虑能力时发生的事件。如果您的组织支持DevOps，您应该对可以提供事故信息的应用程序进行广泛的监视。使用过去的表现来解决一个事件需要多长时间，团队需要留出时间，而不是计划他们的Sprint到容量。Sprint的目标一般应该是可实现的，考虑到“正常”数量的事件和时间，以解决这些事件跨支持的系统。

在组织一级，需要大力解决事件的根源问题。通过减少事故数量或开发更快地将系统恢复到正常运行状态的方法，团队的开发能力将提高。