问解决方案架构师和产品负责人的解压作用

EN

无论是Scrum还是SAFe，产品所有者都不能控制解决方案的实现细节。它们代表了客户的需求，并拥有需要从产品立场构建的功能的积压。

团队应该有一个for的定义，来设定实现的质量期望。团队承诺在DoD上满足他们承担的任何待办事项的所有适用项，并且产品负责人承诺给他们时间去做这件事。

的确，这是在他们的所有权，取消优先的整体架构改进项目，技术债务，和其他关注。在我的经验中，这从来不符合他们的最佳利益，因为它侵蚀了团队的信任和产品的长期成功。特别是，它导致技术债务，这使得后期功能的实现成本更高。

角色之间应该存在健康的紧张关系。然而，就像在一场拔河比赛中，如果任何一方都太强或太弱，一切都会崩溃。如果产品负责人使用组织权威来规定团队如何实现工作，那么他们的工作就违背了Scrum和SAFe的意图，而且他们很可能在这个过程中产生了一系列的负面副作用。

如果您想了解更多关于预期实现的内容，我肯定会阅读Scrum指南's关于Scrum中角色的指导。

SAFe有一个称为容量分配的结构。这意味着每个敏捷发布培训都需要分配一定的百分比来启用功能，并将一定的百分比分配给特性。例如，列车可能有70%的特点和30%的使能能力分配。产品经理负责定义特性，架构师负责定义使能器。同时，他们必须对程序的待办事项进行排序和排序。然后，团队中的每个sprint产品所有者决定在sprint期间实现什么。我写了一个博客，简化了一个安全敏捷的角色、工艺品和仪式列表。它可能会帮助你走向正确的方向。请阅读产品经理和架构师。

产品所有者通常向产品经理报告(虽然不一定)。架构师通常与产品经理级别相同。

平方是正确的。更重要的是，产品负责人不应该关心某事是如何实现的，而应该只关心实现了什么。

其他人似乎都有礼貌地说，我会说:听起来你的老板想成为建筑师。如果不是这样的话，请他们邀请SAs参加产品待办事项整理站起来我知道我们正在创造一种活动，如果不应该存在的话，但是我们已经有了超出常规的紧张状态，所以在你抨击我之前就跟着做吧。，并就即将到来的冲刺可能带来的挑战或担忧进行对话。

这样，在执行工程任务之前就有了更大的一致性。我会在这里停下来，但如果你需要的话，我有更多的想法。