敏捷专题
PMP Agile
敏捷联盟：Scrum
WaterFall：瀑布模型，变更较少
敏捷：变更较多，采用经验方法，迭代，增量
-----------------------------
1.开发要素
1）工具 Tools
2）过程 Process
3）人员 People
------------------------------
49个过程：process
了解一个理论，需要熟悉他的基因
sipoc
------------------------------
假设前提
1）瀑布模型，预知未来不会产生太多变更
2）
敏捷
1）相对估算：
2）需求涌现
3）过程裁剪
PDCA戴明环
-----------------------------
经验教训
检视 Inspect
透明化、一致化 Transparency （沟通竖井，没有横向沟通，无法分享）
调整（规划风险应对）Adapt
-----------------------------
What is Agile
敏捷宣言：（道）
道、法、术、器
个体与交互 重于 过程和工具
可用的产品 重于 完备的文档
客户协作 重于 合同谈判
响应变化 重于 遵循计划
敏捷原则：（12大原则）
敏捷只是大的框架，里边又很多分支
敏捷方法论包括：
DSDM动态
XP 极限编程
FDD：面向特性驱动开发
TDD：面向测试设计
Scrum：新西兰橄榄球 ，敏捷分支，最流行
Lean Software Development：精益
Adaptive Software Develop：适应型软件开发
-----------------------------------
Scrum：
1、一个增量、迭代型生命周期框架
2、允许团队采用迭代交付未来产品
增量：大需求，拆分成小需求
先做一个轮胎，在做车身，在做发动机，在做方向盘
3、小步快跑的模式，应对客户要求
Scrum Value：价值观
Scrum Framework：3、3、5原则
3：Artifacts
Product Backlog（产品代办量）
Sprint Backlog（冲刺量）
Product Incrment：增长的产品
3：Roles
Product Owner：Do a Right Thing
产品拥有人（比发起人小），对客户负责，站在市场角度，能够打压其他竞争产品。
Scrum Master: Rightly Do a Thing
敏捷教练（PMP项目经理）：
Dev Team：
开发团队：做交付的
5：Ceremonies
Product Backlog Refinement：
Spint Planning：
Daily Scrum：每日站会
Sprint Review：
Retrospective：回顾会
PMP：5，10，49
Prince2：7，7，7
PO：产品经理，证明做一件正确的事
Scrum Master：项目经理，正确的做出来
敏捷团队：
交付价值：可用的产品
--------不是中间价值
一定要有Trust，彼此不信任
敏捷原则：
Scrum概述：
1、Ideas， Needs， requets 放入 Product Backlog
2、Sprint Planning（开工会议）：冲刺会议
Sprint Backlog（代办需求）
3、Sprint 1~4 week
Daily Scrum：每日站会
你今日做什么
已经做了什么
有什么问题？
Backlog Refinement：澄清会议
Shippable Product product increment：可交付的产品物
Retrospective：回顾会议,收集经验教训（相当于管理知识和收尾总结）
Work Mode:燃尽图
看板
How to Agile
Product Backlog：产品代办列表
1）所有客户期望东西，都需要罗列在此
2）要足够的细节化，可评估的，可变化的，有有限顺序 Appropriately，Estimated，Emergent，Prioritized
史诗级别：EPIC（可交付成果）：比较虚
任务级别：Feature（子可交付交付）：
故事级别：PBI（工作包）：用户故事，由PO讲解，有DT交付
作为一个角色，我希望有一个什么功能，达到什么价值，解决什么问题
As a role， I Want to do something
As a Traceler，I Want to cancel my whole reservation
相对估算量
-----------------------
先有需求1，后有需求2
point：基点
每个迭代周期的工作量
10天修100双鞋，工作效率是10鞋/天
20人天/20天 = 1人,没有效率的概念
团队工作效率：
5 * 8 = 30/40 效率
团队效率
Planning Poker：扑克法
1，2，3，5，8，13，21
斐波那契数列，越往后，值越大
1）PO介绍需求，默念估算，抽牌，开牌
2，5，8
2）Scrum Master：为什么选2，为什么选8？
3）重新开牌
What you as Product owner need to know
1）Estimates should be up to the team
2）Estimates should be created by the team and not by the most
3）
Store estimates：point1，相对估算量
Task estimates（活动时间）按照人天
=================================
Product Owner：赢得整个市场
做决策的一个人、澄清需求的人
1）Deliver the right product set
交付正确的产品集
2）Deliver it in right timing
确保产品产生最高效益
3）Deliver in the order that will max
4）Satisfy and excite the customer ：澄清需求
5）Clarify the customer need to development teams so that developer velocity is maximized
6）Dynamically respond to change faster
最快动态响应
职责：
1）促使产品成功
2）要有产品视角
3）要负责产品代办列表更新
4）投资回报率ROI最高
5）识别我们的价值
6）能够工作排序
7）接收和拒绝工作成果
8）决定是否发布
哪些会必须开？
1）冲刺规划会
2）更新最新状态
3）检查确认符合要求
4）回顾总结，需要PO参加
5）Dayily Scrum：团队内部审查会，不必要天天参加
6）发布计划
组织级平台：独善其身
Product Owner Characteristics：特性
1）is willing to make hard decision
----------------------------------
所有东西都很重要，就什么都不重要
PO不管敏捷团队如何，最希望客户提出的所有需求，明天就能看到它，没有可谈的地方
Scrum Team：讲究看量下饭
Do Noting
Scrum Master: 整个Team的保护神，将很多杂事挡住，给团队一个环境，便于交付
1）教育PO，cocach，Removing the barriers，移除所有障碍
2）帮助PO增大ROI
3）Impoving 能够提高创新、自我授权，自组织性
4）佣人型领导
移除障碍：
理解变更的意义：
人际关系技能：
怎么画饼，
Do Nothing！！！
------------------------------------
Ask the team！
When you don't know what to do， ask the team：
Example：
1) 上班累，PMP要不要考？
2）
commit，结果和认知，更加适应和接收，自己的意见。
Ask Team not hold Team
Dev Team：
1）团队组成：7 + 2， 5~9个人
2）每个人需要具备2到3种技能
3）交互式技能
4）不能由明星员工，他的离去对Team是个负面打击
5大会议：
1）冲刺规划会议（类似Kick-off metting）：一周迭代一次的话，一般开2个小时，2周的话，4个小时，分为两个部分：
a、由PO定义范围，澄清需求， what
b、由团队定义进度计划，进行询问，接受任务， how
如果无法回答，进行拆分，明确的开发，不明确的产生新的需求，放在下一次会议
1）Product owner reviews the PBI with priority
2）Team ask the question，Product Owner answer
3) Team
Part 2:to define the work
1)Team pick up and own PBIS
2）
Spring Backlog (冲刺堆积量)
-----------------------------
2) PBI梳理会议：Scrum Board， 工作可视化
to do in progress Done
----------------------------------
PBI 1
PBI2
3） PBI Refinement Meeting ：需求澄清会
1）如果团队问问题，PO问不上来，可以拒绝做事
-----------------------------------
本迭代周期，review下一个迭代周期的需求
收集团队问题，在下一个Sprint 所有问题，逐一搞清，PO就有能力
4）Daily Scrum：
不是报告会，是相互通告会
a）你做了什么
b）已完成什么
c）遇到什么问题
5）Forbidden Change during a sprint
2周内如果有变更，则走变更控制流程
考题管理考题，生活管生活
如果变更影响不大，就接受了吧
影响大，走变更
Monitor：
Burn up chart：燃烧图（累积完成）
Burn down chart：燃尽图（剩余工作，有局限性，BAC扩大，无法表示）
Point：
Sprint Review Meeting：
迭代周期完成后，交付给PO确认验收
挣值计算：换算成美元
与敏捷的Point：换算成功效
Sprint Retrospective:回顾会议
2周迭代周期
前9天重工作，留1天开会
吐槽也是解压的事
好的实践，改进和不足---->持续改进
Governance Model：治理框架
1）设定流程（风险、CCB。。。）
2）生命周期定义
------------------------------
EPIC
Features
PBI
-------------------------------
Sprint Prosole
