Index | Scrum Master | Product Owner | Dev Team | Scrum
产品负责人 - SAFe请不要篡改Scrum！ 在这里，我们将解释SAFe描述引入产品负责人角色的观点，该角色与其在Scrum中的真实含义有重大差异。
根据《Scrum指南》中有关产品负责人角色：
…整个组织必须尊重他的决定。产品负责人的决定体现在产品待办列表的内容和顺序中。 源自《Scrum指南》
在SAFe描述中，团队待办事项类似于Scrum中的产品待办事项。团队待办列表的工作部分由计划待办列表（Program Backlog）工作填充，而计划待办列表工作是由敏捷团队外部的独立角色 - 产品经理来管理。实际上，在这种设置中，产品负责人并不是团队待办事项列表的唯一决策者。 而且，即使在规模化的情况下，Scrum也会规定：
多个团队经常在同一产品上一起工作。一个产品待办列表用于描述该产品的即将进行的工作。 源自《Scrum指南》
另外，只有一个产品负责人管理共同的产品待办列表，这才是Scrum中合适的规模化的解决方案。
相反在SAFe中，多个敏捷团队以及其各自的产品负责人和团队待办列表的工作是通用的解决方案 - 产品或产品的一部分。在以下视频中，将这种情况清楚地解释为规模化Scrum的主要功能障碍之一。
观看Youtube视频 - https://youtu.be/cr2rjaGmUzo
此外，在SAFe中：
PO在质量控制中扮演着重要的角色，是唯一有权接受完成故事的团队成员。 源自《规模化敏捷框架-产品负责人》
这是Scrum反模式。由于以下原因，PO无法承担这些责任： 1. 开发团队有责任确保交付高质量的增量。 2. 在这种情况下，PO控制着开发团队的工作成果，从而像经理一样被定位在更高的位置。它通常会引入合同游戏（contract game），并导致团队功能障碍，破坏团队合作精神。
本文链接
本文翻译自如下网站，如果译文和原稿有任何差异，请参考原文。 in case of any discrepancies between the translation and the original, the original version should be considered as the correct one Remove References To Scrum From SAFe!
作者: Roman Pichler 原文: https://www.romanpichler.com/blog/10-scaling-tips-for-product-people/?doing_wp_cron=1561070340.3916580677032470703125
给产品负责人的十条扩展建议 管理不断增长的产品是一件荣耀与挑战并存的事情：让更多人和团队参与并扩大规模并非易事。本文分享了10个实用技巧，以帮助您（产品负责人）进行有效地扩展。
1. 让合适的人参与进来 少数拥有合适的技能和主观能动性的个人要比那些不专业的当一天和尚撞一天钟的人更具生产力。根据我的经验，产品人员和开发团队成员都是如此。因此，努力让合适的人参与进来。这样可以让您的团队更长时间的保持灵活与高效，并且更具适应性。
虽然这可能听起来像常识，但我看到不止一个组织试图通过随意的增加人手到产品中来完成更多工作。例如，我与之合作的一家公司指派了使用古老编程语言开发企业信息系统的开发人员去开发采用最新技术的全新嵌入式产品。毫无疑问这些人在新岗位上非常挣扎，产品也蒙受了损失。
您的Scrum Master应该能够帮助您找到合适的人并清除相关障碍 - 例如，在没有考虑他们的技能和动机的情况下进行人员调动。
2. 不要过早扩张 我曾经参与过一项新产品开发工作，从项目开始就在三个地点分配了100多名开发人员。虽然最初没有足够的工作让这么多人忙碌，但是开发团队不想浪费时间，开始编写软件。这导致了一个膨胀的、过于复杂的代码库和一个难以适应且维护成本昂贵的产品的诞生。
与其过早地扩大规模，不如尽可能地保持小规模，直到接近产品产生市场价值的规模。这允许您快速响应市场反馈，试验新想法，并进行任何可能需要的架构和技术变动，以便进入增长阶段。
3. 建立最小可行性 另一种减少规模扩张需求的好方法是推出一款最小可行性的产品。与功能更丰富、更有抱负的产品相比，开发这样的产品通常需要更少的时间和更少的人员。更重要的是，它可以更容易地适应市场的变化，以实现产品与市场的契合。
你的产品能有多小取决于它的市场。例如，在最初的iPhone上，苹果创造了一个新的市场，因此可以提供一个相对简约的产品。与之形成对比的是，Apple Watch进入了一个现有市场，直接与三星(Samsung)、Garmin和Fitbit等公司的成熟产品竞争。
4. 帮助开发团队实现自给自足 随着产品的增长，工作负载通常也会增加: 处理越来越多的需要花费更多的精力来理解的不同的用户需求，并决定如何最佳地处理这些需求。如果您的开发团队在这个阶段仍然需要填鸭式地提供详细的需求，那么您的工作量可能会变得非常巨大。
为了减少这种风险，帮助开发团队尽早了解用户并了解他们的需求，例如，让团队成员参与用户调研(作为产品发现工作的一部分)，并让他们直接获得用户对早期产品增量的反馈。这将允许团队成员对解决方案拥有自主权，并做出正确的技术决策，提高参与积极性，为添加更多的团队打下基础，并使您不必创建细节丰富的用户故事并在sprint期间回答许多问题。
5. 有机增长 早在1968年，Melvin Conway就观察到“一个系统的结构和设计它的组织结构之间有着非常密切的关系。”这意味着，如果您从三个开发团队开始，那么您产品的软件体系结构可能由三个主要的子系统组成——不管这个体系结构是否支持所需的用户体验和特性。
为了避免这种风险，从一个产品负责人、一个开发团队和一个Scrum Master开始。一旦您验证了关键的用户体验和技术风险，就可以通过要求团队拆分来进行扩展。然后在新组建的团队中加入更多的人。这种方法也被称为有机生长，因为它模仿了生物的细胞分裂。
除了避免上面提到的Conway法则,有机增长还提供了两个额外的好处:它使增加人手的效果落到实处而不是让一个低效的团队处理所有的新特性,它允许您测量增加人手在生产力和基础设施上的影响。
后者可能看起来相当枯燥，但我曾经与一个组织合作过，为了加快开发速度，该组织一口气从3个开发团队提升到了8个。不幸的是，没有人预料到基础设施无法处理新团队造成的网络流量增加。因此，签入和签出代码突然需要花费几分钟而不是几秒钟，这意味着开发速度显著降低，直到升级工作完成后情况才有所好转。
6. 雇佣功能所有者和功能团队 随着您在开发工作中添加更多人员，请考虑使用功能团队 - 实现端到端功能的团队- 而不是像前端或持久层一样按架构分块构建组件的团队。与组件团队相比，功能团队具有更少的团队间依赖性，并降低了局部优化的风险，提高了整体产品性能。但是，它们确实需要统一标准以避免定义不良变量和代码重复：您通常不希望每个功能团队都重新开发自己的UI而放弃已有的可用代码。
当您将功能团队引入到开发工作中时 - 希望是通过有机增长的方式- 您还必须考虑对工作负载的影响。我的经验表明，单个产品人员通常无法与三个以上的敏捷开发团队合作。因此，您必须考虑让其他产品人员参负责该功能并指导功能团队，我称这些人为功能所有者。下图显示了如何应用该角色。有关更多信息，请参阅我的文章“扩展产品负责人角色”。
7. 从一个站点开始，以循序渐进的方式分发工作（如有必要） 虽然很难将合适的人员聚集在一起，但软件开发中有一些事情比分散团队 - 团队成员在不同地方工作 - 例如伦敦，波士顿和班加罗尔开展新产品开发工作更具反作用。
一般来说，存在越多的不确定性，变化和创新就会越多，参与开发工作的每个人都在同一地点办公（包括产品负责人）就越重要。这使您可以培养融洽的团队氛围，建立有效的协作并就共享标准达成一致，例如，如何协作优化产品待办事项以及进行有效的冲刺评审。
因此，在一个站点的一个团队开始新产品的开发工作。一旦解决了关键的用户体验问题和技术风险，如果需要，可以考虑以循序渐进的方式将工作分散到其他站点。这使您可以了解如何通过布局分布式团队来改进您的实践以取得成功，包括通过视频会议进行产品策略审核和产品待办事项优化的协作。
8. 考虑分拆功能和创建产品变体 成长是一件有趣的事情。虽然这是一个值得庆祝的理由 - 产品终于进入了成长阶段并取得了成功 -我们现在必须应对日益庞大且复杂的目标群体，更多样化的需求，更多的功能以及更多的开发团队。但它不一定非得这样。
还记得Facebook在2014年拆分Messenger并将其作为独立应用推出吗？分拆是一项很好的技术，可以避免成功的产品变得越来越大，越来越异构，并且需要越来越多的人来管理和开发它。取而代之的是，您可以使用自己的专业产品人员和开发团队创建新的专业产品。
产品变体执行类似的工作：但是，您可以创建针对一组特定的目标规划版本，而不是分离一个或多个功能。以微软的图表工具Visio为例，该公司提供VisioStandard和Visio Professional等变体。每个变体都可以由一个单独的团队开发，并拥有自己的产品人员来负责。
9. 利用平台优势 平台会捆绑一些共享资产，例如，共享的前端或后端组件或常见服务（如持久层，日志记录和安全防护），并标准化它们的使用方式。使用平台在扩展环境时有两个好处：首先，它鼓励重用并避免每个团队重复造轮子，比如日志服务。其次，它创建并实施跨不同功能和团队的标准，例如通用用户界面设计。
在创建平台时，您有两种选择：集体所有，要求不同的功能团队共同管理和改进平台。或者，您可以通过专门的平台所有者和团队管理平台。（请注意，平台所有者通常需要深厚的技术功底，因为他们通常需要功能团队讨论新接口和现有接口的更改。）
