敏捷架构的系统故事

Question

在尝试将敏捷原则应用于我们的开发过程，特别是scrum原则和类似XP的用户故事时，我们遇到了有关架构的问题。

也许我们仍然与以体系结构为中心的开发有太多联系，但是我们正在努力维护一个强大的基于组件的开发，并与敏捷建模原则相结合。我们的目标是预先设计一个小型设计，在开发过程中容易发生变化。

我正在寻找的东西可以让我放入我的建筑及其内部组件的积压故事：开发故事，而不仅仅是用法故事。 系统故事可能是一种不同类型的用户故事，它讲述了与业务价值并不严格相关的内容，而是与系统的架构和质量问题相关联。

修改 我找到了奥尔堡大学的this research关于“开发者故事”的信息。

您有经验，想法或反对意见吗？

提前谢谢！ （这是我的第一个问题！：D）

Answer 1

IMO积压应该不包含开发者故事。任何产品负责人都无法明智地将这些优先级与业务功能放在一起。如果产品负责人认为其中一个不重要并因此将其从积压中删除，会发生什么？如果团队然后坚持要保留这个故事，那么你就会面临积压的所有权变得不明确的情况。

但是，我确实认为团队需要在项目早期构建架构。我项目的一个问题是我们过多地关注前几个冲刺中的功能。

让我们考虑“建筑债务”（类似于技术债务）作为建设基础设施和架构所需的时间。与技术债务（从零开始并随着团队在没有适当重构的情况下产生功能而建立）不同，团队开始与建筑债务并且必须努力减少它。减少建筑债务所花费的时间意味着花费更少的时间来产生功能，即更低的团队速度和减少的冲刺输出。通过这种方式，建筑债务类似于技术债务。如果出现了不符合当前架构的要求，那么架构债务的水平就会增加。

请记住，团队应该决定（并且能够向产品负责人证明）他们将如何花时间。因此，他们可以在功能，技术债务和建筑债务之间分配他们认为合适的工作。

架构工作仍应由功能驱动。换句话说，团队应该构建基础架构以支持和启用特定的用户故事。不只是因为他们认为将来会有用。 The YAGNI principle适用于这种方法。

Answer 2

我的回答here适用。

在进行架构工作和更多功能特定的工作之间存在非常具有挑战性的平衡。从技术上讲，两者都是有效的方法和工作方式，但是延迟一些可用产品（冲刺结果）的时间越长，您所承担的风险就越大，因为您没有构建正确的产品（用户要求，性能要求等）。您可以尽早开始进行系统级测试，以证明您的产品有效，并且您可以向利益相关者展示产品的价值和方向。

Answer 3

就像放置一个一样简单确保可以从所有其他组件中删除所有其他组件'用户'故事中的会员组件，你的积压应该有系统/开发故事，只要它与产品所有者对此类实施的愿望同步。

这就是我们通常将非功能性需求放在积压中的方式，例如“域模型必须在负载平衡下在不同的数据中心上运行”等。

Answer 4

我认为对开发者故事有用的一个镜头是考虑任何特定故事的“用户”。仅仅因为您没有编写公司外部人员可以看到的功能并不意味着没有用户执行该工作。你可能正在为大厅里的团队编写代码。在某些情况下，用户就是你自己。这通常是开发者故事的情况。想想“作为一名开发人员，我拥有可扩展的架构，因此我可以轻松添加新功能。”通过呼叫特定用户，它可以让产品所有者了解谁将看到故事的价值。并指出“为什么”也有助于传达故事希望实现的好处。正如其他人所提到的，积压的管理确实归结为产品所有者和团队之间的协商。与往常一样，无论过程教条如何，您都需要找出最适合您团队的方法。每个团队都有不同的情况，对一个团队有效的想法并不总能转化为另一个团队。

Answer 5

在我们的团队中，我们将其称为“IT卡”，其形式为：“作为开发人员。我不会重构xyz组件。降低维护成本并增加灵活性。”

团队成员可以自由选择他们认为重要的任何IT卡，而不是从优先顺序的积压中弹出“功能卡”。

我发现这种方法可以很好地将技术债务保持在可接受的水平，并保持健康的创新步伐。

我发现它有点缺乏作为重新构建系统的方法。长期偏离特征产生流程是很难的。

当我写这篇文章时，我认为可以通过主题故事来接近建筑。通过史诗确定建筑目标，将其细分为一个主题，重点关注。