Have you ever tried any similar approach? I have not tried something exactly similar but when I was a Scrum Master of my Team we did have a project wide architectural guideline and vision (which all teams were a part of), which we reminded ourselves of, during the various inspect and adapt points of a Sprint and also the Scrum Project, like during Retrospectives, Sprint Planning meetings and even Daily Scrum meetings. Some ways we used to remind us were by adding Done Criterias for tasks which included one principle to follow architectural guidelines, and it could also be added as a small note in Backlogs. In my suggestion below I have mentioned how this was looked at from a really high level.
Do you discourage it for any reason? No not at all. I say your suggestion is good and you should try it for a planning meeting. And as suggested by Ken Schwaber and Jeff Sutherland in their Scrum Guide, you should inspect and adapt during the 3 points in a Sprint - "There are three points for inspection and adaptation in Scrum. The Daily Scrum meeting is used to inspect progress toward the Sprint goal, and to make adaptations that optimize the value of the next work day. In addition, the Sprint Review and Planning meetings are used to inspect progress toward the Release Goal and to make adaptations that optimize the value of the next Sprint. Finally, the Sprint Retrospective is used to review the past Sprint and determine what adaptations will make the next Sprint more productive, fulfilling, and enjoyable."
Have you any suggestion on this matter? Is it safe for me to assume that this 'Agile' project in your company is just getting started and you don't have a project solid vision set yet? If yes, I would suggest you arrange a 2 week project wide release planning workshop. The purpose of this workshop would be get all the stakeholders, POs , SMs and Project Managers in single location and develop a Super User Story and Vision, and the rest of the Backlogs broken down from the super User Story.The Super User Story would be the high level vision of the project goal. If you have already done this then please ignore this suggestion BUT my point of bringing this up is that the high level vision or super user story could/should have a part which mentions following the architectural principle set in your company.
Advantages of this? It gets the stakeholder involved in the architectural and technical aspect of the product right from the Super User Story which helps create good understanding of the vision between the business and the technical side, and one cannot live without the other.
I may have intentionally tried to extend the answer beyond the questions scope so that I may get some feedback on my ideas as well.
I'm doing it in the way you have described. I have constraints defined on cards (other color). The constraints are not written in user story format but as a plain sentence like:
System will support peak usage of 30 users.
Imports must run daily.
All filters and search results has to be on the same page.
If customer has some special requirements which are not directly single user story but has broader effect I write them as constraints. These constraints are not estimated and are not part of product backlog. We use them to remind some implementation requirements for real user stories.
这是我今年一月在 Architect Factory 看到的一次演讲的主题。我追踪到了它。这是 Lee Ingram 的“业务驱动架构：当前初创公司的示例”。我找不到幻灯片，但他谈到了指导如何满足要求的总体原则的想法。
他拥有诸如多租户和白标签之类的东西。对于多租户 Web 服务，您必须从一开始就规划用户的隔离/隔离。同样，如果您希望能够对您的服务进行白标签，那么还有更多的事情需要可配置（样式、标签等）。两者几乎影响每一个故事。
That was the subject of a talk I saw in January this year at the Architect Factory. I tracked it down. It was Lee Ingram's "Business Driven Architecture: An Example from a Current Startup". I can't find slides, but he spoke about the idea of overarching principles that guide how requirements are to be met.
He had things like multi-tenancy and white-labeling. With a multi-tenant web-service, you have to plan from the beginning for segregation/isolation of users. Similarly, if you want to be able to white-label your service, then many more things need to be configurable (style, labels, etc). Both impact nearly every story.
He not only clarifies the makeup of exactly what purpose stories serve (or whatever you would like to call them), as well as how to build relationships or dependencies between stories, and how to deal with them.
This general idea of "principles" (or constraints) seems like a good one. I've seen what happens when things which really should be in this class - e.g "system must achieve some specific, quantified level of performance" - just gets thrown into the backlog and lost amongst all the other "feature" stories: noone worries about performance (because "it's OK... there's a story for that somewhere") and then when someone eventually does pick it up (oddly, these things always get left to last, despite the high value to the customer) they find themselves with an impossible task for the few days a story is expected to take, and likely only really achievable with some serious rearchitecting of the system which should have been done much earlier and now has a massive refitting cost.
发布评论
评论（5）
您尝试过类似的方法吗？我没有尝试过完全相同的东西，但当我是团队的 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 和项目经理聚集在一个地点，并制定超级用户故事和愿景，以及从超级用户故事中分解出的其余待办事项。超级用户故事将是项目目标的高层次愿景。如果您已经这样做了，那么请忽略这个建议，但我提出这一点的观点是，高级愿景或超级用户故事可以/应该有一个部分提到遵循您公司设定的架构原则。
这样的优点？它让利益相关者直接从超级用户故事中参与产品的架构和技术方面，这有助于在业务和技术方面之间建立对愿景的良好理解，缺一不可。
我可能故意尝试将答案扩展到问题范围之外，以便我也可以获得一些关于我的想法的反馈。
谢谢，席德。
Have you ever tried any similar approach? I have not tried something exactly similar but when I was a Scrum Master of my Team we did have a project wide architectural guideline and vision (which all teams were a part of), which we reminded ourselves of, during the various inspect and adapt points of a Sprint and also the Scrum Project, like during Retrospectives, Sprint Planning meetings and even Daily Scrum meetings. Some ways we used to remind us were by adding Done Criterias for tasks which included one principle to follow architectural guidelines, and it could also be added as a small note in Backlogs. In my suggestion below I have mentioned how this was looked at from a really high level.
Do you discourage it for any reason? No not at all. I say your suggestion is good and you should try it for a planning meeting. And as suggested by Ken Schwaber and Jeff Sutherland in their Scrum Guide, you should inspect and adapt during the 3 points in a Sprint - "There are three points for inspection and adaptation in Scrum. The Daily Scrum meeting is used to inspect progress toward the Sprint goal, and to make adaptations that optimize the value of the next work day. In addition, the Sprint Review and Planning meetings are used to inspect progress toward the Release Goal and to make adaptations that optimize the value of the next Sprint. Finally, the Sprint Retrospective is used to review the past Sprint and determine what adaptations will make the next Sprint more productive, fulfilling, and enjoyable."
Have you any suggestion on this matter? Is it safe for me to assume that this 'Agile' project in your company is just getting started and you don't have a project solid vision set yet? If yes, I would suggest you arrange a 2 week project wide release planning workshop. The purpose of this workshop would be get all the stakeholders, POs , SMs and Project Managers in single location and develop a Super User Story and Vision, and the rest of the Backlogs broken down from the super User Story.The Super User Story would be the high level vision of the project goal. If you have already done this then please ignore this suggestion BUT my point of bringing this up is that the high level vision or super user story could/should have a part which mentions following the architectural principle set in your company.
Advantages of this? It gets the stakeholder involved in the architectural and technical aspect of the product right from the Super User Story which helps create good understanding of the vision between the business and the technical side, and one cannot live without the other.
I may have intentionally tried to extend the answer beyond the questions scope so that I may get some feedback on my ideas as well.
Thanks, Sid.
我正在按照你描述的方式做。我在卡片（其他颜色）上定义了约束。约束不是以用户故事格式编写的，而是以简单的句子形式编写，例如：
如果客户有一些特殊要求，这些要求不是直接的单个用户故事，而是具有更广泛的影响，我会将它们写为约束。这些限制未经估计，也不属于产品待办事项的一部分。我们用它们来提醒真实用户故事的一些实现要求。
I'm doing it in the way you have described. I have constraints defined on cards (other color). The constraints are not written in user story format but as a plain sentence like:
If customer has some special requirements which are not directly single user story but has broader effect I write them as constraints. These constraints are not estimated and are not part of product backlog. We use them to remind some implementation requirements for real user stories.
这是我今年一月在 Architect Factory 看到的一次演讲的主题。我追踪到了它。这是 Lee Ingram 的“业务驱动架构：当前初创公司的示例”。我找不到幻灯片，但他谈到了指导如何满足要求的总体原则的想法。
他拥有诸如多租户和白标签之类的东西。对于多租户 Web 服务，您必须从一开始就规划用户的隔离/隔离。同样，如果您希望能够对您的服务进行白标签，那么还有更多的事情需要可配置（样式、标签等）。两者几乎影响每一个故事。
That was the subject of a talk I saw in January this year at the Architect Factory. I tracked it down. It was Lee Ingram's "Business Driven Architecture: An Example from a Current Startup". I can't find slides, but he spoke about the idea of overarching principles that guide how requirements are to be met.
He had things like multi-tenancy and white-labeling. With a multi-tenant web-service, you have to plan from the beginning for segregation/isolation of users. Similarly, if you want to be able to white-label your service, then many more things need to be configurable (style, labels, etc). Both impact nearly every story.
我强烈推荐 Jeff Patton 关于用户故事映射的演示。
他不仅阐明了故事到底有什么目的（或者无论你如何称呼它们），以及如何在故事之间建立关系或依赖关系，以及如何处理它们。
I highly recommend Jeff Patton's presentation on user story mapping.
He not only clarifies the makeup of exactly what purpose stories serve (or whatever you would like to call them), as well as how to build relationships or dependencies between stories, and how to deal with them.
“原则”（或约束）的这一总体想法似乎是一个不错的想法。我已经看到了当真正应该属于此类的事情（例如“系统必须达到某种特定的、量化的性能水平”）被扔进待办事项并迷失在所有其他“功能”故事中时会发生什么：没有人担心性能（因为“没关系……某个地方有一个故事”），然后当有人最终拿起它时（奇怪的是，这些东西总是被留在最后，尽管对客户来说价值很高），他们发现自己拥有一个对于一个故事预计需要几天的时间来说，这是一项不可能完成的任务，而且很可能只有通过对系统进行一些认真的重新架构才能真正实现，而这些系统本来应该更早完成，但现在却需要大量的改装成本。
This general idea of "principles" (or constraints) seems like a good one. I've seen what happens when things which really should be in this class - e.g "system must achieve some specific, quantified level of performance" - just gets thrown into the backlog and lost amongst all the other "feature" stories: noone worries about performance (because "it's OK... there's a story for that somewhere") and then when someone eventually does pick it up (oddly, these things always get left to last, despite the high value to the customer) they find themselves with an impossible task for the few days a story is expected to take, and likely only really achievable with some serious rearchitecting of the system which should have been done much earlier and now has a massive refitting cost.