垂直用户故事的缺点

在敏捷方法是组织工作纳入垂直用户故事，并提供有重点，但功能完备的片从应用的终端到终端。因为这是构建软件的新方法，所以我读了很多关于为什么它比水平故事更好的文献，但是我对这种方法的弊端知之甚少。

我已经喝了敏捷的冷却剂，我也同意垂直切片蛋糕比水平切片有很多优势。以下是我可以提出的一些缺点：

• 开发人员起初可能会较慢地实现功能，因为他/她必须了解开发故事所需的所有技术（UI +服务层+数据访问+网络等）。
• 总体架构设计（成为应用程序的骨干）并不能完全满足这一要求（但是有些人可能会认为开发/更改总体架构是用户故事的一部分）

垂直切片用户故事还有哪些缺点？

注意：我现在要问这个问题的原因是因为我将试图说服团队开始以“垂直方式”撰写故事，并且我希望能够提前提出可能的取舍，以便他们获胜。当他们面对弊端时，不要认为这种方法是失败的。

我不知道任何长期的缺点。短期而言，对于一个刚接触这种开发的团队来说，主要缺点是需要一定的习惯和学习。

垂直工作的最有效方法是拥有全职开发人员：这样，故事通常可以由一个人（或多个人）执行，而无需执行流水线任务。显然，这要求开发人员在整个堆栈中垂直工作（对于Web应用程序，从html到数据库）。

如果您的团队不习惯处理垂直故事，那么他们很有可能会做相反的事情：每个人只会了解应用程序的一层/一层。当您介绍垂直故事时，您可以期望团队将其分为与图层相对应的任务，然后将任务分配给不同的人。这将是非常低效的。

为此，我可以提供的最佳方法是首先容忍这种流水线操作，同时明确表明长期目标是完全不同的。让团队成员跨层配对计划，以便建立信任并最终使人们完全独立。

我不同意这种方法带来技术债务的其他答案。可以，但是其他任何方法也可以。

我一直在思考这个确切的问题。

我认为区分按个人职责划分和按团队职责划分是很重要的。我将把这个答案主要集中在切片团队上。

对于某些背景：我曾在项目中与全栈开发人员，单层开发人员，垂直（全栈）团队，水平（单层）团队和对角团队合作。对角线团队，我的意思是包含一个故事所需的所有层，但不一定包含系统中的所有层，还可能包含多个专注于同一层的开发人员。换句话说，实际上是垂直的，但外观或实现细节可能有点水平。

最近，我在一个从水平团队过渡到对角线（几乎垂直）团队的团队工作。看到同一群人以两种不同的方式对齐，这特别具有指导意义。这使得一些优点和缺点非常明显。

到目前为止，我将通过以下摘要比较来总结我的观点：

横向团队

优点：

• 促进良好的关注点分离和松散耦合的层级
• 轻松得多的工作负载分配管理
• 易于专业技术负责人进行管理
• 促进内部协作，最佳实践，自豪感和卓越文化
• 符合自然/紧急的沟通模式

缺点：

• 可能导致层间隔离，从而阻碍层间通信
• 如果不缓解，则启用“泡沫”文化
• 难以利用通才领导
• 后援通才

垂直/对角线团队

优点：

• 一个团队中用户故事的所有部分（“一站式服务”）
• 特别有助于在一次冲刺中传递n层故事（尽管您确实需要吗？）
• 促进层级协作和通才技能的培养
• 支持通才

缺点：

• 工作量分配管理更加困难
• 实现关注点和紧密耦合的层之间的不良分离
• 通过减少层内通信来阻碍专业化；在不增加缓解横向/专业行为的情况下，很难看出卓越文化是如何从这种结构中产生的

我认为团队成员没有一种千篇一律的解决方案。但是，对于需要通用化的组织来说，垂直团队的排列似乎更好一些。如果您的工程师是通才，并且喜欢全职工作，那是考虑垂直团队的一个很好的理由。对于需要专家的组织，水平团队会更好地排队。如果您的工程师是专家，那是考虑横向团队的充分理由。

正如其他人提到的那样，将另一个方向分割的辅助结构/行为可以帮助减轻两个系统的缺点。一个有趣的缓解因素是冲刺持续时间。短距离的冲刺使横向团队的一些弊端更容忍。如果您可以在本周构建后端，在下周构建前端，那可能足够快？

要将其中一些拟议的原则应用于现实世界中的问题……我想说的是，水平切片对于一个我从事过的非常实际的SaaS开发团队来说非常有效，该团队正在解决各个层级中非常棘手的技术问题（我认为专业化非常重要），交付频率（以及高粒度/频率的可靠性）对业务成功至关重要。请注意，这个结论是针对一个非常特殊的现实世界团队的，而不是对水平切片优势的一般说明。

一个警告：我可能不相信现代软件开发世界中任何人都声称拥有通才能力而没有大量证据，尽管我知道一些罕见的杰出通才。我觉得普遍性确实是一个很高的（垂直的）顺序，尤其是随着每一层的复杂性不断提高以及替代语言/平台/框架/部署的增加，每种语言都能满足不同的需求。尤其是如今，各行各业的人很容易成为无所不能的大师。此外，我发现大多数人都想专门研究很多，除了一些例外。

我发现的最大缺点是，这使得团队很难采用统一的架构方法来构建应用程序。

在项目的早期阶段，每个人都将单独编写各层。故事（和涉及的层）将起作用，但是当在sprint端回顾交付的产品时，很容易看到每个开发人员的体系结构思想之间的细微差异。

这种事情是不可避免的，但不是阻碍。我试图通过两种方式与之抗争：

1. 实施每个故事之前，与团队进行长时间的设计讨论
   • 这很快就累了。对任何人来说，做出明智的决定通常为时过早，然后您最终不得不争论肯定必须进行更改的内容。
2. 继续进行相对隔离的开发，并记住您正在累积技术债务。
   • 这里的关键是将技术（建筑）债务记录为问题。这是需要偿还的东西。
   • 经过几次冲刺之后，决定一致且统一的体系结构将变得更加容易。在这种情况下，您应该请求强化冲刺来偿还一些技术债务（重构现有代码）。另外，您可以在项目的下一个迭代中分期偿还。

除此以外，我唯一想到的另一个问题是，在项目开始时通常要添加很多样板代码。编写垂直片段故事意味着由于此先决条件而导致团队在前几个故事中的速度会人为地降低...但是只要所有人都知道这只会影响前几个冲刺，那么一切就很好了。

我也不知道有什么缺点，但是垂直的故事可能执行得不好。

当我刚开始我的职业生涯时，我加入了一个热衷于XP的团队，但是他们没有XP的经验。使用垂直用户故事时，我们犯了许多错误。

我们在进行水平工作时遇到的问题之一是要素在各个图层之间的集成度不高。API通常不符合规范，缺少功能和许多其他问题。通常，由于的开发人员已转移到其他项目，您要么必须等待它们，要么自己动手做。

改用“垂直故事”解决了这些问题，并减少/消除了重新集成工作的浪费。

有许多XP实践支持这种工作方式。任何人都需要能够在任何地方工作，并且每个人都应修复他们发现的错误（集体代码所有权）。

当您更改垂直故事时，在您不熟悉的领域工作可能会很棘手。如果您不确定在团队中与某人配对，可以使用配对编程来提供帮助。我发现结对编程是最快掌握新代码库的方法。

我们发现，如果没有层层强大的所有者，就会出现一些重复。尽管这不是一个大问题，但是我们需要确保我们熟练地进行了重构（有适当的测试来支持）。

尽管我提到了许多问题，但我认为不是垂直用户故事是造成此问题的原因。实际上，这使问题更加明显。进行切换后，各个团队或应用程序层之间的问题不再被混淆。