一个真实的产品所有者团队
读：
一个真实的产品所有者团队
好的......足够的理论。我想与你分享，人们参与其中一个产品所有者团队我现在正在使用的角色。我列出了每个角色以及为什么我们将这些人添加到团队中。
一如既往，有兴趣了解你的想法：
- 主要产品所有者- CPO为产品所有者团队提供战略产品方向，并根据需要与每个单独的SCRUM团队直接互动。The CPO’s primary responsibility is to interface with each of the other Product Managers, gather their requirements, understand their business drivers, understand their high level timelines and make business focused trade-offs that deliver the most value to the business, given the time and cost constraints, and measured throughput of the team. The CPO can pull other Product Managers into the Product Owner team, or even the individual Scrum teams, as necessary to communicate business goals to the team.
- 架构师-架构师为产品所有者团队提供战略技术指导，并在必要时直接与每个Scrum团队进行交互。架构师的主要职责是做出影响产品长期发展方向的重要架构决策，或者那些对多个Scrum团队有影响的设计决策。架构师参与的目标是做出不能或不应该在团队级别上做出的决定。这个角色应该将尽可能多的设计决策交给各个Scrum团队。架构师还将帮助PO团队理解我们可能添加到待办事项列表中的特性的成本，并与产品管理一起开发能够在时间、成本和ROI的业务限制内交付的解决方案。亚博vip9通道
- 专案经理- 项目经理管理整体计划，并确保产品所有者团队的机制发生在必要时。项目经理将管理与外部利益相关者的发布级别通信;根据需要促进会议，并努力帮助人们以整体产品的最佳利益达成共识。此人将理解每个Scrum团队的速度，以及他们的进度如何支持与积压大小相比释放的释放。他们将在Scrum团队中致力于了解组织限制和障碍，并得到解决这些问题，或提出关于如何改进团队的整体交付能力的建议。
- 亚博vip9通道业务分析师- BA的角色是提供领域知识的专业领域,促进其他业务分析人员的参与是必要的,与产品管理引起的需求是必要的,与产品管理和产品负责人团队合作定义验收标准,并维持优先产品待办事项列表。亚博vip9通道
- 系统工程师SE的角色是提供产品领域的技术领域知识。SE将在必要时促进其他系统工程师的参与，并与架构师和团队领导一起记录任何指导或限制单个Scrum团队选择的设计约束。
- 质量保证QA的职责是提供测试领域的知识，必要时促进其他QA工程师的参与。QA代表的工作是从可测试性的角度评估用户描述的准备情况，并提供如何分解用户描述的指导，以使测试工程师的工作更容易，并产生更好的质量、更容易维护的代码。
- 技术领导/糖粉- 这些人不是核心团队的一部分，但可能在积压游览过程中根据需要参与。他们的参与产品所有者团队主要是一个正式的反馈机制，帮助产品所有者团队了解团队级别障碍和团队之间的坐标依赖关系。
总的来说，这些人负责以一种团队在sprint计划中可以轻松使用的方式分解待办事项列表。Product Owner团队还将提供早期的、高级的评估，以便我们能够快速确定发布候选范围。Product Owner团队将在做出最终版本决策之前，将候选版本范围提交给团队进行最终验证、分解和评估，但绝对是在sprint中进行任何工作之前。
对这个团队来说，现在还为时过早，但我认为我们已经万事俱备，正在努力让这个团队团结起来。就像我说的，永远欢迎你们的评论。
评论（8）
阿什利
对英航和首相是同一个人有什么看法吗?
是的，没有问题。无论如何，我倾向于喜欢PM的PM PM技能的强大BA。
Antoine Alberti.
首先，迈克，谢谢你的博客。这可能是我找到最有用信息的地方。
其次，我也试图考虑我在工作的实验室的完美分布式组织，我将有大量关于这套问题的问题，以便充分了解导致它的权衡。我会尝试专注于最有意义/最短的。
我理解的方式，产品管理是BAS / CPO。这意味着他们负责共同准备和梳理积压。我是对的，或者是提前分析业务的基础，以便为积压（CPO）提供输入？亚博vip9通道
是嵌入在团队中的基础，就像POS？如果没有，有人会处理这项工作，以便充当每个团队的代理，管理每个团队的积压，了解日常问题，参加仪式？
我想有一个全局积压，然后是每个团队的积压。我也认为每个团队都有其故事点规模，以保持以相对方式估计的可能性。如果是这种情况，他们如何管理全局估计积压？史诗级估计点？如果没有，它们如何同步所有团队的同步故事点值的方式？
如果真的存在史诗般的水平，那里史诗在团队中分裂，如何全局管理测试？有一种集成测试团队吗？如果是，则如何管理反馈？
正如我理解的那样，虽然你可能不喜欢以这种方式引用它，但团队的负责人是CPO，架构师和项目经理。我是对的，或者是终极老板的角色之一，如果决定不能集体做出决定？
我很抱歉这个长名单，但正如我告诉你的那样，我过滤很多。随意含糊地回答，或者只是他们的一部分。我们可以谈几个小时来解决我们的设立和潜在原则的所有细节。
非常感谢。
AA.
玛丽塔
喜欢帖子，迈克！我一直在沿着类似的线路思考。作为一个非常大的系统上的单个PO，我非常了解单个PO概念对我们来说无关。
我们暂时解决了这一点不同，但朝这个方向发展。我刷新了积压并完成了所有下午的内部和外部工作，并为Scrum团队提供了一个项目的初始产品积压。在一系列积压研讨会中，我将通过Scrum Master，Architect和Lead QA来实现这一项目，以便将积压达到项目成功估计项目的点。就在Sprint规划之前，我们可以以较小的批量重复此练习（如有必要），以确保所有仲及信息都可以在可能被拉入Sprint的所有故事中提供。
您是否通过使用问题团队和解决方案团队阅读Marko Taipale对此进行了阅读？当我读到这一点时，我首先开始思考在我的PO角色周围创建一个人团队的行业，他们可以帮助分享负荷。这是帖子：
http://huitale.blogspot.com/2010/12/single-product-owner-model-is-broken.html.
另外，你提到了首席产品负责人，但我没有看到个别PO被提到是产品负责人团队的一部分?还是英航在履行这一职能?你提到了产品经理/产品经理团队——我假设他们是产品负责人团队的外部人员，没有一个PM也是PO的?
查尔斯布拉德利
我很难重新调整这个陈述：
“架构师参与的目标是做出不能或不应该在团队级别上做出的决定。”
随着这个敏捷的宣言原则：
“从自组织团队中出现了最佳架构，要求和设计。”
似乎架构师已经剥夺了交付团队的自组织能力……我疯了吗?
嘿查尔斯，谢谢你的评论。Sutherland几年前公开说，自我组织从未打算过跨越阶级边界。他正在宣布宣言正在谈论的建筑是在较小的架构中。自组织IMO不会在大型建筑中发生。我认为自我组织是一种广泛误解的概念。这并不意味着团队能够选择自己的所有工具，自己的架构，或者决定建立什么......这意味着他们可以决定如何在团队内完成工作。他们决定在团队中做什么。组织，尤其是大型组织，将对团队必须尊重的团队对一支团队进行有效的限制。如果正确理解，我不认为自组织无效。可能不是一个受欢迎的pov，但我坚持不懈;-)
查尔斯布拉德利
谢谢你的响应标记。我会鼓励你看看这个领域的两件事：
1.最近(2013年)Scrum指南的变更允许Dev Org为其所有产品建立最低标准/DoD。所以，这是你的想法，开发团队不能做出所有决定。但是请注意，Dev Org DoD必须如何应用于*所有*产品，提供一个生态系统，而不是命令和控制或架构签字/层次结构。显然Jeff喜欢这个概念，因为他是Scrum指南的合著者。
2.我认为建筑*可以以一种尊重自我组织团队的方式完成。我已经看到它在大型敏捷组织中个人发生，而马班/博德已经在非常大的Scrum组织上近十年。查看更多：
http://bit.ly/1qvzcus.
特别是这些部分：
避免...建筑师手向'编码器'
尝试...建筑师和系统工程师是常规（功能）团队成员
尝试...设计/建筑惯例
避免...建筑宇航员（PowerPoint架构师）
我曾尊重Charles，据谢谢，熟悉他们的贡献。也许这是差异......我看到了像Craig和Bas，Ken和Jeff这样的人，甚至是迪恩·莱弗丁，根据*他们的行业经验沟通方法。他们的观点只是，他们的观点。我不作为福音引用他们，也不认为他们有关于如何实施敏捷的决赛。我提到了我最后回答你的杰夫，因为*你*将他视为权威，我想澄清它是什么意味着自我组织和建筑出现的架构。如果你想把这些家伙所说的东西所说，对你来说更有力量。我们选择滚动自己，不需要从这些家伙借用权威。我可以阅读他们所说的话，尊重他们的观点，如果与我的经历和我们所看到的有效相冲突，那么完全忽略他们的观点。我写的是*没有*理论。我写的一切都来自实际应用。 Product owner teams have been validated in market with the clients we support.