在尝试将敏捷原则应用到我们的开发过程中，特别是 Scrum 原则和类似 XP 的用户故事时，我们遇到了架构方面的问题。
也许我们仍然过多地与以架构为中心的开发联系在一起，但是我们正试图保持一个强大的基于组件的开发，并与敏捷建模原则相结合。我们的目标是预先进行小型设计，在开发过程中易于演变。
我正在寻找的东西可以让我将关于我的架构和其中的组件的积压故事放入我的积压故事中：开发故事，而不仅仅是使用故事。系统故事可能是一种不同类型的用户故事，它讲述的内容与业务价值并不严格相关，而是与系统的架构和质量问题相关联。
编辑： 我发现了奥尔堡大学关于“开发者故事”的这项研究。
你有什么经验、想法或反对意见吗？
先感谢您！（这是我的第一个问题！：D）
IMO 的积压工作不应包括开发人员的故事。任何产品负责人都无法明智地将这些与业务功能一起优先考虑。如果产品负责人认为其中一个不重要并因此将其从积压中拉出来怎么办？如果团队随后坚持保留故事，那么您将处于待办事项的所有权变得不清楚的情况。
但是，我确实认为团队需要在项目早期构建架构。我的项目的一个问题是我们在前几个 sprint 中过于关注功能。
让我们将“架构债务”（类似于技术债务）视为需要花费在构建基础设施和架构上的时间。与技术债务（从零开始并随着团队在没有适当重构的情况下产生功能而逐渐增加）不同，团队从架构债务开始并且必须努力减少它。减少架构债务所花费的时间意味着生产功能所花费的时间更少，即更低的团队速度和减少的 sprint 输出。这样，架构债务类似于技术债务。如果出现不符合当前架构的需求，那么架构债务水平就会增加。
请记住，团队应该决定（并能够向产品负责人证明）他们将如何度过他们的时间。因此，他们可以根据需要在功能、技术债务和架构债务之间分配精力。
不过，架构工作仍应由功能驱动。换句话说，团队应该构建基础设施来支持和启用特定的用户故事。不仅仅是因为他们认为它在未来会有用。YAGNI 原则适用于这种方法。
我的回答在这里适用。
在进行架构工作和更多特定于功能的工作之间存在非常具有挑战性的平衡。从技术上讲，两者都是有效的方法和工作，但是您延迟一些可用产品（冲刺结果）的时间越长，您承担的风险就越大，您没有构建正确的产品（用户要求、性能要求等）。尽可能早地进行系统级测试以证明您的产品有效，并且您可以向利益相关者展示产品的价值和方向。
就像放置一个确保成员资格组件可以从所有其他组件“用户”故事中拔出的测试一样简单，您的待办事项应该有系统/开发故事，只要它与产品所有者的愿望同步这样的实施。
这就是我们通常将非功能性需求放在待办事项中的方式，例如“域模型必须在负载平衡下在不同的数据中心上运行”等。
在我们的团队中，我们将其称为“IT 卡片”，其形式为：“作为开发人员。我不想重构 xyz 组件。以降低维护成本并增加灵活性。”
团队成员可以自由选择他们认为重要的任何 IT 卡，而不是从优先级积压中弹出“功能卡”。
我发现这种方法相当有效，可以将技术债务保持在可接受的水平，并允许健康的创新步伐。
不过，我发现它作为一种重新构建系统的方法有些欠缺。很难证明长期偏离功能生产流程是合理的。
当我写这篇文章时，我在想一个人可以通过主题化故事来接近建筑。用您分解为要关注的主题的史诗来确定架构目标。
我发现对开发者故事有用的一个镜头是考虑任何给定故事的“用户”是谁。仅仅因为您编写的功能不会被公司以外的人看到并不意味着该工作没有用户。你可能正在为大厅里的一个团队编写代码。在某些情况下，用户就是你自己。这通常是开发人员故事的情况。想想“作为一名开发人员，我拥有一个可扩展的架构，因此我可以轻松地添加新功能。” 通过呼唤特定的用户，它可以让产品所有者了解谁会看到故事的价值。指出“为什么”也有助于传达故事希望达到的好处。正如其他人所提到的，积压的管理确实归结为产品所有者和团队之间的谈判。与往常一样，无论流程教条如何，您都需要找出最适合您的团队的方法。每个团队都有不同的情况，适合一个团队的想法并不总是能转化为另一个团队。