敏捷项目管理

规范期 Norming
成熟期 Performing
组织架构
公开的数据流动
问题解决
团队管理
形成期
定义方向、任务、 期限、规范，启动 会，团建，学习
震荡期
协调情绪、加强沟 通、建立信任、随 需调整、认同方向
规范期
共同目标、信任、 鼓励协作、流程 制定和改进、松 弛有度
成熟期
自我管理、肯定鼓励、 处理突发、关注大局
需要PO澄清期间的问 题
用户故事估算
故事估算方法 依据经验
和其他故事做比较 分解成更小的故事
计划扑克估算 理想日估算
•
按客户价值进行优先排序
•
优先选取能交付最高价值给
客户的
•
让客户参与到优先排序过程
•
在制约下优先交付一组有用
的功能
• MMF(最小可售
单元) Product
Backlog DSDM(优
团队发展 注 意 点
◆ 团队可能一直处于、也可能随时重新进入形成期 -震荡期 -正规期 ◆ 业务绩效、关键人员、大批新人…… ◆ 团队负责人起着关键作用，当ta不再被信任时，团队将持续处于
震荡期，最终的结果是解散 ◆ 每个新人进入一个团队，都将经历这四个阶段， 包括PM自己
在很多项目中，需求分析人员只是从一个角度去 写用户故事，这样往往容易忽略一些需求(故事)， 因为有些故事针对的并不是系统的一般用户。以 用户为中心的设计和交互设计让我们明白在编写 故事前识别用户和虚构人物会有很多好处
50
6
故 事
主题 故事
史诗
产品Backlog特点
产品Backlog的属性
详 略 得 当 渐进明细，文档够用就好 优 先 级 从优先级最高开始开发 估 算 过 的 优先级越高估算的越精确 够 用 就 好 适合自己的，逐渐演进 定 期 梳 理 每次新的Sprint开始前梳理调整
创建用户故事地图
购书消费者
优先级 增强可预见性、 避免镀金 展示进度、促 进技术
Sprint计划会
会议目标 1、明确该Sprint做什么，输出Sprint Backlog 2、足够深入理解需求
参与人员 Team、Scrum Master、PO
议程 1、讨论产品Backlog中高优先级项 2、团队挑选部分作为该Sprint目标 3、分解估算
来源广泛 拥抱变化
范围
快速试错
透
明
时间
快！离用户近！
全民测试 阶段性质 量
质量
敏捷推崇的工作方式
开发项目的复杂分类
需求、技术明确，采用传统项目管理即可 需求、技术都不确定的复杂类型，适合敏捷
预定义过程VS经验性过程
复杂的环境会干扰我们对目标的判断，让我们偏离目标
不断的侦测目标，收益反馈，调整方向，完成目标
业务流程
时间线
配送员
高
管理账户
浏览
购买
支付
配送
注册
图书清单
下单
线下付款
发货清单
退货
登陆
图书详情
收获信息
配送清单
确认购买
商
业 价
修改密码
书名检索
购物车
值
维护地址
支付宝
配送单
退货申请
手机验证
书号检索
修改订单
微信绑定
分类浏览
低
微信支付 信用卡
退货处理 退款
发布1 发布2 发布3
确定 满意条件
估算 故事规模
发布计划
用户故事分解 估算 □ 定义DoD 发布
迭代
□ Splike 迭代计划 开发及测试 每日站会 评审会议 回顾会议
□ Backlog梳理
收尾
回顾会议 感恩游戏 总结经验教训 成功交接 文档归档 行政收尾
敏捷原则-12条准则
我们的最高目标是通 过尽早和持续的交付 有价值的软件来使客 户满意
敏捷原则1
可以按任意 顺序进行
选择 迭 代长度
估计 团 队速率
确定 优先排序
发布计划
确定 发布日期
Sprint特点
容易做计划和承诺
反馈快
产生的错误更少
投入产出比高
检查点多
快速激励和开始
时间盒
时间计划 首先是迭代方式：版本
、固定时间盒 基于WBS和估算的时 间计划 当你遭遇时间倒排时：范围 、缓冲
背后的原则 强制排定
归纳联系 问题、风险、懂了
项目分解
追求“小而美”
哪怕应对的 “排山倒海”
凡事皆可拆
交付
改进
团队
事、人、物
增量式
每次一小步
（快速、试错、风险） （接纳、适应）
功能团队 交付能力、克服划 水、自组织、激活
◆ 药，不可多吃！ ◆ 规范性vs灵活性
◆ 持续改进 ◆ 落实重于制定 ◆ 要找到 试点
基本框架上的因地制宜 遵循但不死板 重视流 程背后的原则 而不是 流程行动本身
用户角色Persona建模
类别 求职者 初次找工作者 裁员受害者 大学生 监控者 工作发布者 建立阅读者
姓名 张三 李四 王二 小朋 小芳
… …
用户故事是什 么
用户故事描述了对用户、系统或软件购买者有价值的功能
一份书面的故事描述
有关故事的对话，用于具体化故事细节 可验收测试，用于表达和编档故事细节且可用于确定故事何时完成
估算：5 story point 计划完成时间：2019.10.01
Independent 独立
Negotiable 可协商
Valuable 有价值
Estimable 可估算
Testable 可测试
集体估算，只有开发人员才能估 算
估算不是承 诺
准确而不是精 确
使用相对 值
避免长时间讨 论
大的故事可分解再估 算
作为XXXX，我想要XXXX，这样我可以XXXX
角色：谁要使用这个功能 功能：需要完成什 么样的功能 价值：为什么需要这个功能，能 带来什么价值
INVEST原则
No.S01
优先级 12
作为：一个卖家
我希望：发布我的商品信息 1、显示名称、规格、价格等属性 2、支持上传图片 3、在线编辑
目的：让更多的买家查找到商品
没有一劳永逸的流程 来自团队意愿 每次 一小步
流程管理
◆ 只相信你有权相信的
开发对测试说，我的代码没bug了…
◆ 风险识别，贯穿始终 ◆ 拓展信息来源，让信息汇向你 ◆ 致命风险，不仅仅是上交 ◆ 两份风险列表，一份不公开 ◆ 悲观心态看项目，乐观心态看团队 ◆ 不再成天救火
风险意识
PART
02
作为一个博客读者，我想设置发布文章的背景图片， 以便于我的读者阅读的时候感受到文章的意境
作为一个博客读者，我想让我的读者对我的文章进行 评价，以便于收集读者反馈，日后改进
作为一个博客读者，我想通过博客发布我的照片，以 便于我的读者们认识我
……
……
估算(故事点) 优先级
8
100
10
80
20
60
30
14
◆ 项目管理的目标是平衡三者的关系，使之达到最佳的效果。
资源 /成 本
范围 /质 量
时间
成本
价值
范围
铁三角有所思
• ◆ 各因素相互 牵制 • ◆ 对需求 的管理是源头 • ◆ 单纯加人是个 “焦油坑 ” • ◆ 时间 总是最易确定的因
素， 也是最易被重视的维 度
• ◆ 要求 克制追求时间 的 冲动 • ◆ 最易伤害：长期质量
PART 01
重新认识 项目管理
目 录 DIRECTORY
PART 02
敏捷型 项目管理
PART 03
敏捷转型 成长之路
PART 重 新 认 识 项 目 管 理
01
如何应对互联网巨变时代
无处不在的项目
项目管理做什么
交付：范围、时间、质量····· 组织：团队、氛围、能量、文化、目标······
敏捷软件开发优势
快速交付 1-4周迭代结束即可 交付可运行的软件
质量更好 持续集成及频繁测试 保证代码质量更高
降低风险 短周期迭代持续反 馈，提高预见性
持续改善 迭代结束后进行回顾 频繁检查团队动向
适应变化 小步快跑，快递验证 产品需求及调整方向
满意度高 高ROI的需求快速交付 早期实现商业价值
敏捷型项目管理特点
即使在项目开发的后 期，仍欢迎对需求提 出变更。敏捷过程利 用变化来为客户创造 竞争优势
敏捷原则2
经常性的交付可以工作 的软件，交付的间隔可 以从几周到几个月，且 时间间隔越短越好
在整个项目开发期间， 业务人员和开发人员 必须每天在一起工作
敏捷原则3
敏捷原则4
敏捷原则-12条准则
要善于激励项目人员， 给他们所需的环境和支 持，并相信他们能够完 成任务
项目管理思维
目标管理 全局眼光 项目分解 流程管理 风险意识
目标管理
◆ 点头之前多问几个“为什 么” ◆ 期望管理：结果 VS 过程 ◆ “奇怪”的期望 ◆ 成功交付，是唯一的目标 吗？
目标管理
专职项目经理
① 项目经理直接入驻项目，深入了解项目日常情况，在项目中因地制宜实 施项目管理方法和流程。作为项目经理，一方面对各版本项目的成功交 付负责，另一方面也需关注团队的长期健康成长。
敏捷型的项目管理
如何应对互联网时代管理
什 么 是 敏 捷？
敏捷（Agile）是一种关注价值、消除浪费、 以人为核心、迭代、循序渐进的开发方法。
价值 变化
效率 灵活
用户 团队
透明 检验 适应
传统项目常见模型
交付周期长 6-10个月甚至更长
传统开发面临的问题
软件质量差 赶上线而牺牲质量
团队士气弱 死亡行军及不关注结果
团队内部和各个团队 之间，最有效的沟通 方法是面对面的沟通
可工作的软件是衡量进 度的首要指标
敏捷过程提倡可持续的 开发。项目方、开发人 员和用户应该能够保持 恒久、稳定的进展速度
敏捷原则5
敏捷原则6
敏捷原则7
敏捷原则8
敏捷原则-12条准则
对技术卓越和好的设计 的持续关注有助于增强 敏捷性
尽量做到简洁，尽最 大 可能减少不必要 的工作 这是一门艺 术
最佳的架构、需求和设 计出自自组织团队
团队要定期回顾和反省 如何能够做到更有效， 并相应的调整团队的行 为
敏捷原则9
敏捷原则10
敏捷原则11
敏捷原则12
Hale Waihona Puke Baidu
团队问题
关于一个问题，各种讨论，但迟迟没有定论
除了测试和运营，团队很少人日常使用自己的产品
重要问题，很少有人提反对意见 邮件中打仗
不想再提，因为提了也没用
先级列表)
用户故事排序
价值优先级排序方法
Simple scheme MoSCoW 100-Point
Kano Analysis
类似于传统的系统需求 全程可视化的功能列表 按优先级排序的 每个Sprint开始时调整优先 级 由PO准备和维护 包含验收测试标准 估算：故事点
建立产品Backlog
Backlog 条目
敏捷宣言
个体和交互 可工作的软件
客户合作 响应变化
胜过
流程和工具
胜过
面面俱到的文档
胜过
合同谈判
胜过
遵循计划
虽然右项也具有价值，但我们认为左项更具有更大的价值
敏捷项目阶段
立项
建立愿景 商业论证
启动
项目章程 工作协议 人物角色 □ 初步Backlog 高层次估算 □ 产品roadmap 用户故事地图
项目管理定义
将知识、技能、工具与技术应用于项目活动，以满足项目的要求 ——PMBOK指南
在项目活动中运用专门的知识、技能、工具和方法，使项目能够 在有限资源限定条件下，实现或超过设定的需求和期望的过程 ——百度百科
项目管理五大过程组
启动
千里之行 始于足下
规划
运筹帷幄 决胜千里
执行
言出必行 行必结果
明明觉得有问题，但懒得说
你的团队还好吗? 各种病假事假迟到早退
有人绩效很差，但没什么问题 群里po个信息，没人理，全天没几条信息
会越开越多，越开越长，但决策越来越难
开会就是各自开小差
团建没几个人参加
团队建设四个阶段
相对独立
凝聚力
冲突
依赖于领导者
形成期 Forming
确定方向
振荡期 Storming
VS
敏捷思维
是流程的问题 系统思考，优化整体 快速交付和高质量互为手段、目的
针对流程进行考核 清除员工面临的障碍， 开发员工
关注价值 频繁的预测才是可依赖的方 法
小而灵活才是美
为什么要敏捷
为啥要变化呢？ 不能一开始多花点力气，想明白呢？
◼ 细节无法提前全都想明白 ◼ 世界变化太快，原本有价值的东西，可能会变得不那么有价值了 ◼ 不确定性太多，可能连用户自己都没意识到自己到底想要的是什么
监控
审时度势 沉着应变
收尾
慎终如始 如履薄冰
项目管理五大过程组
项目管理=重要通用能力
责任心
客观开放
执行力
觉察力 感知力
全局观
自驱力
项目管理的常量和变量
时间
范围 成本
生命 周期
产品 类型
团队 阶段
经典项目管理铁三角
时间
计划
◆ 所谓“铁三角”，指的是三者中任意一方的变动都会对其 他二者产生影响。
② 项目的成功交付 是指根据项目实际情况所需达成的重要交付目标 ,包括 但不限于时间、范围、质量等因素，通常是这几项因素的综合结果。
③ 团队的长期健康 成长是指随着产品各版本的推出，团队在执行力、协 作氛围等方面的日渐增强，以及团队日益形成的自我组织和自我管理 .
全局眼光
低头抬头 前后上下通吃
假象演绎 想象沙盘
按时发布低 技术债务增多无法发布
沟通效果差 文档化的沟通不及时
进度延期久 计划和估算全靠拍脑袋
传统和敏捷有什么区别
传统思维VS敏捷思维
传统思维
是员工的问题 优化各部分的工作 快速交付和高质量意味着多花钱 针对个人进行考核 激励并管理员 关注计划 为了更好的预测，做全面的分 析 大而集中能提高效率