一、什么是敏捷
（一）是否遇到了这些问题
■产品上线才发现大部分功能不是客户想要的
■总是无法及时响应客户变化的需求
■做的甘特图计划非常精细，但就是实现不了
■团队成员都是高手，但是开发效率上不来
（二）怎么解决
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)
正确的事情总是殊途同归