理解 Product Owner
Envisioning the Product
The Product Vision
一个有效的vision应该要能回答以下的问题：
－谁会买产品？谁是目标消费者？谁会使用产品？谁是目标使用者？（买的人不等于使用的人）
－产品解决的是什么需求？产品增加了什么价值？
－哪个产品是最重要的用来满足需求的或者说使得产品成功的？产品大致上是什么样的和做什么？产品在哪个领域脱颖而出？
－这个产品是如何胜出竞品和在同公司中脱颖而出？产品的特殊销售点是什么？目标价格是多少？
－公司要怎样从销售产品中赚钱？盈利的资源和商业模型是什么？
－产品可行吗？公司能够生产和售卖产品吗？
Vision需要有以下特质：
－可分享和统一
－宽泛和有吸引力：给团队成员的创造力留有空间
－简短和甜美
最小市场产品
一个拥有满足被选用户需求的最小功能的产品
“There is only one move that really counts: the next one"
简单
－功能简单
－用少的功能和竞争对手对抗
－用户交互的简单
客户需求和产品属性
产品属性包括功能性和非功能性的。非功能性的包括性能，稳固，风格，设计和使用性。
Vision的产生
－使用 pet project
－使用 Scrum
一旦vision产生, 专家需要退出团队而变成合作方
创造Vision的技能
产品原型
demoing cycle: plan, do， check and act
人物原型和场景
我们创造场景来表述人物原型在使用和不使用产品下是怎么达到目标的。
Vision box 和 Trade journal review
Kano Model
-基础，性能，使愉悦
最小产品和产品变体
每个变体针对特定的用户群体和细分市场
常见错误
－没有vision
－预知vision
－分析麻痹
－自以为是
－big is beautiful
Working with the Product Backlog
四大属性
－恰到好处的细节
－可预估的
－自然发生的
－有优先级的
梳理product backlog
发现和描述述内容
－发现
－描述
－组织（theme）
排优先级
－价值
－知识，不确定和风险
因为风险和不确定影响产品的成功与否，不确定和风险物品应该是高优先级的。
－release能力
－依赖
为sprint计划做好准备
－选择sprint的目标
－在恰当的时间准备正好够的物品
－分解物品
－确保明确，可测试性和可行性
衡量物品
大致估算和精准估算
－story points
－planning poker
评估非功能性需求
快速跟踪评估
处理非功能性的需求
管理非功能性的需求：非功能性的需求分为全局的和局部的，全局的非功能性需求需要在一开始的时候就细化。
product backlog 规模
－只使用一个product backlog
－拓展视野
－提供不同的view of product backlog
常见错误
－用详细的需求文档当作product backlog
－愿望清单
－需求推送：po自己写好backlog items然后给到开发人员
－没有提前准备好grooming
－相互竞争的product backlogs
计划发版
时间，费用和功能
质量是锁定的：质量标准被记录在完成的定义中。
季度周期
速率（velocity）
“而我说的算法是“用完成的任务点数除以实际投入的人日数”，假设前5个sprint分别完成9、12、5、16、10个story point，实际投入的人日数分别为20、20、25、25、20，（9+12+5+16+10）/（20+20+25+25+20）=0.47，利用这个数值以及下一个sprint的可用资源（比如是25），就可以算出下一个sprint可以完成的工作量：0.47*25=11.75进一步的，由于可以乐观的认为团队熟练程度在提高，可以调高速度为0.5，于是预计可以完成0.5*25=12.5的工作量。”
发布燃尽
发布计划
－预测速率
－创造发布计划
大项目的发布计划
－评估的统一基准线
－前瞻的计划
－流水线
常见错误
－没有发布燃尽图和计划
－po没有产品发布计划
－大型发布（最重要的）
－质量的妥协
Collaborating in the Sprint Meetings
Sprint Planning
最为po最终要的是：
－在sprint planning meeting前把product backlog排好优先级并保证高优先级的items都细化好
－会议期间po的作用是阐明需求和回答问题，po帮助团队什么必须被完成，team讨论出多少可以被完成和怎么完成
完成的定义
只有visioning sprints有自己特殊的完成的定义。
在第一个sprint之前，po，scrum maser和team要一起定义出完成。
Daily scrum
－po分享自己在做什么或将要做什么，共享一些发布层面的知识资讯
－不对团队个体的工作进度进行评论，如果有担心，可以通过表述整体进度不限有一些拖后（burndown shows a lot of work left to do）
Sprint backlog 和Sprint burndown
Sprint Review
just－in－time review
Sprint Retrospective
大项目中的sprint meeting
－joint sprint planning
－scrum of scrums
－joint sprint review
－joint sprint retrospective
常见的错误
－蹦极po：不参与sprint的过程
－消极的po
－不可持续的脚步
－sprint review不真实
－汇报给上级sprint burndown（用发布burndown或发布计划去沟通）
Transitioning into the Product Owner Role
po 要做和不要做
do／dont：
－需要做什么／说怎么做和要花费多少
－挑战团队／灞陵团队
－建立高校的团队／专注在短期的发布
－商业价值思考／执着的保持原有的计划
－保护团队远离外界的噪音／让团队担心变化
－在sprint和sprint之间整合变化／在sprint里插入变化
