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