Scrum:放松“完成”还是使用尖峰？

Question

考虑一下在我们的组织中完成一个故事需要做些什么。

• 已满足演示要求
• UI设计已完成(布局、样式、字体、控件、颜色等)
• 最终完成用户文本并进行错误更正。
• 所有文本均翻译成西班牙文、日耳曼文、意大利文和法文。
• 用户手册更新
• PO认为需要修复的所有bug都已修复。
• FDA更新的文件(SRS、STD、STP、STM、UFMEA、DFMEA、SDD、安装)
• 要求由PO编写并批准。
• UI规范是由PO编写和批准的。
• 所有测试(最终验收和集成)的书面/更新和执行-同步并与测试经理同意。
• 所有脂肪试验均经QPE批准。
• 回归检验
• 对代码进行了审查和记录。
• 单元测试被编写并执行-同步并与软件经理达成一致。
• 重构，如果需要，已经完成-同步并与软件架构师达成一致。
• 设计已记录在案
• 安装程序被更新(如果需要)

由于需要做大量的工作才能完全完成一个故事，团队不再灵活，更难快速地尝试新特性。

据我所见，解决这个问题的方法有三种：

1. 做更多的“斯派克”故事，不符合“已完成”的定义，但作为快速原型收集反馈用户。
2. 在Sprint过程中，从用户那里获得反馈，而不是在结束时。因此，在故事进行到一半的时候，你已经可以了解用户对这个故事的看法了，并且在做所有繁重的事情(翻译、用户手册等等)之前，你可以很快地适应。
3. 放松“完成”定义，只需要基本测试和错误修复。这样的话，团队将不会在Sprint的末尾有一个潜在的可移植产品，但是它将很快地尝试新的特性和技术创新，而不会承受记录所有东西、编写用户手册、进行设计抛光等工作的负担。

你会选择哪种选择?为什么？

谢谢。

Answer 1

首先，我将尝试将一些项目从你的“已完成的定义”移到“就绪的定义”。ready的定义决定了故事何时处于足以由开发人员实现的状态。

我想转到“准备的定义”的项目是：

• 要求由PO编写并批准。
• UI规范是由PO编写和批准的。

这些项目通常涉及到PO、涉众和团队之间的一系列反复讨论，并给出了故事的形状。由于这个原因，应该在团队能够获得实现的故事之前完成它们。

在那之后，选项2对我来说似乎是最好的。敏捷(和scrum)背后的基本思想之一是，您应该与客户端和用户的代表密切协作，这样您就可以轻松地将团队的想法与客户的实际需求/需求相结合。scrum中的sprint结束时的演示是一个经常重复出现的里程碑，在这个里程碑上，团队可以向世界展示他们已经完成了什么，但是在sprint过程中您没有理由不能询问反馈。

如果经常讨论新功能应采取何种形式，那么您可以考虑引入一种特殊的“概念证明”类型的故事，该类型的故事定义宽松，可供PO使用，以了解该功能的工作原理。这些故事应该在一个单独的分支上实现，以确保它们不会被包含在最终的发行版中。要强调的是，这是一个产品负责人的决定，如果一个特定的故事是一个常规的故事或“概念的证明”故事。

Answer 2

我无法判断，但在我看来，你对“做”的定义是相当不现实的。当然，这取决于您的组织，但我首先要考虑的是，如果您需要，例如，本地化，在交付之前，毕竟，一次只使用一种语言。也许这真的是必要的！

因此--在我确定没有所有这些条件，并且假设列表仍然有效之后，我会采取以下两种方法中的一种：

1. 缩小每个故事的范围，使其适合迭代，并通过并行化使团队完成多个故事。换句话说，最大的运行时间必须是一个迭代，但是可以同时播放多个故事。
2. 删除一组仅适用于实际部署的约束(例如用户手册？)因此，团队可以更快，然后添加一个“发布”冲刺每隔一段时间，当你实际发布。不是很敏捷，但可能是你需要做的事情。

更一般的情况是:采用敏捷过程突出了组织工作方式中的一个风险因素。这是一个相当常见的现象，在我看来，这是敏捷方法的一个可取的特点。特别是，似乎有一个非常大量的仪式。首先，我要研究为什么不能首先大幅度地减少这种情况，而不仅仅是试图使这种方法适合您的情况。你有没有考虑过让团队帮助你(例如在回顾中)？

Answer 3

我注意到你的问题使用了" Scrum“标签，然而，你完成一个故事的任务列表让我相信你不能做Scrum。原因如下：

1. Scrum不需要演示。我们得到的最接近的是Sprint，它仍然与演示非常不同
2. Scrum没有强制要求或规范。我们得到的最接近的是Product项，与创建需求和规范相比，创建它们的开销要小得多
3. Scrum没有“测试经理”的角色。如果您使用的是外部元素，则可能破坏了Scrum的一个基本元素(即团队完全跨功能)。
4. “软件经理”的角色也是如此
5. 也是“软件架构师”

在我看来，您有一个基于Scrum的变体，而不是Scrum。我建议你的工作流程有一些过程中的沉重因素，这些因素正在拖垮你，因此你的不适也是可以理解的。

我的建议是回到Scrum的根源，找出你的功能障碍，然后努力解决它们。