作为为数不多的专讲敏捷产品管理的书，Roman Pichler 这位敏捷产品管理专家，全面描述了敏捷环境中的产品管理，将其经验及扩展理解倾注在这本双语小书（印刷规格尺寸）之中，确实觉得耐读奇特。
全书内容精简，中文版部分130页左右，共有6个章节，所述分别是 理解产品负责人的角色、规划产品愿景、产品 backlog、发布计划、sprint 会议中的合作、转型为产品负责人。
所读会意之处，思考记录如下：
1. 产品负责人
在项目/产品开始之前，对目标及愿景的理解和收集转换尤为重要。较传统方式是市场部负责市场调研，编写产品概念并将其传递给产品经理，产品经理编写需求规格说明书并将其传递给项目经理，项目经理再传递给开发团队。往往如此一番，产品愿景在经过层层传递之后迷失方向，直至最后“失真” 。
因此产品负责人作为管理产品backlog，并确保开发团队交付工作的唯一责任人。在Scrum中扮演者最困难且又重要的角色。PO作为一个全职工作，代表“客户”，传递需求，在“意愿”和“技术”之间起着桥梁的作用。
PO与SM的互补关系，产品负责人主要负责“目标”---开发正确的产品；ScrumMaster主要负责“方式”---使用正确的方式来实施Scrum。
对于复杂的大型Scrum项目，通常会设立首席产品负责人来对其他小型团队进行指导。
2. 产品愿景
《Scrum敏捷项目管理》提到“ 愿景描述了项目的发起原因以及预期的最终状态。” 因此，对于产品目标应广而专，少即是多。 针对众多的客户和产品属性，可遵循的优先级排序要素有： 舍弃孩子套狼、尽量保留、保孩子舍狼。
如我们所知的工具和方法，可以通过“穿刺”（其他地方叫探针）spike来探求具体问题的可执行原型。运用PDCA （计划、执行、检查、行动），还有建立在市场和产品什么周期基础上的产品线路图（关注眼下的6-12个月），还有Kano模型，愿景盒、场景和消耗图（通常创建2个消耗图，一种是在没有产品的情况下，实现特定目标所必须的活动；一种是在产品可用的情况下，未来所需要的活动）。
3.产品 backlog
四个英文字母DEEP描述产品backlog的特征： Detailed appropriate 详尽适当的、Estimate 经过估算的、Emergent 涌现的、Prioritied按优先级排序的。
特别提到梳理产品 backlog 的重要，通常会分配10%的时间来做这部分工作。其中， 价值、知识、不确定性和风险、可发布性、依赖性等都是产品 bcaklog 优先级排序需要考虑的因素。
在敏捷估算实践中 大家都经常会遇到估算不准确的情况，书中提了3点建议：1. 团队必须大致了解需求条目需要哪些具体的工作；2.团队成员必须能够判断这个需求条目与其他条目之间的依赖；3.必须要对完成标准有一个定义。
4.产品负责人角色
“固定时间而在功能范围特性的多寡上保持灵活 。”这句话巧妙的解决了时间、预算和功能这三个因素之间的关系和作用。
尽早而频繁的发布软件，除发布燃尽图之外，还有发布燃尽柱（通过前后sprint对比，知道存在什么问题）。
做发布计划是考虑的四个因素：产品 backlog 条目、backlog 剩余工作量、速率、时间；
5. sprint会议合作
参加sprint计划会议，PO的主要目的是：明确需求，回答问题 。
PO需参加每日例会，关心项目进展时，一定采用建设性的方式最好是提问的方式（引起团队注意，同时又将解决问题的自由留给团队）。
spint 评审会议，PO宣布会议开始，将增量与sprint目标、目标的实际情况进行对比，判断项目的进展。
sprint回顾会议，PO要定期参加，借助会议计划，提改进措施，巩固与Scrum团队成员之间的关系。
PO做汇报，应多邀请利益相关方参加sprint评审会议和scrum每日例会，而非只用sprint燃尽图做汇报工具，容易成为一种控制装置，征求领导对燃尽图的态度，说明缺乏信任。
总结
全书对产品负责人这个角色的重要性、所存在的问题及陷阱。应用实例，每章结尾又附加反思，浅显易懂，略显不足的是没有提供很多作为PO角色所涉及运用的工具图标模板之类，当然Scrum敏捷本就没有标答，因项目不同，环境各异。 书中重复很多次提到，产品负责人要更多的融入团队，是“我们”而非“我”， 不仅需要负责维护backlog并保证所有人都可以看到、理解到位。Scrum团队所有成员结成一种紧密互信的牢固关系。每天至少一小时的时间在团队办公室内与团队共处。作为产品负责人处理问题要坚决，待人接物要平和，最最重要的是，需要获取管理层的持续信任和支持。
2018.4.13
