近日，由 Henrik Kniberg 撰写的博文 agile product ownership in a nutshell 从产品负责人的角度高度总结了敏捷软件开发。Henrik 称其为“将一天的产品负责人课程压缩为 15 分钟的精彩介绍”。他建议大家观看一个关于敏捷产品所有权的视频，该视频提供了相应的脚本。下面介绍了该视频所涵盖的内容。
在 Scrum 中，利益相关者需要将使用用户故事表述的东西放在队列中。这个队列叫做产品订单，由产品负责人负责：
产品负责人决定将什么放进去，什么拿出来。产品负责人还会决定顺序——什么东西需要现在构建，什么可以放在后面进行？这个工作不好做，需要与团队和利益相关者协作完成。
产品负责人需要与团队协作来管理产品订单：
这些问题我一直在谈——估算故事的价值与大小、优先级、划分——所有这些通常叫做“订单梳理”。Pat 会在每个周三的 11:00 到 12:00 召开订单梳理会。整个团队都会参加，有时一些利益相关者也会参加。会议议程会不断变化，有时关注点放在估算上，有时放在故事的划分上，有时还会为故事编写验收标准。
对于软件产品的开发来说，每个 Scrum 角色都会有自己的关注点：
各个 Scrum 角色之间应该保持健康的关系。产品负责人关注构建正确的东西。团队关注正确地构建东西。Scrum Master 或是敏捷教练关注缩短反馈回路。
产品负责人应该与团队协作来平衡质量与进度：
如果团队积累了技术债务（没有编写测试、没有持续改进架构），那么团队的速率将会随着时间的推移变得越来越慢，故事燃尽曲线将会变平。这使得预测变得几乎不可能。因此，团队要负责保持可持续的节奏，产品负责人不应该对其施加压力导致其走捷径。
拥有多个团队的大型项目会有一个以上的产品负责人。产品负责人之间的协作是非常必要的：
但在多团队的情况下，产品负责人还有一个额外的重要职责——彼此交流！我们应该组织团队与订单以最小化依赖。但总还是会有一些依赖！因此，产品负责人之间应该进行某种同步，这样才能按照顺序构建，避免局部优化。
Mountain Goat Software 在 learning scrum – the product owner 中介绍了产品负责人这一角色。产品负责人知道应该构建什么，并向 Scrum 团队表明这一点。团队会与产品负责人通力协作来确定在一个 Sprint 中应该开发多少内容。
产品负责人不能这么说“我们还有 4 个 Sprint，因此你们必须在这个 Sprint 中完成 1/4 的产品订单”。产品负责人的工作是通过清晰、鼓舞人心的目标来激励团队。团队成员最清楚他们自身的能力，因此在任何一个 Sprint 中，他们都会从产品订单中选择可以交付的用户故事。
此外，产品负责人还会与团队就如何管理需求变更这一问题达成一致：
Scrum 团队会承诺完成从产品订单中所选择的用户故事，作为回报，产品负责人也会承诺不在 Sprint 中抛出新的需求。需求可以变更（变更也是受鼓励的），但只能在 Sprint 之外变更。
Faisal Mahmood 在博文 should the product owner attend daily scrum, product owner and team engagement 中讨论了产品负责人该如何与敏捷团队在会议中协作。Faisal 解释了产品负责人为何要参加 Sprint 计划、Sprint 评审与回顾会议中：
产品负责人会向团队描述产品订单条目（用户故事或是需求）。他与团队一起工作，确保大家对产品订单条目（或是用户故事等）范围的理解是一致的。产品负责人必须要参加 Sprint 计划会议，否则团队可能会选择低价值或是压根就没有价值的条目。这会导致浪费、混淆或是错失机会的状况发生。 Sprint 评审是产品负责人接受或拒绝工作的最后机会。Scrum 团队（产品负责人、团队与 Scrum Master）与利益相关者会在 Sprint 评审中就产品方向、市场或是竞争状况中的变化进行讨论。该讨论会产生更新的产品订单。因此，我们说产品负责人必须得参与 Sprint 评审会议。
如果产品负责人不出席回顾会议，那么 Scrum 团队就很难改进计划 Sprint、管理与更新产品订单、梳理产品订单的方式；此外，团队与产品负责人及利益相关者之间的交流方式，以及执行 Sprint 评审的方式也将变得难以改进。
由 Dean Leffingwell 所创建的 scaled agile framework 可以在企业范围内应用精益与敏捷实践。它是这样描述产品负责人角色的：
产品负责人是团队中负责团队订单（即一般意义上的 Scrum 中的产品订单）并确定其优先级的成员。此外，产品负责人在质量上也有着一个重要的角色，他是团队中唯一一个有权向系统基线中“增加”新故事的人。对于向敏捷转型的大多数企业来说，这是个全新、至关重要的角色，通常需要全职参与才行（一般来说是每 1 到 2 个敏捷团队配有 1 个产品负责人）。
根据 Dean 所述，应用敏捷方法开发软件的企业必须得对多个产品经理、产品负责人与团队做出平衡：
从某种程度上来说，企业中成功的开发是一种数字游戏。如果没有在正确的角色上使用正确的人数，那么瓶颈将会严重限制速率。因此，产品经理、产品负责人与敏捷团队的数量必须要做到大致平衡，否则整个系统将会花费大量的时间在定义、澄清与接受上。
Marc Löffler 在其博文 5 reasons why a product owner team might be a good idea 中谈到了产品负责人团队的好处。其中一个原因就是每个敏捷开发团队都应该有一个产品负责人：
曾经听过让 Scrum Master 来担任产品负责人的角色，那他要是不在了呢？这就是瞎搞！但真的就有人这么做，而且不止一个。这就是产品负责人团队存在的另一个原因。即便团队中有一两个成员不在（生病或是度假等） ，团队也依然能够继续。
Marc 提到的另一个原因是产品负责人的团队协作可以改进订单的质量：
我知道并没有人规定只有产品负责人才能在订单中创建新的条目，但很多团队都觉得就该如此。产品负责人团队会迫使大家在一起工作。当然了，他们还需要与开发团队紧密协作，召开订单梳理会议，甚至是让开发者帮助维护订单等。产品负责人团队有助于培育团队的协作精神。
暂无签名
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论