[Scrum]成为一个有效的Product owner

4个问题：
1.Product owner的首要职责是什么？
2.Prodcut owner和ScrumMaster之间的区别是什么？
3.理想的product owner应该具备哪些技能？
4.如果一个项目没有product owner会发生什么事情？

传统产品经理的观点
确定客户需求 -> 创建目标说明书 -> 产生产品概念 -> 选择产品概念 -> 测试产品概念 -> 提出最终的说明书

传统的开发
在Scrum和Agile之前，在项目开始之前都会谨慎地考虑什么是需要的，以及它将如何被交付。所有将来的工作都被暂停，依赖于此工作的完成。理论上在项目开始之前的变动成本为$1，那么到了项目完成60%的时候做同样的变动，成本可能会是$100。

prodcut owner帮助减少不确定性

突发状况
事先不可能知晓所有的需求。努力和长时间的思考可以揭露某些需求，但是每个项目都会有一些突发的需求。突发需求是用户事先不能确定的。

那么如何应对？

• 多说少写，只记录你需要的。
• 给用户看实际的软件。
• 认可突发的需求。
• 逐渐提炼对产品的理解。并且在产品清单中表达出这种累进的提炼。

Agile产品管理主要关注从产品规划到冲刺之间的间隔。

使用产品清单来叙述故事
故事可以产生主要的清单项。
Card：把故事记录在卡片上
Conversation:在交谈的过程中出现故事之后的细节(可以使用思维导图工具)
Confirmation:验收测试确认故事被正确地编码
添加故事细节：作为满足条件的细节；分解为更小的故事。

排列产品清单
关键是使用不同的细节层次来编写产品清单项。将要进行工作的故事细粒度，未来长远的故事粗粒度。

故事研讨会
参与人员可以包括开发人员、用户、其他人员。大家头脑风暴产生故事。目的是写出尽可能多的故事，一些是准备好实现的，一些是大规模的。在此时还没有区分优先次序。
另外一种办法是从用户界面入手，问一些自由回答的问题，例如：
.用户下一步最可能希望做什么？
.用户可能在这里犯哪些错误？
.在这里什么会混淆用户？
.用户可能需要什么样的额外信息？
以每个用户角色来考虑这些问题。可以使用模板：“作为一个<用户角色>，我希望<达成目标>，因此可以<理由>”

详细到什么程度？
必须描述足够详细到可以变成冲刺过程的输出。

构成一个好故事的方面(INVEST)
Independent：依赖会导致难于处理预测和区分优先次序。
Negotiable：故事不是合约，留有一些灵活性。故事卡片只是功能的简短描述。
Valuable:对使用者和购买者，而不是开发者，有价值。重写开发者的故事来反映使用者和购买者的价值。
Estimatable：计划基于用户故事，因此需要能够估算它们。
Size appropriately：如果准备开始对故事进行工作，那么应该小到足够能在一个冲刺中完成。
Testable：可以被测试，这样可以有种方式知道是否一个故事已完成。只有完成和未完成，没有“部分完成”或“除了...没成”。

划分产品功能项的优先次序
3个步骤：1.组织需求为不同主题。2.评定每个主题的重要性。3.区分主题的优先次序。

为什么划分主题？
通常单独的故事不能互相区分优先次序。例如：在一个字处理器中，制表重要还是Undo重要？一辆汽车的左前轮或右前轮谁更重要？
将故事组织为主题的步骤：
1.在单独的卡片上记录下每个故事
2.除去冗余的故事
3.组合类似的故事
4.给每个组标记一个主题名称
5.如果有大量的主题或者有小主题，考虑安排主题层次
6.回顾结果

共性分组
将卡片随机分发给所有参与者。让某人阅读一个卡片然后将它贴在墙上或桌上。下一个人阅读自己的卡片，接着张贴卡片，或者查找类似的卡片并把自己的卡片加到一起。持续重复道没有卡片为止。确信你按照使用者的需求来组织故事，而不是按照你创建软件的方式来组织。

评定每个主题的重要性
有两种一般的方法：团队意见、使用者调查
还有一些特殊的方法：主题筛选、主题评分、相关权重、Kano分析、财务分析、解析层次过程

主题筛选
.为下一个发布的重要事项，确定大约5-9个选择标准。
.选择一个基线主题(可能包括在下一个发布、被大多数团队成员所理解)
.评定每个候选主题和基线主题的相关性

主题评分
.跟主题筛选相似，但是选择标准有权重
.需要为每个标准选择一个基线主题
.每个主题根据每个选择条件的基线进行评定

相关权重
.从1-9评定有一个故事/主题的影响
.从1-9评定没有它的影响
.计算每个故事或主题相对整个产品清单的价值
.对每个故事或主题的开发估算
.计算每个故事或成本相对整个产品清单的成本
.优先次序=相对值/相对成本

Kano分析
有三类特性
惊喜型：用户不知道他想要的特性，直到亲眼看到
线性型：越多越好
必要型：为了让用户满意，必须出现
为了评定一个功能特性的类型，我们可以对少量用户(20-30)进行调查。对他们问两类问题：
.功能的问题，“如果有这个功能，你感觉如何”
.丧失功能的问题，“如果缺少这个功能，你感觉如何”
对一个特性的两个回答分类，得出此特性的类别(M/L/E/Q/R/I)
最后对分析结果加以聚类统计，得出该主题/故事的类别。我们应该必须包括所有必要型的特性和某些线性型的特性，给至少一些惊喜型的特性留一些空间。