建筑原理是“非功能”用户故事[封闭

Question

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

但是，有一件事不能说服我。 在此博客文章中 迈克·科恩（Mike Cohn）定义了一种特定类型的用户故事，他称之为约束，可用于定义所谓的非功能要求。我个人不喜欢这个词 约束 甚至使用经典模板“作为...，我想要...，这样……”。

相反，我会尝试使客户在卡片上始终在卡片上写作，也许是上述模板，那些尼克·罗赞斯基（Nick Rozanski）和艾恩·伍兹（Eoin Woods）呼唤的模板 软件系统体系结构, 建筑原则:

“建筑原则是指导建筑定义的信念，方法或意图的陈述。”

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

我想处理这些 原则 卡是将它们放在我们的积压卡板旁边，以便在用户故事定义和计划活动中始终存在它们。我还会鼓励客户和开发人员每次认为卡可以作为团队的提醒来提醒他们，并将其捡起并将其放在迭代板旁边。

您是否尝试过类似的方法？您是否出于任何原因劝阻它？您对此事有任何建议吗？

Answer 1

您是否尝试过类似的方法？我并没有尝试过完全相似的事情，但是当我是团队的混乱大师时，我们确实有一个项目广泛的建筑指南和远见（所有团队都是其中的一部分），我们提醒自己，在各种检查和适应点期间Sprint和Scrum项目，例如回顾期，冲刺计划会议，甚至每日的Scrum会议。我们用来提醒我们的一些方式是为任务添加完成的标准，其中包括一个原则遵循建筑指南，并且也可以在积压中添加为小笔记。在下面的建议中，我提到了如何从非常高的水平看待它。

您是否出于任何原因劝阻它？一点都不。我说您的建议很好，您应该尝试进行计划会议。正如肯·施瓦伯（Ken Schwaber）和杰夫·萨瑟兰（Jeff Sutherland）在其Scrum指南中所建议的那样，您应该在冲刺的3分中进行检查和适应 - “有3点需要检查和适应Scrum。 Sprint目标，并进行适应以优化下一工作日的价值。此外，Sprint审查和计划会议还用于检查朝着发布目标的进度，并进行适应，以优化下一个Sprint的价值。最后， Sprint的回顾展用于审查过去的冲刺，并确定哪些改编将使下一个冲刺更具生产力，充实和愉快。”

您对此事有任何建议吗？对我来说，假设您公司中的这个“敏捷”项目刚刚起步，您还没有稳定的愿景设置？如果是，我建议您安排一个为期2周的项目广泛发布计划研讨会。该研讨会的目的是让所有利益相关者，POS，SMS和项目经理在单个位置并发展超级用户的故事和愿景，其余的积压案从超级用户的故事中分解出来。超级用户的故事将是项目目标的高级视野。如果您已经做到了这一点，请忽略这个建议，但是我提出这一点的观点是，高级视觉或超级用户的故事可以/应该有一部分，该部分遵循公司中设定的建筑原则。

这是优势吗？从超级用户的故事中，利益相关者参与了产品的建筑和技术方面，这有助于对业务和技术方面的愿景有很好的了解，而一个人不能没有另一个。

我可能已经故意试图将答案扩展到问题范围之外，以便我也可以对自己的想法获得一些反馈。

谢谢，席德。

Answer 2

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

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

如果客户有一些特殊要求，这些要求不是直接单一的用户故事，但效果更大，我将其写为约束。这些约束未估计，也不属于产品积压的一部分。我们使用它们来提醒对真实用户故事的某些实施要求。

Answer 3

那是我今年1月在建筑师工厂看到的演讲的主题。我跟踪了。这是Lee Ingram的“业务驱动建筑：当前创业公司的示例”。我找不到幻灯片，但他谈到了指导如何满足要求的总体原则的想法。

他有多重租赁和白标的东西。借助多租户网络服务，您必须从一开始就计划隔离/隔离用户。同样，如果您希望能够白色标记您的服务，那么还需要配置更多的东西（样式，标签等）。两者几乎都会影响每个故事。

Answer 4

我强烈推荐 杰夫·帕顿（Jeff Patton）关于用户故事映射的演示.

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

Answer 5

“原理”（或约束）的这种一般思想似乎是一个好方法。我已经看到当真正应该在此类中进行的事情 - 例如，“系统必须达到某种特定的，量化的绩效水平” - 只是被扔进积压中并在所有其他“特征”故事中迷失了：没有人担心表演（因为“没关系...有一个故事”），然后当某人最终确实捡起它时（奇怪的是，尽管这些事情对客户的价值很高，但这些东西总是持续下去）在几天的时间里，不可能的任务预计要采取的时间，并且只有对系统的认真进行重新进行的重新研究才能真正实现，而该系统本来应该做得更早，现在有大量的改装成本。