[PM]敏捷及Scrum

洋葱圈图

就软件产品和项目领域而言（包括互联网，当然还有其他领域），敏捷其实就是一种方法论，无非就是这种方法论较其他而言，相对节奏更灵活，信息更透明，产出更高效，风险整体更小，对各种反应更快，当然对人的要求也更高。

没有对比就没有伤害，关于传统项目全生命周期，言简意赅的说个我曾经作为PM项目经理来跟进的项目交付方法论。背景为财富五百强TOP10的某国企，项目体量千万级别，周期8个月左右。全生命周期流程为：1项目需求挖掘→2项目立项申请→3项目投标竞标→4项目组成立→5项目规划（颗粒度到周）→6项目实施（每周周报+周期成果演示+需求变更+提交变更流程+反复研发+测试+再汇报）→7项目阶段性交付验收→8重复项目实施*N→9项目验收→10项目转运维。

作为传统项目实施方法论来讲，需要PM的前瞻能力值基本跟上帝平级，望眼欲穿到一百天以后是常有的事情，那么问题来了，随着外部环境变化，周边政策变化，以及信息化高度发达的今天，诸如此类的项目真的可以实现信息化先进生产力吗？

答案是需要思考的。但从概率角度来讲，传统方法论较为低了一些。

而敏捷套路用我所理解的一段话概述即为：驱动自组织跨职能的人员团队，用高频率短周期的持续迭代交付方式，快速得到有效用户反馈，并针对过程和结果进行持续优化和改进，由产品负责人掌控整体方向，由敏捷教练SM来引导方法论，实现整个团队的高度信息透明+高效沟通，用渐进明细的方式来交付最终成果。

敏捷价值观▼

（洋葱圈最里层）

个体与互动高于流程和工具

可工作的软件高于详尽的文档

客户协作高于合同谈判

响应变化高于遵循计划

敏捷原则▼

（洋葱圈第二层）

也是衡量方法论是否为敏捷的标尺

-目标是满足客户

-时刻拥抱变化（后期也一样，技术支持重构）

-持续交付（短周期）

-跨职能相互合作

-充分信任激发个体

-面对面交谈

-可用的软件是首要度量标准

-可持续开发

-不断完善追去卓越

-简洁，够用就好

-自组织团队

-及时复盘

敏捷实践▼

（洋葱圈第三层）

最后基于价值观和原则之上的第三层洋葱圈，就是各实践通过敏捷技术百家争鸣的区域，这里面有各种各样的方法，有适用于大型组织的SAFe，有适用于单团队单迭代，又可以融入组织级方法里的Scrum、XP等，有适用于整合起来按需使用的敏捷方法， 如用户故事、重构、持续集成等等。

说Scrum之前需要说一个承载需求的载体，也是实践其中之一，即用户故事。可以理解为说白话的需求说明书，核心是从用户的角度出发，用一句话在卡片上来描述需求：我作为xx角色通过实现xx功能从而达到xx价值，卡片背面描述该故事具体的测试场景，用这个方式来描述需求对于用户、产品负责人Product Owner（以下简称PO）、敏捷教练Scrum Master（以下简称SM）、研发团队（以下简称开发Team）都比较浅显易懂，从而使信息更透明。而用户故事也是分颗粒度，分别是史诗级故事＞特性故事＞具体故事＞围绕故事拆分出来的任务Task，整体团队是从充分理解用户故事的角度来开展具体任务工作，从下往上，逐层汇集。

进入正题，开聊Scrum▼

下面从最流行的方法论Scrum说起，一句话描述，就是3个角色、3个工件、做5个活动。（还有5个价值观，参考以上就好）

3个角色即PO、SM和开发Team。

3个工具即得产品待办事项清单、迭代待办事项清单、可交付的产品增量。

5个活动即迭代执行、迭代计划会、每日站会、迭代评审会、迭代回顾会。

整体流程如下

1-团队组建，宣扬方法论

目的：组建好用的团队，灌输结果导向以及敏捷方法。

成事在人。敏捷方法里对于个人和团队的技能要求有三点，一是跨职能，即在懂研发的基础之上，可以跨到测试甚至设计甚至更多；二是主观能动性要高，都是为了解决问题而不是卖骚秀工作量；三是认同结果导向，即我们用此方法，可以更快更高质量的输出可用产品。

2-创建产品待办事项列表

目的：输出有排序的，有故事点估算的用户故事列表。

此环节里PO进行产品梳理，排序现有用户故事，同时帮开发Team理解需求。开发Team根据理解的用户故事来进行故事点估算，产出可输入至迭代计划里的用户故事。SM来绘制燃尽图，表示产品进度，在每个迭代后进行更新。

备注：用户故事也分颗粒度大小，排序就是优先级越高的故事越具体。

3-通过迭代计划会议产出【迭代周期+事项列表】

目的：通过会议产出本轮迭代的任务。

迭代周期：根据交付要求进行评估后产出产品迭代周期，一般为15天-30天不等。周期太长不灵活。

PO与团队从产品待办事项列表中选取待完成的用户故事。开发Team负责将这些用户故事拆分成任务，给出任务估算，任务一般可在8小时内完成的，可量化。SM绘制针对迭代的可视化图，表示迭代进度，在每个立会进行更新。最后将本轮迭代的任务放置在To do（准备做）一栏。

4-通过每日立会【沟通及领取、交付任务】

目的：保证整体团队每天高频的沟通，了解每个任务的进展及大家进度情况。

整体团队每天花15分钟快速的勾兑昨天做了什么、今天准备做什么，需要什么问题。

每个人主动在To do（准备做）一栏中的选取今日要完成的任务放入Doing一栏并且开工，第二天立会继续按此勾兑，同时将已完成的任务放入Done（完成）一栏

备注：只有PO、SM、开发Team能发言，其他人旁观，有事儿单独聊。

5-通过评审、回顾会议【评审本次迭代的成果和输出改进项】

Scrum方法论里是两个会。

评审会是邀请客户等利益攸关者一起针对本次迭代的成果进行评审（可交付的产品增量）。团队进行演示，PO来讲解整体产品情况。

回顾会是团队内部针对本次迭代内发生的各类做的好的、可以改进的、存在问题的输出改进项， 改进项作为单独的任务为下一轮迭代做输出，也就是持续改进。

6-会后更新产品待办事项列表

整体过程中：

SM需要确保开发Team不受外界干扰，作为敏捷教练更多的是确保会议执行、确保大家理解方法、遵循时间盒规则。

PO把控整体方向及对接外部需求，只有PO可调整产品待办列表优先级，另有权中途取消迭代。

开发Team负责任务的同时还需要遵循敏捷的核心方法，同时按需运用如持续集成、自动化测试、结对编程等组件级方法。

Scrum流程图

（附事项+角色+负责事务）

Scrum思维导图

最后总结一下精华：

前期贴合需求，浅显易懂的说明（用户故事）

价值观一致(褒义方向)

自组织跨职能团队(人&技能)

信息发射源(可视化看板+燃尽图)

高频短时沟通(每日立会)

高频迭代及优化机制(持续改进)

周期性评审及回顾(交付增量＋下一轮改进)

始终认为，敏捷只是达成目标所使用的方法，而Scrum、XP等诸多实践只是提供了一种验证过的可行的参考，而是否适用于本团队，以及团队里每个人具备的技能和方法认知，还需要管理者自行斟酌和思考。

永远不是为了敏捷而敏捷，而是为了更高效的交付更高质量的可用产品。通往罗马之路放眼望去遍布脚下，选择以及实践出最适合自己的为好