作为“非功能性”用户故事的架构原则[关闭]答案

【问题标题】：Architectural principles as "non-functional" user stories [closed]作为“非功能性”用户故事的架构原则[关闭]
【发布时间】：2010-09-15 11:22:45
【问题描述】：

我即将在我们公司启动一个试点项目，以引入敏捷实践，包括使用用户故事。在阅读了 Mike Cohn 的两本书之后，特别是敏捷估计和规划以及应用用户故事，我现在对如何进行有了更清晰的了解。我有信心在实践中完善我们的技术。

但是有一件事不能说服我。 In this blog post Mike Cohn 定义了一种特定类型的用户故事，他称之为约束，可以用来定义所谓的非功能性需求。我个人不喜欢约束这个词，甚至不喜欢使用经典模板“作为...，我想要...，所以...”。

相反，我会尝试让客户始终在卡片上书写，也许使用上面的模板，Nick Rozanski 和 Eoin Woods 在他们出色的书 Software Systems Architecture 中称为的那些，架构原则 ：

“架构原则是指导架构定义的信念、方法或意图的陈述。”

（他们还将这些原则分为业务原则和技术原则，我认为我们不应该关心这种区别。）

我想对这些原则卡片做的是将它们放在我们的待办事项卡片板旁边，以便在用户故事定义和计划活动期间始终存在它们。我还鼓励客户和开发人员在每次他们认为卡片可以作为团队提醒有用时将它们捡起来放在迭代板旁边。

你有没有尝试过类似的方法？你有什么理由不鼓励它吗？您对这个问题有什么建议吗？

【问题讨论】：

标签： agile requirements user-stories

【解决方案1】：

你有没有尝试过类似的方法？我没有尝试过完全相同的东西，但是当我是我团队的 Scrum Master 时，我们确实有一个项目范围的架构指南和愿景（所有团队都是其中的一部分），我们在各种检查和调整点中提醒自己Sprint 和 Scrum 项目，例如在回顾、Sprint 计划会议甚至每日 Scrum 会议期间。我们曾经提醒我们的一些方法是为任务添加完成标准，其中包括遵循架构准则的一项原则，也可以在待办事项列表中作为小注释添加。在我下面的建议中，我提到了如何从一个非常高的层次来看待这一点。

您是否出于任何原因不鼓励它？一点都不。我说你的建议很好，你应该在计划会议上尝试一下。正如 Ken Schwaber 和 Jeff Sutherland 在他们的 Scrum 指南中所建议的那样，你应该在 Sprint 的 3 个点中检查和适应——“Scrum 中有三个点需要检查和适应。每日 Scrum 会议用于检查朝着Sprint 目标，并进行调整以优化下一个工作日的价值。此外，Sprint 审查和计划会议用于检查发布目标的进度，并进行调整以优化下一个 Sprint 的价值。最后， Sprint Retrospective 用于回顾过去的 Sprint，并确定哪些调整将使下一个 Sprint 更加高效、充实和愉快。”

您对这个问题有什么建议吗？我可以假设贵公司的这个“敏捷”项目才刚刚开始，而你还没有确定项目的可靠愿景吗？如果是，我建议您安排一个为期 2 周的项目范围的发布计划研讨会。本次研讨会的目的是将所有利益相关者、PO、SM 和项目经理聚集在一个地方，并制定一个超级用户故事和愿景，以及从超级用户故事分解的其余待办事项。超级用户故事将是项目目标的高层次愿景。如果你已经这样做了，那么请忽略这个建议，但我提出这个问题的目的是，高级愿景或超级用户故事可以/应该有一部分提到遵循贵公司设定的架构原则。

这样做有什么好处？它让利益相关者直接从超级用户故事中参与到产品的架构和技术方面，这有助于更好地理解业务和技术方面之间的愿景，没有另一个就不能生存。

我可能有意尝试将答案扩展到问题范围之外，以便我也可以获得一些关于我的想法的反馈。

谢谢，席德。

【讨论】：

嗯，超级用户故事，是的！正是我在过去 4 天里寻找的从头开始一个项目的东西。实际上，在常规的 sprint 和用户故事的范围内，找不到如何估算和设计核心架构和项目布局的方法。杰出的。马上去试试。

【解决方案2】：

我正在按照您描述的方式进行操作。我在卡片（其他颜色）上定义了约束。约束不是以用户故事格式编写的，而是以简单的句子形式编写的，例如：

系统将支持 30 个用户的峰值使用。
必须每天进行导入。
所有过滤器和搜索结果必须在同一页面上。

如果客户有一些特殊要求，它们不是直接的单个用户故事，而是具有更广泛的影响，我将它们写为约束。这些限制没有被估计，也不是产品积压的一部分。我们使用它们来提醒真实用户故事的一些实现要求。

【讨论】：

【解决方案3】：

这是我今年 1 月在 Architect Factory 看到的一次演讲的主题。我追踪了它。这是 Lee Ingram 的“业务驱动架构：当前初创公司的示例”。我找不到幻灯片，但他谈到了指导如何满足要求的总体原则的想法。

他拥有多租户和白标等功能。使用多租户 Web 服务，您必须从一开始就规划用户的隔离/隔离。同样，如果您希望能够为您的服务贴上白标签，那么需要配置更多的东西（样式、标签等）。两者几乎都影响到每一个故事。

【讨论】：

【解决方案4】：

他不仅阐明了故事所服务的确切目的（或任何您想称它们的名称）的构成，以及如何在故事之间建立关系或依赖关系，以及如何处理它们。

【讨论】：

漂亮的演示文稿，故事地图策略似乎很有趣，我正在考虑它（我有一些疑问）......但是我的担忧更多地涉及那些称为 "non-functional" 的经典方式

【解决方案5】：

“原则”（或约束）的一般概念似乎是一个不错的概念。我已经看到当真正应该在这个类中的东西 - 例如“系统必须达到一些特定的，量化的性能水平” - 只是被扔进积压并迷失在所有其他“功能”故事中时会发生什么：没有人担心性能（因为“没关系......在某个地方有一个故事”）然后当有人最终拿起它时（奇怪的是，这些东西总是留到最后，尽管对客户有很高的价值）他们发现自己有一个一个故事在几天内完成是不可能完成的任务，而且可能只有通过对系统进行一些认真的重新架构才能真正实现，而这本来应该更早完成，但现在需要大量的改装成本。

【讨论】：

完美！下周我们将开始这个新的冒险，我刚刚在我们的迭代板上放了一行：“原则：”......我们会看到会发生什么......