我们有一个项目将持续大约5个sprint。
该项目涉及许多用户故事，每个故事都涉及不同开发人员的工作：Web(AngularJS&ASP.NETMVC)和CRM(Dynamics)。因此，它是"垂直拆分"。
每个用户故事都建立在最后一个之上：更多的字段被添加到UI中，更多的字段必须由CRM工作流提取。因此，测试每个用户故事需要多次重新访问用户界面和后端，并测试刚刚添加的新字段。
不同寻常的是，我们被要求用两种不同类型的任务来处理sprint：用户故事被放在一个便利贴上，故事被进一步分解为每个开发人员所需的活动(UI/CRM)。因此，我们实际上以两次消耗告终：考虑到我们没有提供单个任务的估计，这是我不理解的。
我知道垂直划分用户故事意味着你总是会提供有用的东西，但我忍不住认为这并不总是交付项目的最有效方式，尤其是当你考虑到你正在一次又一次地重新访问应用程序的相同部分时。
在scrum敏捷中，是否存在可以接受水平拆分的场景，比如在我们的案例中，它将允许CRM开发人员在单独的用户故事中实现他们的工作？毕竟，如果是在sprint的早期，那么在开发人员各自的层中不实现某个功能的风险非常小。此外，不需要将用户故事分解为更多的"任务"。
在这种情况下，通过将任务分解为水平(架构)任务，我们可以在几天内更改UI，然后让CRM开发人员获取我们在单独的故事中发送的数据。我认为这也会让测试变得容易得多，因为你在各自的环境中测试每个完整的"功能"，而不是在几个用户故事中构建它。。。。
显然，如果你是一个全栈开发人员，那么实现垂直拆分要容易得多，。但这个项目并非如此。。。。
如果您有一个不断增加字段/UI数量的应用程序，建议采用什么方法？敏捷中是否允许横向拆分任务，还是总是不允许？
我不确定即使横向拆分任务也能达到你想要的效果。让我们举一个极端的例子，UI开发人员完成了100%的任务，而CRM开发人员没有完成任何任务。
是否会发布任何功能(或完成任何用户故事)？我想不会。
因此，我建议将UI和CRM开发人员作为一个单元来处理(具有常见的烧录)，并在它们之间内部分配任务
他们最好以相似的节奏工作，这样他们就可以为彼此提供要完成的任务。此外，这种合作可能是一件好事，因为UI和CRM开发人员都会对项目有更多的承诺，因为他们有一个共同的目标，并作为一个共同单元来衡量。
希望这听起来合理，能帮助你做出决定。
这就是集群概念的由来。假设你的scrum团队由具有技术能力的成员组成，这些成员涵盖了用户故事的各个方面(例如UI、CRM、DB等)，那么你的scram团队可以集群第一个用户故事，共同完成所有方面。假设您的团队中嵌入了一个测试人员，他们也可以同时为其编写测试用例。一两天内，这个故事就完成了，你就有了一些功能齐全的东西，可以向你的产品所有者/利益相关者展示。然后团队蜂拥进入下一个用户故事。一个团队需要时间才能进入节奏才能有效地做到这一点，根据我的经验，对于一个以前没有这种工作经验的团队来说，大约需要6-12个月的时间
此外，通过提前完成整个垂直路径，您可以尽早了解需要什么，并可以在有大量代码需要重构之前快速做出更改。如果你先做一整层，然后再做下一层，除了还不能测试第一层之外，你最终会在实现下一层时发现一些事情，这将导致你不得不回去重做第一层。这会导致额外的工作或创建不可维护的代码，因为事情会在截止日期前被黑客入侵。