《我们敏捷了吗?-敏捷化项目管理》学习笔记

一、什么是敏捷

(一)是否遇到了这些问题

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

(二)怎么解决

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)

正确的事情总是殊途同归

发表评论

电子邮件地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据