如何分解scrum中的sprint？

Question

我在挣扎如何分解SCRUM中的sprint。我知道在许多情况下，SCRUM只用于软件过程中的开发部分，但我想将它用于整个项目(在我们的例子中:预研分析、从供应商那里购买和开发)。

如果我根据时间限制分解一个sprint (例如，每个时间2-3周)，那么sprint将包含我所看到的不相关的特性。例如，同一sprint包含“X的预研”、“Y的购买”、“Z的开发”等。这个例子的问题是很难找到一个共同的冲刺目标。

如果我根据特性分解一个sprint，例如，一个sprint表示“”，另一个sprint表示“”，那么对于每个sprint，很容易有一个清晰的sprint目标。另一方面，这导致一些架构师不得不并行处理几个sprint。这是因为每一项预先研究都要求我们有外部顾问参与。我们的建筑师或多或少会将这项工作交给顾问进行特定的预科研究，其余的则由顾问来完成。因此，架构师将有时间并行地管理几个预研究。这种情况的问题是，SCRUM中有一条经验法则，一个人不能同时使用几个sprint。

这里需要一些指导，如何在sprint中添加特性。如果你根据时间分解，你如何创建一个清晰的冲刺目标？如果您对特性进行分解，那么您的团队是否与几个sprint并行工作？

Answer 1

Sprint只是一个发布周期。这是一个短期计划(尽管Scrum指南不再使用这个词，我更喜欢它:承诺)来向客户和用户交付一套明确的增值产品。史诗和故事代表了系统的特性/功能和质量属性。

我开始使用尖峰的思想来处理调查任务，目的是在交付增值功能之前做出决策或学习一些信息。尖峰是以小时或天为单位的。一些团队试图让他们适应冲刺，而另一些团队则让他们生活在Sprint之外，而不是与Sprints和end日期相一致。无论您做什么，都要意识到，如果一个Spike正在进行，那么您的团队交付功能的能力将会降低。您也可以选择将Spikes放入Product和/或Sprint中，并对它们进行优先排序，并根据它们的完成情况编写史诗和故事。

至于你的Sprint目标，我并不完全相信它是有用的。正如您所看到的，您的Sprint可能是一些交付功能的组合(创建软件、支持硬件等等)。以完成史诗和故事以及学习新事物(建筑权衡、法规、语言或框架等)的形式出现。以完成刺的形式。基于优先级，您的Sprint待办事项可能贯穿软件系统的许多方面，因此很难编写一个简明的目标。在我看来，所有Sprints都有一个目标:通过满足您对每个已完成故事的完成的定义，为客户和用户提供价值。这一价值可能体现在功能上，也可能在于增加团队的知识，以做出更好的未来决策。

Answer 2

基于你所说的，我只是认为Scrum不适合你。你试图把冲刺当作任务来处理，但它们并不是为之而设计的--它们是用来确保人们定期展示进步的时间箱。不幸的是，当进度不能用比scrum更长的时间来衡量时，或者当一项任务需要比sprint更长的时间(这将发生在外部顾问身上)时，它们就特别糟糕了。

对您来说，更好的方法是修改看板--其中的任务无论如何都是并行运行的。如果你认为一个任务可以被“停放”，当你被派到一个顾问那里，允许超过规定数量的在建任务(即一个停放的任务不算作正在进行中)，那么我认为你会有一个更容易管理的(而且显然是可以理解的)过程。

还有很多其他敏捷过程，我会认真考虑其中的任何一个，而不是Scrum。我建议你至少调查一下替代方案。

Answer 3

谢谢你的好想法，我一直在考虑它们。我看到的是最好的选择就是坚持使用SCRUM，即使它在与顾问一起工作时并不是最优的。

@Thomas我作为scrum大师的经验告诉我，当sprint包含各种与彼此没有真正关系的特性时，很难有良好的事后回溯会议。他们往往含糊不清是我的经验。