一、敏捷项目管理的引入
传统的瀑布式软件开发造成大量的浪费且输出并不是用户想要的产品。
敏捷开发的历史：2001，鲍勃马丁和其他17人发布的敏捷宣言
敏捷软件开发宣言
独立和互动 胜过 流程和工具
可运行的软件 胜过 复杂的文件
客户协作 胜过 合同的谈判
应对变化 胜过 遵守计划
Agile（敏捷）开发的特点：清晰定义成果和目标，明确传递给团队。减少控制和命令。
将权力归还给执行者，行事的出发点基于对团队的信任。
产品满足客户应用的要求是企业生存的必要条件。
敏捷人的价值观：只有用户喜欢的产品才是敏捷人的目标。
敏捷人的特点：拥抱变化
敏捷人对质量的定义：产出超越客户的期望值。
对敏捷的常见误解：
对人的要求很高
敏捷无文档，也不做设计
敏捷就是快，可以缩短工期
敏捷就是持续集成
实施敏捷必须使用自动化测试
敏捷就是很炫酷的工作方法
敏捷好，其他项目管理不好
实现敏捷很容易
敏捷可以解决所有问题
以上都是误解！！！
敏捷思维=Scrum +XP + Kanban
二、Scrum方法论
Minimal Framework of Scrum敏捷开发的基本框架
核心要素可以归纳为3355，另外的工具是通用的Scrum实践。
3 roles：Product Owner，Scrum Master，Team
3 artifacts：Product Backlog，Sprint Backlog，Burndown Chart
5 ceremonies：Sprint Planning，Sprint Review，Retrospective，Daily Scrum，Sprint
三、Scrum要素
PSP潜在可交付产品增量
Release Plan（发布计划）----(PO)Product backlog（产品需求）----(team)Sprint backlog迭代需求(commitment承诺)
High Quality高质量的产品
Tested经过测试的产品
Entire完整可用的产品
Do well when it should be done.在规定的时间内必须尽最大努力完成好。
Product Backlog产品需求(Product owner产品负责人)
DEEP Principle原则
Detailed appropriately适当细化的
Emergent随时产生的
Estimated有估算的
Prioritized有优先级的
Product Backlog including产品需求可以包括:
用户故事, Bug, Task, 其他
但是用户故事是我们最希望出现在产品需求里面的内如。
用户故事是产品负责人用来讨论的关于产品需求的一个提示。
As a…(role)
I want/need …(goal)
So that I could…(value)
User Story 3C原则
Card写在卡片上
Conversation用于对话
Confirmation及时确认
INVEST
Independence独立的
Negotiable可讨论的
Valuable有价值的
Estimable可估算的
Small小的
Testable可测试的
Epic or implementable
X史诗级 V可被实现的
四、角色和职责
Product Owner产品负责人：(Wolf)
对产品的投资回报率负责
驱动产品成功
确定产品的愿景
管理product baclog
定义价值
排列优先级
决定发布
Stakeholder汇报
ScrumMaster
变革的引领者
服务型领导者
障碍的清除者
Scrum流程专家
系统的维护工
Team
5-9人，
Full time staff
自我组织和管理
所有人都是team member
淡化Function
是一个learning team
五、Scrum阶段活动
Sprint planning迭代策划
Morning上午：PO tell USER Story。PO讲故事。
Afternoon下午：estimate估算，discuss讨论，distribute task分配任务
Task估算单位是小时，
User story估算单位是story point故事点
Sprint Backlog迭代需求
故事点系统
估算的目标是在一定时间内把估算的错误率降到最低，而不是尽量精确。
估算是为了讨论和学习，排除不确定性，分享知识，打通其他人不知道的内容。
Burndown Chart燃尽图
Daily Scrum每日站会
不超过15min
不用来解决问题，用来提出问题
只有Scrum team发言，stakeholder不允许发言
每日站会的三个问题：
What has been done since last meeting?上次会议后完成了什么？
Want need to be done before next meeting？下次会议前需要完成什么？
What obstacle in the way?有什么阻碍？
Sprint review迭代评审
非正式
不用PPT
最多两个小时
Sprint retrospective迭代回顾：Team团队自行找到可以做得更好的点，实现持续改进
传统方式：差距+新的需求
心路里程坐标图
