一、什么是敏捷

（一）是否遇到了这些问题

■产品上线才发现大部分功能不是客户想要的
■总是无法及时响应客户变化的需求
■做的甘特图计划非常精细，但就是实现不了
■团队成员都是高手，但是开发效率上不来

（二）怎么解决

4大核心价值

个体和互动＞流程和工具

工作的软件＞详尽的文档

客户合作＞合同谈判

响应变化＞遵循计划

12条原则

尽早、持续交付、有价值、面对面、反省调整等

（三）敏捷误区

敏捷不等于不需要规划

敏捷不等于不需要文档

敏捷不等于每天发版本

（四）我理解的敏捷

二、别人是怎么“敏捷”

（一）Scrum被广泛采用：微软、雅虎、谷歌、电艺、飞利浦

（二）两个纬度

1、Who

（1）产品所有者-决定干什么

（2）ScrumMaster-决定怎么干

团队管理（牧羊犬）

Scrum专家

确保工作顺畅

确保工作开心

确保不被骚扰

（3）执行团队

人少 不求人 不中断

目标利益一致 互相帮助 和谐

2、How

（1）Plan阶段

【会议一】收集、制定、调整产品需求表Product Backlog

【会议二】选取部分最有价值的需求，输出Sprint Backlog

产品计划--backlog的样例

迭代backlog的样例

任务长什么样子

（2）Do阶段

每日早会

要精简，不是做工作汇报

抛出问题，不是在会上解决

关注任务，不要扩散

围在一起，站着开

三个问题：昨天你做了什么？今天你将要做什么？你又需要帮助的地方吗？

（3）CA阶段

1、迭代验收

演示成果，收集反馈意见

团队成员，产品关注人参加

会议形式

2、迭代回顾

总结经验教训

效率导向

会议形式

（三）Scrum能达到什么目的，做得到吗?

尽早的持续交付有价值的软件

在这个过程中不断反省调整

选代、筛选排序、每日早会、验收、回顾

三、我们能怎么“敏捷”

（一）为什么要有项目经理

产品经理要关注业务，需要有人专注团队管理

（二）为什么要有需求设计

■产品与执行团队，以及执行团队内部达成一致。沟通需要。

■通过设计验证需求是否正确

■复杂功能分解需要

■这是最容易出问题的环节

（三）三个核心

1、产品需求管理

∴产品经理需要良好的沟通技能

（1）找对人：用户、客户、老板

（2）用户故事

（3）故事挖掘分析

1.痛点真实存在吗

2.价值与代价

长期的产品目标与短期目标

（4）图文确认理解一致

1.嘴巴上说得再好也不及看一眼直接

2.设计的意义（响应痛点）

3.基于场景（用户代入）

4.符合交互设计原则（从上到下，从左到右）

（5）迭代规划最有价值部门

主要的需求的价值、分析已完成

1.价值导向

2.长期规划是否有调整

3.评估工作规模

4.评估技术能力

（6）注重沟通

1.与客户沟通，需求收集、分析、确认，有业务方案说服力

2.与开发人员沟通，它能带来多大的价值，有实施说服力

2、研发过程

（1）研发过程-PDCA

（2）规划设计

选出最有价值优先级最高的需求

把需求拆为任务

做好开发前的一切准备，每项工作具体怎么开展是非常清楚的

1.需求规划、评估

2.功能设计、评审

（3）实施

1.开发、自测

2.集成

3.提测、修复缺陷

4.穿插质量控制，多使用自动化工具

（4）交付-外部反馈

1.联系用户，收集反馈意见，确定下个版本最有价值的需求

2.用户手册

3.版本上线公告

4.培训推广

（5）复盘-内部提升

1.指标导向，效率导向，消除障碍

2.快乐工作的氛围

3.积极主动参与，负面影响大的人早清除

4.落实（master、项目经理职责）

常问：有没有不开心的，有没有想吐槽的，能不能减少缺陷数量

3、团队管理

1.各司其职，利益一致，目标一致：不求人

2.共同管理，排除障碍：和谐（·利益一致，共同制定规则，减少障碍；·有事说事；·看到成绩，指出不足）

3.工作透明，心理有数：互相帮助（·每日站立会：1.昨天做了些什么；2.今天准备做什么；3.遇到什么问题。齐心协力，提升效率）

4.面对面沟通：沟通要求（·项目组内部：1.主动出击，2.就事论事，3.邀请关联人，4.急事，可以当面，就不发微信，5.急事，可以打电话，就不发邮件）

四、结束语

持续交付最有价值的产品

任何东西都可以学习和改进

具体可以采用Scrum框架和方法（PDCA)

正确的事情总是殊途同归