Mar*_*one 6 agile requirements user-stories
我即将在我们公司启动一个试点项目,以引入敏捷实践,包括使用用户故事.在阅读了Mike Cohn的两本书,特别是Agile Estimating and Planning和User Stories Applied之后,我现在对如何继续进行了更清晰的了解.我有信心在练习中改进我们的技术.
然而有一件事并没有让我信服.在这篇博客文章中, Mike Cohn定义了一种特定类型的用户故事,他称之为约束,可用于定义所谓的非功能性需求.就个人而言,我不喜欢单词约束,甚至使用经典模板"作为...,我想......,所以......".
相反,我会尝试让客户写,总是在卡片上,也许是上面的模板,Nick Rozanski和Eoin Woods所称的那些,在他们出色的书籍软件系统架构中,架构原则:
"建筑原则是指导建筑定义的信念,方法或意图的陈述."
(他们还将这些原则划分为商业原则和技术原则,我认为我们不应该关注这种差异.)
我想用这些原则卡做的是将它们放在我们的积压卡板旁边,以便在用户故事定义和规划活动期间始终存在它们.我还鼓励客户和开发人员拿起它们,并在每次认为卡片可用作团队提醒时将它们放在迭代板旁边.
你有没有试过任何类似的方法？你出于任何原因劝阻它吗？你对这件事有什么建议吗？
您尝试过类似的方法吗？我没有尝试过完全相同的东西，但当我是团队的 Scrum Master 时，我们确实有一个项目范围的架构指南和愿景（所有团队都是其中的一部分），我们在各种检查和适应点期间提醒自己这一点Sprint 和 Scrum 项目的一部分，例如在回顾、Sprint 计划会议甚至每日 Scrum 会议期间。我们用来提醒我们的一些方法是为任务添加完成标准，其中包括遵循架构指南的一项原则，并且它也可以作为待办事项中的小注释添加。在我下面的建议中，我提到了如何从一个非常高的层面来看待这一点。
您是否会出于任何原因阻止它？一点都不。我说你的建议很好，你应该在计划会议上尝试一下。正如 Ken Schwaber 和 Jeff Sutherland 在他们的 Scrum 指南中建议的那样，您应该在 Sprint 的 3 个点中进行检查和调整 - “Scrum 中有 3 个点需要检查和调整。每日 Scrum 会议用于检查实现 Sprint 的进度。 Sprint 目标，并进行调整以优化下一个工作日的价值。此外，Sprint 审查和规划会议用于检查实现发布目标的进度，并进行调整以优化下一个 Sprint 的价值。最后， Sprint 回顾用于回顾过去的 Sprint，并确定哪些调整将使下一个 Sprint 更加高效、充实和愉快。”
您对此事有什么建议吗？我是否可以安全地假设贵公司的这个“敏捷”项目才刚刚开始，而您还没有制定明确的项目愿景？如果是，我建议您安排一个为期 2 周的项目范围发布规划研讨会。本次研讨会的目的是让所有利益相关者、PO、SM 和项目经理聚集在一个地点，并制定超级用户故事和愿景，以及从超级用户故事中分解出的其余待办事项。超级用户故事将是项目目标的高层次愿景。如果您已经这样做了，那么请忽略这个建议，但我提出这一点的观点是，高级愿景或超级用户故事可以/应该有一个部分提到遵循您公司设定的架构原则。
这样的优点？它让利益相关者直接从超级用户故事中参与产品的架构和技术方面，这有助于在业务和技术方面之间建立对愿景的良好理解，缺一不可。
我可能故意尝试将答案扩展到问题范围之外，以便我也可以获得一些关于我的想法的反馈。
谢谢，席德。