敏捷SCRUM:水平与垂直拆分

Question

我们有一个项目，将持续大约5冲刺。

该项目涉及许多用户故事，每个故事都涉及不同开发人员的工作: Web (AngularJS & CRM )和ASP.NET (动态)。因此，它是“垂直分割”的。

每个用户故事都建立在最后一个用户故事的基础上:更多的字段被添加到UI中，更多的字段必须由CRM工作流选择。因此，测试每个用户情景需要多次重新访问用户界面和后端，并测试刚刚添加的新字段。

不同寻常的是，我们被要求用两种不同类型的任务来处理sprint :用户故事被放在一个post it note中，故事被进一步分解为每个开发人员所需的活动(UI / CRM)。结果，我们实际上得到了两个烧毁:考虑到我们没有提供单个任务的估计，这是我不能理解的。

我理解垂直拆分用户故事意味着你总是会交付一些有用的东西，但我不禁认为这并不总是交付项目的最有效方式，特别是当你一次又一次地重复访问应用程序的相同部分时。

在scrum agile中，水平拆分是可以接受的吗?在我们的案例中，它允许CRM开发人员在单独的用户故事中实现他们的工作？毕竟，如果是在sprint的早期阶段，在开发人员各自的层中不实现功能的风险是相当小的。此外，没有必要将用户故事分解为更多的“任务”。

在这种情况下，通过将任务分解为水平(架构)任务，我们可以在几天内更改UI，然后让CRM开发人员收集我们在单独故事中发送的数据。我认为这也会使测试变得更容易，因为你是在各自的环境中测试每个完整的“功能”，而不是在几个用户情景中构建它……

显然，如果你是一个全栈开发人员，实现垂直拆分要容易得多。但是这个项目不是这样的.

在您的应用程序不断增加字段/ UI数量的情况下，建议的方法是什么？在敏捷中，是否允许任务的水平拆分，或者总是禁忌？

Answer 1

我不确定，即使你水平地拆分任务，你也能达到你想要的效果。让我们举一个极端的例子，UI开发人员完成了100%的任务，而CRM开发人员没有完成任何任务。

是否会发布任何功能(或实现任何用户故事)？我想不是。

因此，我建议将UI和CRM开发人员作为一个单位(具有共同的工作压力)，并在他们内部拆分任务。

优选地，他们将以相似的节奏工作，这样他们就可以相互提供要完成的任务。此外，这种合作可能是一件好事，因为UI和CRM开发人员都会对项目有更多的承诺，因为他们有一个共同的目标，并作为一个共同的单位来衡量。

希望它听起来是合理的，并帮助你做出决定。

Answer 2

这就是集群概念的用武之地。假设您的scrum团队由具有涵盖用户故事的所有方面(例如UI、CRM、DB等)的技术能力的成员组成，那么您的scrum团队可以将第一个用户故事聚集在一起，同时完成所有方面。假设您的团队中嵌入了一名测试人员，他们也可以同时为其编写测试用例。在一两天内，这个故事就完成了，你就有了功能齐全的东西，并且可以向你的产品所有者/利益相关者证明。然后团队蜂拥而至下一个用户故事。一个团队需要时间来掌握节奏才能有效地做到这一点，根据我的经验，对于一个没有以这种方式工作的团队来说，大约需要6-12个月的时间。

此外，通过预先完成整个垂直路径，您可以及早了解所需的内容，并且可以在有大量代码需要重构之前快速进行更改。如果你先做整个层，然后再做下一层，除了还不能测试第一层之外，在实现下一层时，你最终会发现一些东西，这将导致你不得不返回并重新做第一层。这会导致额外的工作或创建不可维护的代码，因为为了满足最后期限，事情会被黑客入侵。