6

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

然而，有一件事并不能说服我。在这篇博文中， Mike Cohn 定义了一种特定类型的用户故事，他称之为约束，可以用来定义所谓的非功能性需求。就我个人而言，我不喜欢约束这个词，甚至不喜欢使用经典模板“作为......，我想要......，所以......”。

相反，我会尝试让客户始终在卡片上写下，也许使用上面的模板，尼克·罗赞斯基和伊恩·伍兹在他们出色的著作《软件系统架构》中所称的那些架构原则：

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

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

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

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

4

5 回答 5

2

你有没有尝试过类似的方法？我没有尝试过完全相同的东西，但是当我是我团队的 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 和项目经理聚集在一个地方，并制定一个超级用户故事和愿景，以及从超级用户故事分解的其余待办事项。超级用户故事将是项目目标的高层次愿景。如果你已经这样做了，那么请忽略这个建议，但我提出这个问题的目的是，高级愿景或超级用户故事可以/应该有一部分提到遵循贵公司设定的架构原则。

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

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

谢谢，席德。

于 2010-09-22T14:21:33.493 回答
1

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

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

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

于 2010-09-17T21:36:33.497 回答
0

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

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

于 2010-09-15T11:44:30.030 回答
0

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

于 2010-09-22T14:55:49.657 回答
0

我强烈推荐Jeff Patton 关于用户故事映射的演讲。

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

于 2010-09-16T00:07:51.683 回答