建筑原则是“非功能性”用户故事

Question

我即将在我们公司启动一个试点项目，以引入敏捷实践，包括使用用户故事。在阅读了Mike Cohn的两本书，特别是Agile Estimating and Planning和User Stories Applied之后，我现在对如何继续进行了更清晰的了解。我有信心在练习中改进我们的技术。

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

相反，我会尝试让客户在他们出色的书籍Software Systems Architecture，建筑原则中使用上述模板，也就是上面的模板，也就是Nick Rozanski和Eoin Woods所称的那些。 EM>：

  

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

（他们还将这些原则划分为商业原则和技术原则，这是我认为我们不应该关注的差异。）

我想用这些原则卡片做的是将它们放在我们的积压卡板旁边，以便在用户故事定义和规划活动期间始终显示它们。我还鼓励客户和开发人员在每次认为卡片可以作为团队提醒时，将它们接收并放在迭代板旁边。

你有没有试过任何类似的方法？你出于任何原因劝阻它吗？你对这件事有什么建议吗？

Answer 1

你有没有试过任何类似的方法？我没有尝试过完全相似的东西但是当我是我的团队的Scrum Master时，我们确实有一个项目范围的建筑指南和愿景（所有团队都参与其中），我们在各种检查和调整点中提醒自己Sprint以及Scrum项目，如回顾展，Sprint计划会议甚至Daily Scrum会议。我们过去常常提醒我们的一些方法是为任务添加Done Criterias，其中包括遵循架构指南的一个原则，并且它也可以作为Backlogs中的小注释添加。在我的建议中，我已经提到了如何从一个非常高的层面看待它。

你出于任何原因劝阻它吗？一点都不。我说你的建议很好，你应该尝试一下计划会议。正如Ken Schwaber和Jeff Sutherland在他们的Scrum指南中所建议的那样，你应该在Sprint的3个点中进行检查和调整 - “在Scrum中有三个点进行检查和调整。每日Scrum会议用于检查进展到Sprint目标，并进行调整以优化下一个工作日的价值。此外，Sprint审查和计划会议用于检查发布目标的进展情况，并进行调整以优化下一个Sprint的价值。最后， Sprint Retrospective用于回顾过去的Sprint，并确定哪些改编将使下一个Sprint更高效，更充实，更有乐趣。“

你对这件事有什么建议吗？我可以安全地假设贵公司的这个“敏捷”项目刚刚开始并且您没有项目可靠的设置吗？如果是，我建议您安排为期2周的项目范围发布计划研讨会。本次研讨会的目的是让所有利益相关者，PO，SM和项目经理在单一地点获得，并开发超级用户故事和愿景，其余的Backlogs从超级用户故事中分解出来。超级用户故事将是项目目标的高层次愿景。如果你已经这样做了，那么请忽略这个建议但是我提出这个问题的意思是高级视觉或超级用户故事可能/应该有一部分提到你公司设定的建筑原则。

这有什么好处？它让利益相关者从超级用户故事中获得产品的架构和技术方面的参与，这有助于更好地理解业务和技术方面的愿景，而且不能没有其他人。

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

谢谢，Sid。

Answer 2

我按照你描述的方式做这件事。我在卡片上定义了约束（其他颜色）。约束不是以用户故事格式编写的，而是以简单的句子写成：

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

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

Answer 3

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

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

Answer 4

我强烈推荐Jeff Patton's presentation on user story mapping。

他不仅澄清了故事的目的（或者你想称之为什么）的构成，以及如何在故事之间建立关系或依赖关系，以及如何处理故事。

Answer 5

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