敏捷转型打造VUCA时代的高效能组织（王明兰著）思维导图模板

6、如何带领Scrum团队

组建Scrum团队

说明

Scrum团队由产品负责人、开发团队和Scrum Master组成

Scrum团队是跨职能的自组织团队

自组织团队自己选择如何最好的完成工作，而不是由团队外的人指导

跨职能团队拥有完成工作所需的全部技能，不需要依赖团队以外的人

一个团队需要哪些职能，应视团队自身的需要而定，只要不依赖团队以外的人完成工作即可

跨职能有两个维度

跨工种：如跨越产品、架构设计、用户体验设计、开发、测试及运维等

跨领域：如跨前端、后端或中间件

为什么要跨工种

不同工种组成一个团队，大家群里群策，没有部门之间的交接，不依赖与其他部门或团队就可以完成一个产品，这种方式无疑是最高效的；

对于涉及多个团队协同开发的大型产品，可能做不到一个团队能够独立完成一个产品，但在组建团队时，要围绕产品的价值流，以特性为单位组建Scrum团队，确保每个Scrum团队囊括了交付一个产品特性的全部工种

为什么要跨领域

康威定律：任何组织在设计系统时，其设计的系统架构就是该组织沟通结构的写照，即产品必然是其组织沟通结构的缩影

要什么的系统就要搭建什么样的团队

如果团队分成前端、DBA、中间件团队这张筒仓式的职能部门，将会产生筒仓式的软件架构

如果要交付一个潜在的可交付产品增量，就需要跨越各职能部门，团队与团队之间的交接和等待，就像一场接力赛，这样的速度无法满足互联网时代激烈的竞争要求

当组织要改变一个产品特性时，可能会牵动每个层次的整体架构的变动

在按职能分工的组织里工作，各团队只能把自己的那部分工作做最好，控制不了的只能搁置一旁，而那些被搁置的工作，却是能够连接、集成整个系统的关键部分，从而造成整个产品交付效率低下

开发团队的规模

Scrum提倡的是7±2模式，即5~9人规模

不要纠结于这个数字，重要的是团队能够拥有完成产品增量所需的所有技能，同时保持高效率的协作

人数较多的团队，如果发现团队出现了信息断层，需要让团队协作更紧凑，可以考虑拆分为两个团队

保持团队的稳定性

团队能保持长期稳定当然是最好

即使团队不稳定，也要尽力保持Scrum团队的正常发展

Scrum团队尽力避免身兼数职的成员加入，尽量避免一个人在两个团队中同时肩负职责

正确理解关键角色：Scrum Master

Scrum Master与项目经理的区别

角色定义不同

两个角色是定义在不同的流程和价值观里的

当一个人身上的两个角色博弈时，失败的总是新角色

避免项目经理或者团队组长兼任Scrum Master，以免其依旧保持原有的项目管理方式和思想

传统项目经理的职责被Scrum Master、产品负责人、开发团队所分担

产品定义的职责由产品负责人来承担

项目计划的职责由产品负责人和开发团队共同承担

项目执行和监控的职责由开发团队承担

团队管理的职责，通过Scrum Master引导团队自管理完成

管理方式不同

项目经理：命令下达式，整个团队以项目经理为中心运转，大家信息不对称，不透明，项目经理掌握着信息的全集，团队成员基本上只掌握自己的任务以及与自己任务相关的信息

Scrum Master：1、除了维护Scrum流程没有其他权力，对团队没有发号施令的权力；2、通过引导的方式促进团队彼此沟通协作，而不是以某个人为中心；3、如发现团队成员之间或团队与外界出现了协作障碍，他会引导大家去除障碍，确保协奏的紧密性。4、团队成员通过自组织实现协作，信息交换是对称和透明的，不需要以某个人为枢纽

合格的Scrum Master通过问问题的方式引导团队思考，并由团队自己做决定

Sprint目标未达成，大家认为是什么原因呢？

那么大家认为咱们需要采取什么措施改进呢？

大家觉得我需要在哪方面帮助大家，才能达到更好的效果呢？

Scrum Master的职责

过程权威：负责维护Scrum团队的流程，确保团队遵守工作协议，指导团队践行敏捷的价值观、原则，以及实践Scrum，是流程负责人

牧羊犬：负责保护团队不受外借干扰，让团队将精力集中在每个Sprint的交付上。拦截外界干扰，让团队专心工作

清道夫：负责清扫妨碍团队生产效率的一切障碍，要引导团队自管理，由团队成员自己清除障碍，当团队自己搞不定时，SM将责无旁贷

教练：观察团队如何运作Scrum，帮助团队提升敏捷的实践能力，改变团队的思维模式，从而提升团队的整体效能。辅助产品负责人开展与开发团队相关的活动，如梳理Backlog等，引导团队持续优化产品，实现产品的最优产出；

服务型领导：SM是典型的服务型领导，服务于团队、产品负责人及组织

变革代言人：对与团队周边的人和组织产生推进变革的作用；组织需要建立敏捷转型委员会等机制，为SM推进和影响组织变更建立顺畅的通道

Scrum Master兼职怎么办

需要注意几点：

1、为行驶SM职责分配充裕的时间，要预留足够的时间来学习和练习新方法。应保证投入30%~50%的时间，以确保团队持续改进

2、角色切换时，明确此刻“我是谁”。在同一项活动中，尽量少做角色切换，非要转换时，明确自己的身份后再提问/发言等

3、Scrum Master要被正式任命，并在绩效目标里体现其工作职责

做一名合格的产品负责人

产品负责人的职责

建立产品愿景

与内部和外部利益干系人、团队一起规划产品发布

与客户、用户等外部利益干系人和企业内部利益干系人协作，获取他们的需求和反馈，在Scrum团队里代表内部利益干系人的声音

在Scrum流程中，与开发团队、SM密切合作交付产品

管理产品待办事项列表，是产品待办事项列表的唯一负责人，管理的内容包括：

清晰的表述产品待办事项列表，确保产品待办事项列表对所有人是课件的、透明和清晰的

对产品待办事项列表进行优先级排序

保证Scrum团队下一个迭代要做的工作是确定的且足够细化的

确保Scrum团队对产品待办事项列表有足够深的了解

对于一个产品来说，只有一个产品负责人

SM和产品负责人都是企业敏捷转型的关键角色，如果企业对产品负责人的角色有正确理解，让其顺利行驶其职责，那么对敏捷转型有关键作用

企业管理层需要为产品负责人提供如下支持

尊重产品负责人的角色定义，对产品负责人充分授权

常踩的坑：企业虽然任命了产品负责人，但管理层习惯对产品的需求直接下达命令，对发布计划指手画脚，导致产品负责人无法决定产品的范围和时间

设立专职的产品负责人

让团队正确理解产品负责人的角色

错误理解：1、产品负责人是SM和开发团队的领导；2、产品负责人和SM都是开发团队的领导

产品负责人需具备的能力

1、与产品相关领域的知识能力

2、制定宏观愿景和进行长期规划的能力

3、沟通和谈判能力

4、洞察能力和创造能力

5、执行能力：带领团队将产品愿景落地执行

团队工作协议

什么是工作协议

工作协议是由团队共同商议，达成一致遵守的一组规则、纪律和流程的组合

团队在工作协议的约束规则里工作

工作协议必须是可执行的，并有反馈机制来闭环，否则就容易成为一纸空文

工作协作是团队自己设定的，SM或者团队管理者可以引导团队制定工作协议的过程，但是达成哪些工作协议由团队自己商定

敏捷团队刚开始组建时，是制定工作协议最好的时候。

如果是团队从半途开始向敏捷转型，则转型一开始就需要制定工作协议；或在第一个迭代结束时，根据这个迭代暴露的问题制定工作协议

如何制定工作协议

需要三个工具

白板

马克笔

报事贴

步骤如下

开场：SM跟团队解释工作协议是什么以及制定工作协议的目的，列举几个现实工作中工作协议的范例，如：

每天站会9点开始，迟到者做10个俯卧撑

CI Build失败报警后，要马上修复BUG

任务板要在每日站会前更新

发散：每个人对工作协议提出自己的建议，并用报事贴默写（避免影响彼此思路）出来，一张报事贴提议一条工作协议

收敛：收集报事贴，贴到白板上，大家聚焦到白板跟前讨论，每人介绍自己提议的工作协议，然后每个人对大家提议的工作协议投票，将投票最多的3~5条工作协议作为团队共同遵守的工作协议

承诺：团队工作承诺遵守这几条工作协议，如果有人违反其中任何一条，其他人要及时提醒ta

可视化：团队达成的工作协议最好用大字写在报事贴上，然后张贴在团队的工作区域或任务板上，让大家每天抬头可见，起到实时提醒的作用

工作协议要与时俱进

Scrum是一种经验式的过程，其流程和规则会根据团队的需要而制定，因此，工作协议也会随着团队需要而改变

把握Sprint节奏

设置合适的Sprint长度

选择以周为单位

每个独立交付产品的团队，最好单独定义Sprint长度，而不是整个公司或部门一刀切

对于一个项目有多个团队协同交付产品的情况，大家要保持同样的Sprint长度，既方便跨团队计划和对其交付节奏，也让每个团队有共同的语言

现在使用2周长度的Sprint团队比较多

如果产品负责人无法提前2周预见需求，业务变化频繁，可考虑缩短Sprint周期

Sprint周期长度也取决于团队的工程能力，对于没有任何自动化集成、自动化测试和自动化部署的“三无”团队，2周经常不够，方法：

可延长周期到3~4周，将工程实践任务纳入Sprint Backlog，确保迭代交付特性的同时团队工程能力得到提升

保持迭代周期不变，调整DoD，调整为在当前周期下产品可以达到的程度，但这样势必会造成下一迭代工作量加重

迭代不是永远都需要有的，随着团队敏捷成熟度提升，当团队能够按需发布，甚至每天可发布多次，即达到流式开发、持续交付的程度，便可抛弃迭代周期的框架，迭代长度只是作为团队计划的节奏，不再作为交付的节奏

不要推迟Sprint

只有固定Sprint时长，团队才会有紧迫感

只有固定Sprint时长，发布才具备可预测性

只有固定Sprint时长，才可以减少团队运行Scrum的事务性成本

按固定节奏工作，预留Sprint计划、评审、回顾等活动的时间并按周期预定好会议室

保证大家的时间管理是有节奏的，从而减少协调和调度的事务性成本

DoD：怎样才算“完成”

DoD的范围有多大，本质上反映了组织的敏捷成熟度，DoD的范围越靠近上线的最后一步，说明组织的敏捷成熟度越高

DoD也体现了组织敏捷转型范围，产品发布到用户手里需要做的所有工作都应该在DoD中

那些承担Scrum团队未完成的工作的部门，被称为：Undone部门，这些部门正是敏捷转型未来需覆盖的目标

每个Sprint不断积累的未完成的工作，不仅推迟了产品的反馈周期，蕴藏的缺陷也不断增加，因此，未完成的工作越少越好

团队尽量将产品的质量反馈闭环控制在一个Sprint之内，不要推迟风险暴露的时间，如性能测试等工作

做好启动第一个Sprint的准备工作

Sprint0阶段

给Scrum团队做敏捷导入培训

组建Scrum团队，任命SM和产品负责人

管理层跟团队沟通Scrum和敏捷转型目标，确保团队对敏捷没有抵制情绪

团队就工作协议达成一致

团队准备开发和测试环境、服务器、硬件等资源

团队准备产品Backlog，尤其是第一个Sprint的用户故事

团队就估算的基准故事达成一致

团队做产品的最小架构设计

Sprint0推荐做法：拆分出一个最小的用户故事，在Sprint0中实现，这个最小的用户故事作为一个探针，验证为Sprint1做准备的那些任务是否已经完成

承诺Sprint目标

Sprint目标是当前Sprint中产品Backlog所要达到的目标，为开发团队提供指引，使团队明确构建产品增量的目的

Sprint目标在Sprint计划会议中确定

没有Sprint目标的团队，经常会遇到以下问题

在Sprint计划中计划了一堆零散的用户故事，互相之间没有联系，导致团队不清楚运行这个迭代的意义，而只盯着那些零散的小用户故事。Sprint目标能够帮助团队聚焦，依照Sprint Backlog背后的目的而做，而不是纯粹为了实现Sprint Backlog中的用户故事

在做Sprint计划时，如果没有设定Sprint目标，团队只对整个Sprint Backlog作出承诺，会让团队没有任何弹性空间。现实的产品增量交付过程中总会碰到Sprint计划中意想不到的困难和未知的风险，这些都会导致Sprint目标无法达成，Sprint目标为开发团队在Sprint中需要实现的功能预留一定的弹性空间，也就是说，可能会有个别用户故事没有完成，但是并不影响Sprint目标的达成

在Sprint执行过程中，有时候会涌现新的用户故事，或原计划的用户故事不需要在这个Sprint完成，这时，Sprint目标能够帮助产品负责人和团队判断用户故事优先级，决定取舍

夯实Sprint计划

Sprint计划的流程

Sprint计划的输入有：

为Sprint准备的高质量的产品Backlog

一份高质量的产品Backlog对Sprint计划相当重要，产品负责人维护高质量的产品Backlog

就绪的定义（DoR），定义了产品Backlog可以进入Sprint计划的前提条件，依据团队具体情况定义

完成的定义（DoD），定义了产品增量做到什么程度算是完成

团队的历史速率

在Sprint结束时由实际完成的所有用户故事点数之和来度量

速率的统计有两个作用

1、让团队对每个Sprint的产出量做到心里有数，这样能够做出靠谱的预测

2、速率是发布计划的重要输入。比如你的产品当前版本的Backlog有150个故事点，而团队每个Sprint的平均速率是30个故事点，可预测出这个版本大概需要5个Sprint来完成

团队做Sprint Backlog的可用时间

产品负责人提议的Sprint目标

Sprint计划的输出有：

团队承诺的Sprint目标

Sprint Backlog

Sprint计划的参与人有：

产品负责人

团队成员

Scrum Master

开展Sprint计划会议的步骤

产品负责人陈述Sprint目标，讲用户故事

Who：用户是什么角色

What：完成什么活动

Why：达成什么目的

How：具体怎么做，如果有业务流程图、线框图、参考规范或标准等，也需介绍给团队

验收条件：做到什么程度算完成

产品负责人澄清产品需求

就Sprint目标及每个用户故事做现场解答，确保团队每个人都用户故事都有一致的理解

团队估算完成用户故事所需故事点数

团队选取Sprint Backlog，调整Sprint目标

依据团队历史速率以及对完成用户故事所需点数的估算，按照产品Backlog的优先级，选取用户故事，作为这个Sprint的Backlog

根据选择的Sprint Backlog，团队审视产品负责人提议的Sprint目标施放可以达成，如果Sprint Backlog范围超过了Sprint目标，团队应与产品负责人协商，是否应该调整Sprint目标

拆分任务

每个任务的粒度争取在一天之内（任务越大，其中蕴藏的风险可能越多，团队在探讨如何把任务拆小的过程中，会暴露出实现用户故事的风险）

任务拆分也不能走极端，拆的太小，如0.5小时、1小时等，以免额外增加管理成本

判断Sprint Backlog是否达到产能上限

如Sprint估算超出Sprint的可用时间，不管团队是否愿意挑战，应该尊重团队的决定，如果团队不愿意挑战，则需要从Sprint Backlog中取出一个或几个用户故事

承诺目标

Sprint计划会议结束前，SM需要问大家对这个Sprint是否有信心，从而确保每个成员为达成Sprint目标做出承诺

高效征求意见的方法-五指拳投票

团队可以将Sprint Backlog的用户故事和拆分的任务卡放到任务板上，作为Sprint第一天启动的站会输入

避开每日站会的常见误区

每日站会是团队每天自我检查和调整的机会

时间误区

站会不是每天开

总是有人迟到

流程误区

只动嘴，不更新任务板

啥都谈，就是不谈障碍和风险

僵化站会的三个问题

领导力误区

团队向Scrum Master汇报

Scrum Master给每个同事分配任务（SM应鼓励团队成员主动认领工作任务，积极发挥团队的主观能动性）

团队以外的人到站会上指手画脚

无论是产品负责人还是部门主管，都尽量别到站会上来

充分利用产品的反馈环：Sprint Demo

什么是Sprint 评审

Sprint 评审（也叫Sprint Demo）是对产品进行检查与调整的反馈环

Sprint评审会一个非正式会议，并不是一个进度汇报会议，目的是为了获取产品的反馈（检视所交付的产品增量并按需调整产品的Backlog）

Sprint评审会召开时间：Sprint结束、Sprint回顾会议之前

Sprint评审会议参与人：团队、产品负责人、产品的利益干系人（包括客户、投资人、用户代表等）

谁来演示：由参与用户故事开发和测试的同事来演示

Sprint执行过程中，每做完一个用户故事就及时找产品负责人验收，有问题可以立即调整

常踩的坑：只是演示，没有利益干系人体验产品的环节（最好让参与者自己体验产品）

让Sprint回顾成为团队改进的发动机

Sprint结束时团队做改进和调整的活动有两个：

对产品的改进和调整（Sprint评审会议）

对团队工作方式的改进和调整（Sprint回顾会议）

什么是Sprint回顾

1、哪些地方存在问题，需要改进；2、哪些地方做得好，需要保持；3、改进措施

SM需要为回顾会议其创建一个轻松的环境，让大家能够畅所欲言

是Scrum团队自我改进的工具，由团队决定是否需要邀请团队以外的人参加

团队以外的人以观众身份参加，不可发表自己的意见，如果参会者有意见，可私下与SM沟通

2周的Sprint，2小时就可以开完一个高效的Sprint回顾会议

Sprint回顾的流程

SM明确回顾会的目的，避免大家都回顾会有不同的理解（不是总结会，也不是给领导汇报的总结）

Sprint回顾是对这个Sprint过程中的团队、对外关系、过程和工具这几方面进行检视，但不限于这几方面

找出这个Sprint做得好的地方和做的不好的地方，决定改进措施，从而让团队持续改进

步骤

1、开场，SM需覆盖以下内容

介绍会议的目标和规则，以及回顾的工作协议

介绍会议议程

介绍回顾会议以什么方式开展，回顾的范围是什么（如工作流程、团队之间的协议）

最重要的是要创造一个开诚布公的场域

回顾的基本原则：不管我们发现了什么，我们理解并且相信，每个同事在其已知的知识、技术、能力、资源以及当下所处的环境下，付出了最大的努力。这样的原则可以为团队创造尊重、互信的气氛

Sprint回顾的基本原则、议程、工作协议、回顾范围都可以被可视化到墙上，以营造一个开放的公共场域

2、收集数据

1、团队的速率

2、Sprint燃尽图

3、版本燃尽图

SM带领团队解读数据，让大家对团队的交付情况有共同的认识

这个Sprint没有完成的目标

目前的速率低于最近的几个Sprint

按照现在的速率，从版本燃尽图上能看到我们将推迟一个月发布版本

这个Sprint的前3天，燃尽图上Sprint Backlog没有一点燃尽，导致我们后来几天加班赶进度，最后到Sprint结束的时候也没有完成目标

3、产生改进意见

头脑风暴的框架SSCC

Start：哪些时间应该开始尝试

Stop：哪些问题或者时间应该立即停止

Continue：哪些现有的实践应该继续保持

Change：哪些情况应该改变

每个提议采用报事贴书写，以免互相影响思绪

4、决定改进措施

改进意见要放到Sprint中，团队边交付产品边改进

团队必须对改进意见缩小范围，以免实施太多的改进影响正常的产品交付工作

改进措施分两类

新的实践、规范或共识，不需要作为一个具体任务来落地实施

需要团队完成的一个具体的任务，比如自动化测试这种长期任务，需分解到Sprint里来执行，并在每个Sprint结束时进行检视

5、收尾

对大家花时间共创一个美好的Sprint回顾表示感谢

拍照作为历史记录存档

将改进措施报事贴放到任务板上，用来跟踪进展

做一个关于回顾的回顾，帮助团队在下次回顾中做得更好

7、用看板加速价值流动

价值流映射

为什么要映射价值流

影响整个上市周期时间的价值流动效率的关键因素是什么？

价值流图是一个简单有效的工具，能够帮助团队行程以价值的视角来观察和思考流程，分析价值流动过程的每个增值和不增值的环节

如何衡量价值流动的快慢呢？

流动效率=增值活动时间/周期时间*100%

增值活动时间=价值流程过程中所有增值活动所耗费的时间之和

非增值活动时间=价值流程过程中所有非增值活动所耗费的时间之和

周期时间=增值活动时间+非增值活动时间，即从提出需求到发布的整改过程所耗费的时间

通过流动效率可以判断价值流中的浪费情况

很多团队只关注开发环节的效率是远远不够的，必须关注全价值流的效率

缩短周期时间可以分两步走

通过流程改进、组织调整等方法，减少等待、交接等非增值活动的时间，比如组建跨职能团队

在第一步基础上，提高团队工作效率，缩短增值活动时间，比如导入工程实践以提升团队的开发、测试和运维效率

如何做价值流映射

团队的价值流，应由团队成员共同识别并达成共识

最终定稿的价值流应该是每个成员都认可的

无论是哪种产品规模，价值流需要反映真实的价值流动过程，因为价值流映射的团队共创的

知识工作领域，价值流映射要简单得多，只需4个步骤

1、分析工作项（交付价值的单元）类型

2、列出选定工作项从诞生到交付的各个环节

3、分析哪些环节是增值环节，哪些是非增值环节

4、估算每个环节的耗时

5、将以上步骤的分析结果绘制成价值流图

通过价值流图可以达到以下目的

让团队对产品真实的价值流达成共同的认识和理解

让团队对浪费环节有明确的理解，对价值流动效率有量化认识，并将其作为驱动改进的起点

为下一步设计看板系统提供输入

看板分级

说明

由于看板方法是以价值流为中心的工作方式，所以看板方法里没有团队的概念，而是以价值流为单位建立看板。

使用看板的可以是一个团队，也可以是多个团队，看板的范围取决于价值流的范围

依据价值流的范围，看板可分为两级：团队级看板、产品级看板

团队级看板

由一个小团队所拥有的看板

这个小团队可能是跨职能团队，也可能是纯粹的职能型团队

对于跨职能团队来说，他们的看板管理是端到端的价值流

一个系统中各环节连接的部分，往往是上下游的交界处，也是等待时间最长、浪费最大的地方

只有对整个系统建立全价值流并应用看板方法，才能够实现系统级优化的效果

常踩的坑：很多企业都只在价值流的一部分应用看板方法，常见的应用起始点是开发环节，而整个价值流的瓶颈未必是开发环节

产品级看板

产品级看板上流动的是特性级大颗粒需求（即产品经理、版本经理及利益干系人所关注的需求）

团队级看板上流动的是由产品级看板拆分出去的小需求，一般情况下，一个完整的特性级需求不需要拆分到多个团队中去，而是由一个相应的特性团队完成即可；相反，如果其中有的团队是组件团队，则需要将需求拆分到多个团队协作交付。

产品级看板由负责端到端价值流的人来管理，在很多企业里是产品经理、版本经理这样的角色

团队级看板的需求状态如何被反映到产品级看板中呢？--通过父子需求的级联关系实现

对于几十人至几百人的规模，最好使用电子看板以提升管理效率

团队级看板属于团队级敏捷，产品级看板属于产品级敏捷

服务级别及处理策略

服务级别及延期成本

延期成本：按期交付所产生的财务成本

延期成本是产品开发领域最值得量化的指标

服务级别

从延期成本的角度来分析，服务级别有4种

加急类：产生的价值或损失极其重大，而且影响即刻产生，或在某个时间窗口内迅速产生影响的工作

固定交付日期类：在到达截止日期后价值或损失迅速上升，而在截止日期到达前交付不产生价值或损失的工作，如电商6.18活动

普通类：价值或损失随着时间线性增长，没有特定的截止日期，早交付早产生影响的工作

投资类：不直接产生价值或损失的工作，或不可预测的工作，这类工作会提升团队效率从而间接产生价值，或如果一直不做的话，长期累积下去会造成经济损失，如清偿技术债、自动化测试、自动化部署、持续集成、架构解耦、代码重构等。这类特性，延期成本不可预测，需用精益创业的方法来验证其价值

处理策略

加急类

走加急通道

不受在制品限制的约束

在整个看板范围内最多同时只能有一个加急的工作项

固定交付日期类

需要在进入看板队列前一周提交给开发团队

在截止日期到达前必须交付

参与在制品限制的计算

普通类

特性按照优先级排序，只有排在前五的特性才能进入看板队列

按照先入先出的顺序交付

团队对每个工作项要预估交付时间

内部技术改进类

内部技术改进工作依据部门调整计划实施

在整个看板范围内，内部技术改进类不少于10%，不超过30%

工作项范围

加急类

宕机

造成经济损失的缺陷，比如用户无法下单

基本功能无法使用的缺陷

固定交付日期类

市场窗口要求的交付日期，即错过市场窗口就没有价值或价值损失极大，比如为大型展会、节日促销等规划的特性

其他团队依赖我们交付的工作项，与我们协商日期后我们已承诺日期

普通类

产品新功能

优化产品体验

内部技术改进类

搭建持续交付流水线

优化前台框架

看板可视化设计

看板可视化可以帮助团队客观、实时的掌握项目进度并帮助团队依据事实和数据做决策

步骤

1、定义过程改进的起始点和终止点（最理想的看板是展示出从开始提出想法，到将想法交付给客户或用户为止的全价值流过程）

2、设计看板的列，设计出工作项需要流经的看板的列（进行中和完成列，完成列给下游一个指示信号，提升上游工作已完成，可以拉动并开始下游的工作）

3、设计看板的泳道（泳道的划分规则由每个团队根据自己需要决定），可以按服务级别划分

4、设计看板的工作项卡片

卡片设计要遵循足够好的原则，即卡片对工作项的状态和风险的呈现有一目了然的效果，足以让团队依据卡片的信息做决策

包含内容

工作项类型或服务级别

标题与ID

负责人

优先级序号

描述

规模/工作量

自然天

故事点

小时数

时间信息

风险和依赖

限制在制品，实现拉动生产

什么是拉动式生成

严格地说，只做了可视化还不能称为应用了看板方法，只有实现了拉动式生产，才是看板方法

拉动式生成、看板、精益生产等概念来自丰田企业

前工序视后工序为自己的内部客户，当后工序需要工件生产的时候向前工序取货，每个工序都以这种拉动式的生产方式工作，一直到第一个工序，从而整个生产线形成了拉动式系统

最理想的情况是企业在接到客户订单后再开始生产，这才是把浪费降到最低的生产方式

常踩的坑：很多软件企业把看板当做Scrum里面的任务板

在制品：没有完成的工作项

拉动式生产方式中，每个流程环节都设置了在制品限制，即允许并行处理的最多工作项个数。从看板的最后一列开始，每个流程环节的处理人都是当自己有富余产能的时候才会拉动上游环节的工作项，从而确保每个环节并行的工作项个数与其产能相匹配，因此，在拉动式生产系统里，工作项始终处于流动状态，没有堆积

创新产品，团队需要采用精益创业的方法，设计最小可行产品（MVP)来验证客户群体和市场

为什么要限制在制品

1、缩短平均周期时间

排队理论是一个有关周期时间与在制品关系的简单数学公式，这一法则为精益生产的改善指明了道路

吞吐率=在制品÷平均周期时间

平均周期时间=在制品÷吞吐率

人月神话经典观点：给一个已经延期的软件项目增加人力，会让这个项目更延期

能够从本质上提升效率的方法是投资敏捷技术实践，如自动化测试、持续集成、加速构建效率、持续交付、自动化运维等技术

2、打破在制品堆积的恶性循环

在制品堆积的影响

1、在制品在某个流程环节或所有流程环节堆积，势必造成相应流程环节的周期时间变长，从而导致总的交付周期延长

2、某个流程环节的周期时间变长，会导致产品质量反馈慢，产品总的交付周期延长，会导致用户或客户的反馈周期延长

3、产品质量反馈慢会造成缺陷堆积

4、测试工程师将产品测试中或上线后发现的批量缺陷都返回给开发团队，使其成为产品Backlog的一部分，无形中又增加了在制品数量，使在制品堆积更加严重

5、创新产品得到用户验证前，很多时候团队实际在做自己“假设有价值”的需求，导致很多未经验证的低价值或无价值需求源源不断进入Backlog，增加在制品数量，且这些需求还会与那些对用户有真正价值的需求争夺宝贵的研发资源。

6、产品质量差，同时业务响应慢，必然导致用户或客户对产品的满意度降低

通过限制在制品数量，可以达到以下目的

1、产品特性的交付周期缩短

2、交付周期缩短，产品质量的反馈周期及用户反馈周期缩短，从而使团队响应业务的速度变快

3、当质量的反馈周期缩短后，从测试和线上返回开发的缺陷会减少，从而产品质量会有所提升

4、从测试和线上返回开发的缺陷减少，在团队的Backlog里排队的缺陷就会减少，从而使在制品数量降低

5、用户或客户反馈的反馈周期缩短后，那些未经验证的无用的或低价值的需求也会减少，从而间接的使在制品的数量降低

6、产品质量的提高，同时团队对业务响应的速度变快，必然会提升用户或客户对产品的满意度；

如何限制和调整在制品

1、将实际的在制品数量作为限制的初始值

2、按列限制在制品数量

约定看板的工作节奏

就绪队列填充节奏

交付节奏

需求从“准备部署”到“已上线”的频率，是特性上线的节奏。交付节奏取决于团队的工程能力和业务需要两个方面

当团队的持续交付能力达到非常成熟的程度，可以做到按需交付并随时上线时，就不需要拘泥于一个固定的交付节奏

团队的交付节奏越快，填充节奏也就相应的要加快

将队列填充节奏与交付节奏保持一致比较容易控制需求在看板上的进出关系

在Sprint周期内，需求范围是不能改变的，而在看板方法里，即使需求被拉入就绪队列，只要团队还未启动就可以改变需求

构建三层反馈环

奏响站会四部曲

步骤

走读

拉动

关注

检视

每日站会结果

看板被更新

完成了很久的工作项卡片被拿掉了

可能会触发会后讨论，但不要让讨论占用站会的时间

累积流图被更新

回顾会议

看板方法更加强调对交付数据做分析，并依据数据进行改进

看板度量数据包括

累积流图

周期时间分布

周期时间趋势

吞吐率趋势

流动效率趋势

比较合适的回顾节奏是两周一次

组织级运营评审

明确组织级运营评审的目标和范围

组织的商业运营状况

市场和运营数据

项目交付数据

人力资源数据

确定组织运营评审的周期和参会人

周期视组织自身的规模来定

哪些人参与取决于组织的文化

收集组织的商业结果数据、市场运营数据、项目交付数据和人力资源数据

项目组收集自己的交付数据

项目交付的整体情况

效率维度（平均周期时间、速率等）

质量维度：每个项目的质量数据

用户运营维度

问题反馈：需要管理层解决的问题

8、用精益的方式做产品

精益创业：创新产品的方法论

浪费的代价

产品里最大的浪费是没有价值的产品，以及产品里那些没用价值的特性

精益创业的反馈环

精益创业方法论来源于其缔造者埃里克.莱斯的著作《精益创业》

敏捷关注的是产品如何做，即在做什么样的产品这一议题通过验证后，用敏捷开发方法快速迭代，持续获取用户反馈，进而不断调整和改进产品。

精益创业为做什么样的产品，以及确定采用什么样的商业模式提供了可以验证的方法论

精益创业到底是什么呢？指的是企业在各种不确定的环境中开发新产品时，用来规避风险和减少浪费，尽快为用户提供有价值的产品的一种方法论

精益创业的本质是一个反馈环：概念->开发->产品->测量->数据->认知->概念

核心思想是：当有了一个产品概念时，不要急于投入资源开发产品，而要先开发一个最小可行性产品（MVP)，将MVP带到早期客户中去验证概念的价值。依据早期客户的反馈来调整产品概念

MVP不一定是真实的产品，而是以最快的方式和最少的精力完成的一次“开发--测量--认知“反馈循环的实验品

用MVP开启学习认知的流程，在快速验证循环中不断的验证和改进，逐步走向完美，而不是在初始规划阶段就预先定义好产品要达到的目标

MVP是用来验证基本的商业假设

精益创业是做创新产品和创新项目的方法论，对于任何新产品、新流程、新工具都是通用的，不论是在创业公司还是成熟的大企业

设计最小可行性产品（MVP)

常用的设计方法有

1、用户访谈

2、产品介绍的视频

3、众筹

4、仿真

5、原型

6、预售页面

建立产品愿景

精益画布：从一个想法开始建立商业模式

1、Why：为什么要用精益画布

精益画布提供了一种可视化框架，可以帮助团队理清思路，快速识别出项目中的不确定性及风险，进而便于团队一起创建商业模式

2、WHo：谁制作精益画布

一般包括产品负责人、行业专家、架构师等，产品负责人在制作精益画布过程中起主导作用，对商业模式有决定权

3、When：什么时候做精益画布

在对一个产品有了想法后开始

4、How：怎么做精益画布

9个步骤

1、问题：客户要解决的三个问题

2、客户群体分类：目标客户

3、独特卖点：为什么你的产品与众不同、值得购买

4、解决方案：产品最重要的三个功能

5、渠道：如何找到客户

6、成本分析：a、获取客户所需费用；b、销售所需费用；c、研制和生产所需费用

7、收入分析：a、盈利模式；b、客户终身价值；c、收入；d、毛利

8、关键指标：应该考核哪些东西

9、门槛优势：无法被竞争对手轻易复制或超越的优势

用户画像：定位目标用户群体

做产品围绕的中心只有一个，即使用产品的用户

用户画像是用来分析目标用户的一个有效工具

其定义是：真实用户的虚拟代表，是建立在一系列真实数据之上的目标用户模型

1、Why：为什么要创建用户画像

让团队统一定义用户，减少主观臆测的干扰，帮助团队理解用户到底真正需要什么，从而使团队设计出真正以用户为中心的解决方案

用户画像的作用

帮助企业设计商业模式

帮助团队与用户产生共鸣

帮助团队达成统一意见，提高效率

帮助团队从“以功能为中心”转向”以用户为中心“做产品设计

帮助团队聚焦核心场景，优化需求优先级

2、Who：谁负责创建用户画像

用户画像是由产品负责人、UX设计师、研发团队、运营人员所组成的团队共同创建的成果

常踩的坑：在很多企业里，创建用户画像成了UX设计师的分内职责，却没有其他角色的参与，这样无法让团队对用户的理解达成共识；

鉴于UX设计师掌握专业的用户画像方法和用户调研过程，所以可以由UX设计师主导用户画像的创建以及用户调研工作，但是要创建高质量的用户画像，必须协同产品负责人、研发团队等同事共同完成用户画像的创建

3、When：什么时候创建用户画像

企业在创建商业模式时

通过客户调查问卷或者客户访谈了解客户群体的共性与差异后，汇总成不同的虚拟用户，形成用户画像

4、How：怎么创建用户画像

用户画像是虚拟的

团队需要在做产品的过程中通过设计MVP、频繁发布产品等方式不断地探索和修正其对用户的认知，在这个过程中，很可能当初团队创建的用户画像会被抛弃

推荐高效创建用户画像的流程

1、收集用户调研的数据和信息

2、团队全员聚集在一起，每个人依据用户调研的结果创建自己理解的用户画像

3、每个人将自己创建的用户画像贴在墙上，轮流介绍自己的用户画像，团队一起讨论

4、团队对每个用户画像进行修正或废除，最终形成由1~3个团队达成共识的用户画像

5、团队在后续做产品的过程中，依据用户画像继续深入目标用户群体做实地考察，同时通过发布MVP获得验证反馈，然后团队对反馈进行总结分析，进而定期修正画像，这是个学习、证伪的多次循环的过程。

用户画像不是静态的，我们需要拿着MVP或者发布的产品回到之前调研的用户中去验证这个产品是否解决了他们的痛点，在此过程中，我们会发现用户新的需求或痛点，从而进一步丰富用户画像

用户画像的基本框架

照片

行为习惯

基本信息

洞察到痛点

形成产品愿景

1、Why：为什么需要有产品愿景

产品愿景是指引产品发展方向的灯塔

帮助团队聚焦

激励团队

便于企业内外利益干系人理解产品

2、Who：谁负责创建产品愿景

创建产品愿景是团队共创的活动，主要由产品负责人创建，涉及的人员同制作商业模式的人员

3、When：什么时候创建产品愿景

制作商业模式和用户画像的过程中，产品愿景就逐渐被勾勒出来

4、How：怎么做

好的产品愿景具备以下几个特点

简介、清晰

团队可以用电梯演讲来测试

电梯演讲：短时间内表述清楚产品内容，来源于麦肯锡公司

定位明确

目标客户是谁、客户为什么要买这个产品，而不是竞争对手的产品

充满激情

能够启发和激励团队参与打造这个产品的热情，也能够鼓舞潜在客户、投资人、利益干系人对产品产生好奇感

愿景创建完毕后，团队可将愿景用白板纸书写下来悬挂在团队的工作区域，从而提醒团队不要忘记产品的长远目标

产品愿景模板示意图

为满足：目标客户

他们需要：客户需求

什么名字：产品名字

有哪些特性：产品描述

同类产品：竞争对手的产品

本产品的长处：优势

制订产品规划

创建产品的第一份Backlog

卡诺模型

也叫做狩野模型，由日本品牌管理大师狩野纪昭博士提出，卡诺模型将产品的属性分为五类

无差异属性：可有可无的属性，无论是否提供此属性，用户的满意度不会改变

魅力属性：用户想象不到的属性，如果不提供此属性，不会降低用户的满意度，而一旦提供此属性，用户的满意度会大幅提升

线性属性：客户的满意度与产品品质呈线性增长，即产品的品质越好，客户的满意度越高

必备属性：用户对产品的基本需求，如果不提供此属性，用户的满意度会大幅降低

反向属性：用户根本没有此类需求，如果提供此属性，用户的满意度反而会下降

必须做好产品的必备属性和线性属性，这是产品的基础

不要规划那些无差异属性和反向属性的需求

努力做好魅力属性的需求，这些需求能够激发产品的指数级增长

规划最小可发布版本（MMR)

团队需要从第一份产品Backlog里精心筛选出最有价值的特性并作出一个成本最小的产品版本发布到市场上，而不是畅想未来

最小可发布版本（Minimum Marketable Release）是为客户提供的最小、最有价值的特性结合构成一个产品发布出来，目标是抢占市场窗口，及早获取用户真实的反馈，用真实的产品验证商业模式

最小可发布版本即第一个版本的市场反馈可以为产品的迭代演进提供参考信息，从而使团队减少不必要的需求开发，减少浪费

MMR与MVP有所区别，MVP是验证假设的试验，MMR是真的可以被用户购买的产品

团队需要铭记的是：永远都不要期望在第一个版本里作出尽可能多的需求特性，而是要以最少的特性先发布MMR，这个版本要体现产品的独特的价值主张

那如何决定哪些特性应放在第一版的MMR里面呢？

1、根据核心价值主张和卡诺模型

KANO模型（卡诺模型）

卡诺模型更多的是关于产品对于用户的兴奋点和满意度，按照卡诺模型，会将需求分解为基本需求、期望需求、兴奋需求、无差异需求和反期望需求五个部分

2、团队对产品的每个特性只需要问一个问题：如果没有它会怎么样？如果没有它并不影响用户的使用需求，那它就不该出现

对于产品的每个特性，其最小的、必不可少的、有价值的部分都要被拆分出来

拆分出最小特性的要诀是：将每个特性拆分出子特性，一直拆到不能再拆为止（如果再继续拆，就无法为用户提供独立的价值），然后采用MoSCoW方法来识别每个子特性的优先级

MoSCoW方法

决定优先级的方法，是Must Have、Should Have、Could Have、Won't Have的英文单词缩写

Must Have：必须有的特性，如果没有这个特性即无法实现版本发布的目标

Should Have：不是关键的基本特性，但是对用户仍有较高的价值

Could Have：在Must Have和Should Have特性都具备的前提下，团队可以考虑那些添枝加叶的功能，当然要在其成本和代价不大的情况下才考虑做，在有风险的情况下，团队应首先考虑删掉Could Have特性

Won't Have：在这个版本里不会发布的特性

团队在第一个版本后的每个版本制作过程中，也需要用MMR的思想来重新审视每个特性的优先级，将每个特性拆分到最小单位，并从当前的Backlog里取优先级最高的那些特性

洋葱圈规划法

很多团队认为，敏捷的价值观是“拥抱变化胜于执行计划”，那既然做敏捷了，就不用做什么计划了

很多敏捷团队非常专注于眼前的工作，只关注当前迭代的交付，或者是那些已经入看板就绪队列的需求的交付，但是对产品下一步要做什么、未来要做什么都不清楚

实际上产品规划是在多个层面上持续进行的活动，洋葱圈规划

洋葱圈规划（从最外层到最内层）

投资组合计划/评审/回顾

产品路线图计划/评审/回顾愿景

包含重要版本的发布时间、重要版本的名称、重要版本要实现的目标、重要版本的特性（不需要做详细拆分）

版本计划/评审/回顾每个版本

很多互联网团队的交付能力比较成熟，每个迭代甚至在每天都会发布多个版本，这说明版本周期小于迭代周期，在这种情况下，团队一般不需要召开评审和回顾会议

每日站会

每日站会是最小单元的计划活动

敏捷需求管理

敏捷需求管理与传统需求管理的差异

需求所承担的作用不同

传统需求：详尽的描述团队需要完成的产品特性，经常成为产品和研发之间的契约，团队最终交付的是文档中描述的产品特性，但该描述是客户真正的需求吗？只有等团队交付给客户之后才能知道答案

敏捷需求：需求作用是为了引导团队对客户诉求进行理解。事实证明，只有产品经理一个人写的需求，并不能使团队真正理解客户的诉求，团队只有通过一起来讨论并分析需求才能达到真正理解客户诉求的目的

时限不同

传统需求：需求生命周期非常漫长，有专门的需求分析阶段，是产品开发的早期阶段，以后的阶段都是为了交付需求。团队对新提出的需求或者对原有需求的变更也要通过评审委员会的评审，走正式的变更流程

敏捷需求：a、需求生命周期很短暂，没有专门的需求分析阶段，团队可随时对记录需求的特性列表进行增加、删除和修改。
b、产品负责人和团队对需求的分析贯穿于整个产品生命周期，他们在每个迭代周期都有讨论和梳理需求的时间。团队不需要针对需求变更走评审流程，团队可以随时在Backlog理修改需求（只要需还没被纳入当前的迭代计划，或者没有被纳入看板的就绪队之中，团队就可以修改

需求的规模不同

传统需求：没有明确的需求拆分概念，不管各个需求的规模是大还是小，团队都是到”最后一公里“的时候一起交付；

敏捷需求：要被拆分到最小粒度，以保证产品特性的持续发布

参与人不同

传统需求：有专门的产品经理或者业务分析元依据其对客户需求的理解进行需求分析，形成需求分析文档后传递给研发团队，而研发团队基本不参与需求分析

敏捷需求：产品负责人是需求分析的主要负责人，他需要与研发团队一起讨论需求，这样做的必要性在于

无论需求写的多么具体，实际的需求信息无法通过文字完整的传递出来

产品的需求与其解决方案之间的界限并不是完全清晰的

无论产品负责人的个人能力有多强，单靠其自己的力量无法对需求的场景全面分析。研发团队从解决方案的视角来思考和澄清需求，往往会让产品负责人发现很多其之前没有考虑到场景

优先级制定方式不同

瀑布模式：需求库里面所有的需求通常都要做

敏捷开发：团队需要将需求拆分到最小价值单元，最小价值单元必须有明确的优先级，只有少量的需求才是版本里不可或缺的

常踩的坑

很多敏捷团队仍旧在用瀑布方式管理需求，常见现象有

所有需求都必须在某个时间点完成

产品负责人将需求扔给团队后就消失了，团队很难找到ta澄清需求

需求完全没有被拆分，或者拆分不到最小价值单元时就进入开发阶段

从传统工作方式走向了敏捷的极端，产生了更大的浪费

需求没有被纳入Backlog，团队通过口头传递就进入了开发阶段

需求表达不清晰，产品负责人将需求分析工作推给了研发团队，研发团队在开发的时候现做需求分析

保持产品Backlog的深度

Backlog来源

商业模式（精益画布）

产品愿景

用户画像

产品路线图

客户或用户的反馈

团队自己发现的需求

Backlog需要满足以下属性，即DEEP

D（Detailed Appropriately）适度详细

需求优先级越高，描述得越细致，反之越粗糙。优先级排在最高的需求，其描述细致到足以马上启动开发

E（Estimated）估算好的

团队不需要对Backlog里的每个需求都作出估算，但一定要对下一个版本以及下一个迭代的需求作出估算。

估算的意义

判断需求的规模

做版本计划

做迭代计划

E（Emergent）涌现的

需求不是一开始被写进Backlog里的时候团队就能完全清楚的，而是随着时间的演进，通过逐渐增多的用户和时长的反馈，使得团队获得更多的人之后而逐渐明晰的

在当今UVCA时代，唯一不变的就是变化

VUCA：易变性（Volatility）、不确定性（Uncertainty）、复杂性（Complexity）和模糊性（Ambigutiy）

P（Prioritized）排好优先级的

团队在产品需求分析中要弄清楚需求的优先级

团队的版本需求分析中要分清楚Must Have需求、Should Have需求和Could Have需求

团队在做迭代计划的时候，需要将纳入迭代的需求排除唯一一个先后顺序，团队按照这个先后顺序认领需求开发

在很多敏捷团队的Backlog里，需求优先级并没有被标识出来，而是存放在了产品负责人的脑袋里，但这并不代表需求没有优先级。当问及团队为什么没有标识的时候，产品负责人说大家都知道，没有必要标识。而当问及研发工程师的时候，他们表示不清楚，只是知道这些需求需要做

为什么需要通过显性标识让全员对需求的优先级有明确的理解呢？

口头沟通无法确保每个人都信息的准确掌握

如果不知道优先级，团队成员一般会喜欢认领那些容易的需求，会导致真正高价值的需求被排在后面

用户故事：以用户为中心描述需求

Why：为什么要用用户故事（卡片）来描述产品需求

帮助产品负责人和团队逐渐形成以用户为中心的思考方式，而不是单纯地以功能为中心来思考产品

Who：哪些人创建用户故事

产品负责人创建初始用户故事，然后将用户故事卡片带到Backlog梳理会上与团队成员一起讨论，再由团队成员来补充和创建新的用户故事，这样做比团队从零开始创建用户故事的效率要高

创新性的特性，可以召集团队一起进行头脑风暴来创建用户故事

When：什么时候创建用户故事

团队的第一个Backlog条目就可以以用户故事的形式创建

产品负责人在与团队做Backlog梳理和迭代计划的时候，会发现并创建新的用户故事或者修改已有的用户故事

How：怎么创建用户故事

用户故事三要素

角色：谁要使用这个功能

功能：需要完成什么样的功能

目的：这个功能可以达到什么目的

用户故事模板

作为一个<角色>，我想要的<功能>，以便达到的<目的>

作为一个项目经理，我想要一个工作项订阅功能，以便于我随时掌握那些重要工作项的进展

用户故事要从真实的用户角度来描述，要体现出产品给用户带来的价值

需求与用户故事的关系

用户故事从用户使用产品系统的角度对需求进行描述的方式，但不是所有的需求都必须用用户故事的形式来描述，如果需求与用户的使用无关，则不需要使用用户故事的形式来描述，如有些产品需要满足某些法律法规、政府规定、行业规范等

对于那些涉及用户使用产品系统的需求，需要永远选择用户故事的方式来描述吗?

在团队没有养成以用户为中心的思考习惯时，最好采用用户故事的方式来帮助团队固化思维方式，但是在团队形成习惯后，就不需要每个需求都使用用户故事来描述，尤其是那些产品体验优化类的需求，因为团队对目标用户及其使用的目的都已经非常清楚

团队还需要创建验收条件来定义用户故事的边界和范围。相当于用户故事的”完成的定义“。验收条件的3个作用

触发团队从用户的角度思考如何使产品满足用户的诉求

作为创建测试用例的输入

把握需求的范围，去除不必要的需求场景

用户故事需满足INVEST原则

I（Independent）独立的

尽量避免用户故事之间相互依赖，因为团队在对用户故事排优先级或做迭代计划时，用户故事之间的相互依赖会使工作量的估算变得更加困难

通过下面两种方式减少用户故事之间的依赖性

将相互依赖的用户故事合并成一个颗粒度大的、独立的用户故事

重新拆分用户故事

N（Negotiable）可协商的

是对产品功能的简短描述，不是详尽的、面面俱到的细节描述，需求的细节将在团队的讨论过程中涌现出来

用户故事开启了产品负责人与利益干系人、客户以及团队关于需求讨论的对话，但是它不是需求的全部

V（Valuable）对用户或客户有价值的

应清晰体现出产品对用户或客户的价值

E（Estimable）可估算的

开发团队需估算用户故事的规模，以确定优先级、工作量，并安排计划的执行

S（Small）小

规模应尽可能小，至少要确保在一个Sprint内能够完成

规模越大，在安排计划执行和工作量估算等方面的风险就会越大

如果按天估算，则一个story最好在1~5天

如果按照故事点，则一个Story最好拆分到13个点以内完成

T（Testable）可测试的

用户故事必须是可测试的

团队可通过以下方法使用户故事达到可测试的条件

测试人员与开发人员一同参与用户故事的讲解和讨论，从而让测试人员能第一时间理解需求，并从测试的角度提问和思考

明确每个用户故事的验收条件，并将其作为测试的输入

如何决定需求的优先级顺序

两种方法

定性评估法

通过评估影响需求排序的几个要素，然后为需求排出先后顺序

延期成本

实现成本

风险和不确定性

依赖

如A依赖B，则A和B最好错开一个迭代周期后再实现，至少错开一周。尤其是在相互依赖的用户故事由其他团队交付的情况下，由于进度不受团队自己控制，所以团队更需要将它们错开节奏

定量评估法

为影响优先级顺序的每个要素赋予一个数值，然后用公式计算并排列出需求的先后顺序

规模化敏捷框架SAFe采用加权最短作业优先法来评估需求的优先级

WSJF=延期成本/工作规模

工作规模即需求规模，可通过故事点、理想人天等估算得出

延期成本

用户和商业价值

用户更喜欢哪一个需求

这些需求对这些盈收有什么影响

如果不做这个需求的话会产生什么潜在的负面影响

时间的关键性

是否是固定交付日期类型的需求

用户是否愿意等待，还是会选择其他产品

如果是在某个时间窗口不上线的话，是否会让用户失望

减少风险或获取新的商业机会

是否会降低团队以后交付某些必要的特性的风险

是否会获得团队之前不知道的知识或信息

是否会给企业带来新的商业机会

WSJF公式可细化为：WSJF=（用户和商业价值+时间的关键性+减少风险或获取新的商业机会）/工作规模

不需要对整个Backlog进行排序，需要将排在顶部的当前版本的需求以及最近一两个迭代的需求排出唯一的先后顺序；对于以后版本以及一两个迭代以后的需求，则不需要排出唯一的先后顺序

产品决策：如何决定需求做与不做

产品决策要以”用户或客户场景驱动“为核心

面对一个需求，首先判断这个是否是用户或客户的真实需求，以及这个需求是在什么场景下产生的

产品需求决策过程示意图

甄别需求真伪

开展竞品分析

设计方案，思考如何超越竞品

权衡市场窗口，估算上市时间

将需求规划到不同的版本中

长踩的坑

产品负责人自己的假设

对市场上竞品的模仿

年度战略规划

行业竞争

领导指示

无论从什么渠道获取到的需求，都要将其带到用户或客户的场景中去分析。从客户价值角度分析，是否值得做

对用户提出的原始需求进行甄别，以用户为中心，听取用户的反馈，并不意味着用户提出的所有需求都要去做。

根据经验，用户提出的需求里有70%的需求是不需要做的

面对一个需求时，应做好以下工作

还原需求

千万不要把用户提出的所谓需求，直接收录到Backlog里，一定要做需求还原的工作

用场景化甄别出伪需求

Who：哪些角色参与

When：什么时候、在什么条件下发生

Why：要解决什么问题

How Often：以什么频次发生

How：怎么发生

判断是否刚需、高频或大客户的需求

刚需、高频的特性是需要重点打磨的地方

判断是否解决了”更“的问题

完成这个需求有什么优势

需求做进产品之中后，对用户现有的解决方案有没有更大的超越，如果没有，则白做了

判断是否是全流程的需求

如果需求只是流程中的一部分，则要考虑是否延展到全流程场景

如不能延展，则该需求与用户现有的解决方案衔接起来是否流畅

让用户体验设计敏捷起来

将用户体验设计纳入敏捷流程

UX设计师与团队矛盾很深，该如何解决

UX部门派驻全职的设计师进入敏捷团队

产品负责人、开发团队和UX设计师要错开工作节奏

UX设计师的工作与开发工作应错开一周甚至两周的时间

对产品设计的争执是良性的互动过程，产品负责人是最终决策者

正确发挥原型的作用

Why：为什么要做原型

When：什么时候制作原型

Who：谁负责制作原型

How：怎么制作原型

低保真原型

可点击的框线图

高保真原型

在框线图基础上增加了视觉和交互的细节设计

与真实的产品看起来没有差别

可以直接为研发团队的前端开发提供输入

9、敏捷与精益数据分析

数据分析框架

任何企业的业务目标之一都是在财务上实现一定的收益增长，为了实现这个目标，企业需要向客户持续且高效率的提供高质量、有价值的产品或服务，而这一切的原动力是企业里每个团队、每个员工的学习和成长

财务

关于财务收益和成本的度量，敏捷没有特殊的方法和理念，企业可以继续沿用原有的度量方法

价值

一直是一个难题，企业可以从产品运营数据和用户体验数据两方面进行度量

效率

敏捷引入了很多新的度量方式，企业可以从价值交付效率和工程效率两个方面进行

质量

质量分为内部质量和外部质量

在瀑布模式里，企业更关注产品的外部质量，敏捷的核心要素之一是缩短反馈环，将质量内建在开发过程中，因此，企业在关注外部质量的同时，更加强调外部质量。

学习和成长

一个企业的核心竞争力，说到底是拥有不断学习和成长的员工，可以用技能地图度量方法，帮助企业开展分析组织和团队能力的活动，引导组织和团队持续学习和成长

度量价值

价值度量的意义不只是知道结果，更重要的意义如下

辅助产品决策

在产品或需求启动前评估价值，以做出”做什么或不做什么“以及”什么时候做“的决策

形成产品反馈闭环

在产品或需求发布后度量其价值，为调整产品放行或Backlog提供输入

评估方法

产品运营数据

访问用户量（UV)

体现产品当前的运营状况

新用户量

分析产品的推广效果或成长空间

活跃用户量/活跃度

分析产品真正获取了多少有价值的用户

活跃度越高，说明用户对产品的黏性越高

流失用户量

分析产品对用户的保留能力

回访用户量

分析产品挽回流失用户的能力

海盗指标模型

获取用户：用户从哪些渠道来，如何让他们成为产品的使用者

激活用户：新用户是否感受到了产品的价值？第一次使用的体验如何

留存用户：用户为什么愿意留下来？如何让用户复购产品？

用户营收：如何将留存的用户变现？

用户推荐：用户是否对产品满意？如何使用户将产品推荐到他的社交圈

业界成熟的用户数据分析工具

用户体验数据

Google的用户体验设计师提出了以用户为中心的度量体系”HEART“框架

提供了一个”目标->信号->指标“的简单流程来完成用户体验指标的设定。

明确目标（Why）：为什么度量，需要实现什么目标

明确信号（What）：为了实现目标，需要度量哪些内容

定义度量指标（How）：详细定义度量的方法和频次

H：愉悦感（Happiness）

用户对产品的满意度、视觉感觉、向别人推荐的意愿、易用性等方面的感知；

可通过调查问卷的方式

E：参与度（Engadgement）

用户在一个产品中的参与深度。

可通过一段时间内用户访问产品的频次、强度或互动深度等方面综合运用相关数据来判断，比如针对社交类产品，可通过度量用户每周的登录次数、每周上传的照片数、每天的对话次数等，比单纯的度量用户访问总量更能体现产品的体验价值。

用户对产品使用的频次越高，互动越多，说明对产品的体验越好

A：接受度（Adoption）和R：留存率（Retention）

企业可用接受度和留存率两指标来区分新用户和老用户。

接受度：用于监控在特定时期内有多少新用户开始使用产品，比如最近7天内新创建的账号

留存率：监控特定时期内有多少用户继续使用产品。比如某一周的”7天活跃用户“在3个月后仍然在”7天活跃用户“

T：任务完成率（Task Success）

包括一些传统的用户体验行为指标，比如任务完成的时间效率数据、任务完成的百分比、任务完成的错误率数据等

度量效率

价值交付效率

速率

团队对一个Sprint里完成的工作的度量，单位可以是用户故事点数、理想人天、或者是用户故事的数量

迭代结束时统计实际完成的速率与计划的速率之间的比值，且对没完成的用户故事做回顾，看看需采取什么改进措施

速率一般用柱状图表示：如Jira的速率统计图、Excel、手工绘制等

每个Sprint的实际完成的速率可作为后续Sprint计划的参考

Sprint燃尽图

燃尽图的全称：总剩余工时的燃尽图：指当前Sprint计划的用户故事被拆分的所有任务，其剩余估算的时间总和随着日期的变化而逐日递减的统计图

团队每天将估算的剩余任务的小时数相加，绘制成实际燃尽线。

燃尽图的最大作用是预警交付风险

当实际燃尽线低于理想燃尽线时，团队可能会提前完成Sprint计划的工作，此时团队仍需继续保持现有的速度

当实际燃尽线高于理想燃尽线时，团队可能会完不成该Sprint的工作，此时，Scrum Master需提醒团队加速前进

燃尽图没有好坏之分，Sprint燃尽的过程千差万别，只要最终在Sprint截止日达到Sprint目标，Sprint就是成功的

燃尽图每天给团队一个进度反馈，用数据告诉团队是否会有达不成Sprint目标的风险

有个问题：工时的燃尽不代表价值的交付，即使某一天工时燃了很多，但团队一个用户故事都没完成，也不能代表价值交付，于是采用用户故事燃尽图，用户故事燃尽图就像楼梯一样，不是一条斜线。

版本燃尽图

横轴：Sprint周期

纵轴：该版本未完成的用户故事点数

看板累积流图

是看板方法里核心的度量之一

可以很好的反映工作项在每个流程环节中的流动问题

横轴：时间（天）

纵轴：工作项数量（个）

借助累积流图可以分析出以下有价值的信息

在制品数量

平均周期时间

吞吐率

看完成线的斜率

需求范围的变化

预测交付日期

看板周期时间分布

看图的尾巴

尾巴很长，说明团队的交付时间离散、交付能力不稳定

团队需回顾：处于分布图尾部的那些工作项的价值流动过程，分析是什么原因导致周期时间偏长

波峰的位置

波峰靠右，说明团队的交付周期时间偏长，整体的交付能力薄弱

团队需回顾：为什么每个工作项的交付周期会这么长？工作项是否已拆分到最小单位？如果已拆分到最小单位，如何才能缩短交付周期?

波峰的高度

波峰位置越高，说明分布越集中，从而团队交付周期的可预测性越强

如果分布图扁平，一定有大量的离散点，说明团队交付周期的时间跨度很大

团队应回顾并分析：如何提高可预测性？比如可尝试将需求粒度拆分得更加均匀，让工作项流动得更加顺畅

工程效率度量

编译效率

用开发人员从启动个人构建到获得构建结果反馈的时间来度量

包含的活动有：代码提交、编译连接、静态检查、单元测试

版本构建效率

用从启动版本构建到获得可运行版本的时间来度量

包括的活动有：版本编译、静态检查、冒烟测试

回归验证效率

用完成一轮产品回归验证所需的时间来度量，即在迭代周期内修改了旧代码后，重新进入测试环节以确认修改没有引入新的错误，或导致其他代码产生错误的一轮测试时间

包括手工和自动化测试，但应尽量采用全自动化测试，因为手工的回归验证方法无法满足频繁发布的要求

全量功能验证效率

用覆盖版本所有功能的一轮测试时间来度量全量功能验证效率

包括手工测试和自动化测试，自动化测试的程度越高越好

非功能性验证效率

依据产品的测试计划，有些版本需要开展性能测试、安全测试、压力测试等非功能性测试。

这些测试需要专业的工具完成，这些通常是模拟大数据量、模拟长时间运行的测试，因此非功能性验证效率是测试效率的重要组织部分

度量质量

外部质量

能被用户或客户感知的质量

常见的度量指标

用户满意度

满意度电子调查问卷（如卸载时弹出的卸载原因）

净推荐值方法（NPS）：是一种计量某个客户将会向其他人推荐某个企业或服务的可能性的指数，它可用于海盗指标的”用户推进“步骤中；采用打分制，0-10分

产品的非功能性属性

可靠性、性能、安全等非功能性需求，在产品上线前进行测试以确保能够达到预定目标

比如手机的平均故障间隔时间

关键使用场景的性能指标，如开机时间少于10分钟

电量消耗指标

缺陷密度

以每千行代码的缺陷数来测量，其测量单位是：Defects/KLOC

计算公式：缺陷数量➗代码行数

缺陷密度越低，意味着产品的质量越高

用缺陷密度来度量质量的原理是：由于我们无法通过测试发现所有的缺陷，而且在修复缺陷时还会引入新的缺陷，因此，在测试中发现缺陷越多的地方，就会有越多的潜在缺陷将会被发现

内部质量

不被用户或客户感知，而被开发者感知的质量，即开发和设计的质量

精益专注于在缺陷发生的源头将其发现并解决，通过减少价值流中的缺陷向下一个环节流动的可能性，从而减少缺陷带来的成本。

如果一切都等到测试人员对产品的外部质量全部测试完成，缺陷的反馈周期将会被不必要的拉长，修复的代价将呈指数级增长

内部质量度量又分为

代码质量度量

圈复杂度

是代码复杂度的衡量标准，用来衡量一个模块结构的复杂程度，数量上表现为独立路径条数，即合理的预防错误发生所需测试的最小路径条数。

圈复杂度越大，说明程序代码可能质量低且难以测试和维护

程序里可能蕴含的错误与圈复杂度的高低有很大关系

危险函数

指的是部分函数没有检查目标缓冲区的大小，很容易引入缓冲区的安全漏洞，并且这些函数没有处理掉一些特殊情况（比如内存重叠），可能会导致意想不到的安全问题

静态分析告警

静态分析指的是在不运行代码的方式下，通过词法分析、语法分析、控制流分析等技术对代程序代码进行扫描，已验证代码是否满足规范性、安全性、可靠性、可维护性等指标的代码分析技术所产生的告警

此外，代码质量还可以用冗余代码、函数代码行、文件代码行、编译告警、重复文件数、重复代码率等指标度量

白盒测试覆盖率度量

包括单元测试、模块测试、集成测试、API测试的测试覆盖率

测试金字塔框架

从下往上依次为：单元测试/组件测试、验收测试/API接口测试、用户界面测试

测试金字塔框架表明，越靠近底层的，其自动化程度越高

从上往下的测试类型，其成本更低，效率更高，且更贴近代码，因此缺陷更容易定位。

从下往上的测试类型，其成本更高、效率更低、但更接近真实的业务需求，缺陷定位越不容易

持续交付流水线运行的成功率

流水线的调度周期可能包含持续交付全过程的各个环节或其中的一些环节，因此，流水线运行的成功率可能有编译通过率、代码静态检查通过率、冒烟测试执行率和通过率、回归测试的执行率和通过率、全量验证的执行率和通过率等。

业界有很多软件工程工具能够自动度量以上介绍的内部质量，尤其是持续交付和DevOps工具，一般都可以在流水线运行过程中自动统计运行成功率

有了关于效率和质量的数据，组织应该设定指标来促使团队提升效率，否则单凭数据本身难以引起团队的关注，除非团队自身有很强的内驱力

效率和质量是密切相关的，企业应定义研发效率目标，同时也应定义内部质量目标

效率的提升是无止境的，因此当组织的效率指标达到了目标后，就需要设定更有挑战的目标，以牵引组织持续改进

度量学习与成长

发展组织能力

能力评估自评打分，打分录入数据库，作为后续新项目立项时的参考，确保员工的能力与项目需求相匹配，避免员工不能胜任或过于胜任的情况

发展团队能力

以敏捷团队为单位发展团队的能力。最好的敏捷团队是T型团队，即每个人都有自己的专长，但也是个通才，在别人需要帮助的时候，可以提供帮助

避免团队的技术壁垒，确保团队按照价值优先的原则为Backlog排序

团队技能地图

团队将产品所需的技能逐一列出

自评打分

集体评估

能力基线化

团队可将产品负责人提供的Backlog里优先级最高的哪些需求以及产品路线图作为技能地图的重要输入

评估敏捷转型的效率

面向结果的评估

定量评估

价值

效率

质量

学习

成长

定性评估

结合定量评估，还可通过调查问卷，让敏捷转型中担任各种角色的员工来反馈敏捷转型的效果

敏捷撰写是以人为中心的变革，因此相比冷冰冰、数字化的度量结果，人们对敏捷转型的感受同样重要

面向过程的评估

敏捷与CMMI不同，敏捷不是过程的集合，因此业界没有统一的敏捷成熟度模型

推进使用规划化敏捷框架SAFe的敏捷自评表来设计适合自己的评估工具

SAFe的自评表分为

团队级自评

产品管理健康度

技术健康度

潜在产品增量/版本健康度

团队健康度

迭代健康度

敏捷发布火车自评

投资组合自评

过程做的再好也未必能产生所期望的结果，因此面向过程的评估不能单独应用，需结合面向结果的评估方法一起应用，才能客观的反映出团队转型的进展，从而找到下一步改进团队工作的方向

10、敏捷领导力

敏捷领导力框架

激励员工

赋能团队

统一目标

能力提升

结构成长

全面改进

激励员工：让每个人积极主动起来

马斯洛需求层次理论

在不同时期表现出来的对各种需求的迫切程度不尽相同，人们在当下最迫切的需求才是激励ta采取行动的主要原因和动力

当低层次的需求基本得到满足后，它的激励作用就会降低，其优势地位将不再保持，高层次的需求会取代它成为推动行为发生的主要原因。长久的热情是由高层次的需求激发出来的。人的最高层次的需求是自我实现

马斯洛需求层次理论5个层级

生理需要

设计一些让人工作愉快的场景，如令人舒心的茶水间、洗手间、办公位、办公室等

安全需要

人身安全、信息安全和心理安全

心理安全

在企业里，员工是否能轻松自如的表达自己的观点？

大家对不懂的事情是否敢于提问?

这些问题虽然貌似简单，但遗憾的是，很多企业都做不到

社会需要

团队的每个成员都需要在团队中找到自己明确的位置，从而产生存在感

企业可以从以下几个方面着手满足员工的社会需要

团队成员的角色定义明确

在物理空间上尽量让团队坐在一起

定期举行茶话会等团队建设活动，增强团队凝聚力

在工作之余，领导者需要花些时间与团队在一起，以此拉近与成员间的距离

尊重的需要

每个人都有被尊重的需求

如果这个需求被满足，他/她机会更加喜欢其所在的环境

遗憾的是，对人的不尊重是很多企业里的常见病

你可能经常见到领导对下属咆哮、谩骂、羞辱式的批评，这会让领导者在其他方面所在的一切激励员工努力付诸东流

尊重员工方面的措施参考

感谢信

在回顾会议中插入感谢信的环节，主持人给每个人准备一个信封和一张A4纸，让每个人回顾这个迭代的历程，给心中想表达感谢的同事写一封信。写好后，由身旁的同事读信，并将其交给被感谢的同事

感谢信是团队有效的黏合剂，能有效凝聚团队成员，激励大家为了达成团队的目标而互帮互助

咖啡角感谢墙

Open Door政策

很多外企都有该政策，即企业里所有管理者的办公室门都保持敞开状态，任何一名员工都可以走进管理者的办公室，与其交流工作上的问题和想法

参与式决策

聆听并有时候采纳员工的意见，员工会感受到自己受到了尊重，工作动力会得到提升

自我超越的需要

员工的职业发展路线

企业平台与自己的发展目标一致，则内在动力会更强

赋能团队：让团队自组织

如何管理知识工作者

德鲁克提出，对管理知识工作者需掌握以下几个原则

员工自己是对其工作如何开展的最佳决策人

如果想高效的领导员工，必须聆听和尊重员工

知识工作者必须自我管理，他们必须有自主权

持续创新必须成为知识工作者工作、任务和责任的一部分

德鲁克的观点与敏捷团队的”自组织“理论有异曲同工之妙，Scrum Guide提到Scrum团队自组织的特点是

团队是自组织且跨功能的

自组织团队决定如何最好的完成他们的工作，而不是由团队外的其他人来指使他们完成

敏捷宣言的12条原则中关于自组织也有一条

最好的架构、需求和设计出自自组织团队

何为自组织团队呢？

在没有施加任何有意计划的管理或外部元素控制的情况下，系统里的结构或模式有其默认的过程和方式。因此自组织是任何动态系统的默认行为，不论它们是原子、生物、业务系统，还是软件工程师团队。不管你如何管理团队，团队本身都存在一定的自组织性。

自组织不是意味着团队可以不受约束，不代表完全无组织

自组织团队还是需要一些规则来约束大家的行为，并且需要制定基本的管理流程来支持整个团队的工作运转

权利矩阵示意图

被管理

自管理

自设计

自治

采取什么风格的领导力

Scrum Master属于服务型领导

每位员工对于任何一个工作领域都可能处于四种不同的发展水平（被领导者所处的发展水平）

D1：能力弱，意愿高

D2：能力弱至一般，意愿低

D3：能力中等至强，意愿不定

D4：能力强，意愿高

根据被领导者所处的不同发展水平，领导者应采取不同的领导风格

S1：指令型

能力弱、意愿高阶段，应采取高指导、低支持的策略，与员工交互的方式更多是告诉他做什么、怎么做、何时做

S2：教练型

能力弱至一般，意愿低阶段，适合采用”高指导、高支持“策略，不仅要告诉员工做什么、怎么做，而且要在调动员工的积极性上多下功夫

S3：支持型

能力中等至强，意愿不定阶段，适合采取”高支持、低指导“策略，注意多支持员工的工作，稳固员工的积极性。

S4：授权型

能力强，意愿高阶段，适合采用”低指导、低支持“策略，对应这样的员工，你可以大胆的放权让其工作。如果每个员工都处于这个阶段，领导者的工作与生活就会变得非常轻松

统一目标：让大家齐心协力

设立目标

团队自治与统一目标的关系

领导者需统一组织的目标，目标需具备以下特点

要有高度

企业目标高于任何部门的目标

部门目标高于任何子部门目标

团队目标高于团队里任何人的目标

以客户为中心设立目标，而不是以自己为中心设立目标

以客户为中心的目标会牵引整个组织将注意力转向外部，胜过将注意力放在内部优化，以及部门之间、团队之间的利益争夺上

即使是组织内部需要优化，也是从外部目标分解而来

要足够远大

要现实

设计一个实现目标的路线图

需注意几个问题

不要设立太多目标

不要用目标恐吓团队

不要频繁更换目标

实现目标

为了确保团队高效的达成目标，需注意以下几个实操点

保持团队稳定，不要将团队拆来拆去

塔克曼阶段理论，任何一个团队都会经历以下四个阶段

形成期

震荡期

规范期

成熟期

如果一个团队被拆散并重新组建，势必重新经历这四个阶段

保护团队不受打扰、不被中断

只有团队里的每个人将时间和精力集中在团队的共同目标上，才有可能高效的实现组织目标

Scrum Master具有”牧羊犬“的职责，负责保护团队不受外界干扰

组织的领导者同样承担了整个组织的”牧羊犬“职责，负责保护整个组织不受与目标不相关的事情的干扰

实施基于数据的透明、量化的管理

组织需要掌握实现目标的进展，从而及时采取措施予以调整，需要有透明的可量化的数据

培养能力：让团队卓越起来

为了打造卓越团队，领导者在实操层面可以尝试以下实践

向团队明确责任

团队成员的能力提升是个人的责任，不是公司的责任

招聘时把好关

宁愿招聘能力偏弱一些，但有学习热情的人

与员工制定”一对一“的个人成长计划

为实现马斯洛需求理论的最高级需求-自我超越

制订组织的整体能力发展计划和衡量体现

技能水平数据库，可供查询

让员工感受来自同行的压力

采取措施让团队看到榜样的力量，让员工知道山外有山，人外有人

结构成长：建立敏捷型的组织结构

在瞬息万变的环境里，企业需要建立快速交付产品价值、容易适配业务变化的组织结构

敏捷性组织结构需满足以下四个条件

以客户和市场为中心

什么样的业务决定了企业搭建什么样的组织结构

围绕产品价值流，搭建跨职能团队

对于一个从零起步开展敏捷转型的企业，一步就做到完全跨职能并不是一件容易的事，那么企业该怎做呢？

阵型1：研发部门内部角色融合：打破设计、开发、测试部门之间的壁垒，组建研发部门内部的跨职能团队

阵型2：将研发、产品、市场等角色融合，组建了跨职能团队

阵型3：针对互联网产品，实施产品自运营、自运维、打破了研发、市场、运维部门之间的壁垒，从而组建了跨职能团队

阵型1的组织努力向阵型2发展，而阵型2的组织发展目标是阵型3，从而逐步实现所有的业务线都以跨职能团队为最小组织单元

及时调整组织结构，不拖延

一般来说，当组织里的人数增长了50%以上时，领导者应考虑调整组织结构，让组织不因人数的增长而降低了沟通效率

不让沟通效率因组织规模的扩大而降低

随着组织规模越来越大，如何继续保持高效的沟通与协作呢？

将信息透明化，如Scrum方法和看板方法

将项目信息、价值流动过程、项目的状态高度透明化

建立知识共享机制

知识和经验的共享平台

去中心化

提高审批效率

全面改进：持续提升组织能力

这一步的核心是建立组织的Kaizen机制

领导者需要在组织里建立多层Kaizen环，全方位地拉动全员持续改进工作

组织的最高管理者负责组织层Kaizen

由研发中心的最高领导CTO带领管理团队负责整个中心层面的持续改进，运用PDCA思想，并采取第四章介绍的组织级改进措施

成立敏捷转型委员会

建立组织级改进Backlog

管理层亲自深入团队做Gemba Walk

建立敏捷实战社区

发布火车工程师负责产品层Kaizen

在很多企业里，很多产品由多个Scrum团队共同协作完成，交付产品的组织是项目群（Program），采用的是规模化敏捷框架SAFe，Program管理采用的是SAFe里的敏捷发布火车模型。每个敏捷发布火车由一位发布火车工程师负责整个Program的持续改进，且采用敏捷发布火车自带的改进环机制，帮助整个Program持续提升组织能力

Scrum Master负责团队层Kaizen

SM负责其所在的Scrum团队的工作方式的持续改进，采用Scrum框架自带的改进环机制，促使团队能力持续提升

多层Kaizen机制最重要的是每层机制之间需要有自内环向外环延伸的反馈机制，以及自外环向内环深入的信息沟通机制

1、在每个Scrum团队的回顾会议上，团队成员提出的需要由产品管理层或研发中心管理层帮助解决的事项，应由SM负责向上反馈并推动解决；
2、对于产品层来说，每个Scrum团队通过每日的Scrum of Scrum向产品管理层反馈需要帮助解决的阻塞事项；
3、在产品层的项目群增量（Program Increment，简称PI）回顾会议上，项目组成员提出的需要由研发中心管理层帮助解决的事项，应由发布火车工程师负责向上反馈并推动

除了多层Kaizen环机制外，组织里的任何团队、任何产品、任何部门都可以采用以下实践方式来持续改进工作方式：

举行定期回顾会议

建立组织需要改进的Backlog，并定期跟踪改进事项的进展

映射价值流，并持续优化价值流

成立敏捷实践社区

定期举行组织级运营评审会议

1、敏捷转型不易，但它是必走之路

为什么一定要实施敏捷转型

敏捷给企业带来的收益

增强了应对需求变更的能力

提高了团队的交付效率

提升了项目的可视化程度

敏捷是必然趋势

软件作坊

软件工程化

敏捷和精益

缺点1：耗时长，但是最终交付的产品与客户的期望偏差很大

缺点2：无法根据市场的变化动态调整产品

缺点3：质量反馈严重滞后，软件的变更成本高

精益软件开发原则

优化全局

将整个价值的创造过程进行改革，消除浪费环境，优化全价值流，提升整体价值流程的效率，才能最大化的提升组织的效率

以客户为中心

赋能工作者

减少浪费

增强学习

加速流动

质量内建

持续改善

敏捷转型是一项艰巨的工作

典型的失败模式：船货膜拜（指那些浮于科学调查和研究的表面形式，却丧失科学本质的伪科学）

敏捷转型会遇到那些困难

改变组织文化的能力

组织现有的瀑布式流程

没有足够的敏捷经验

没有足够的管理层支撑

业务人员/用户/客户没有参与

管理者担心失去控制

管理者担心缺少提前计划

对敏捷方法是否可以规模化缺乏信心

担心组织不具备规模化敏捷的能力

没有什么障碍

转型耗费时间和成本

缺乏开发团队的支持

与公司必须遵守的规范相违背

敏捷转型不是一场普通的变革

敏捷是没有终点的

敏捷没有统一的成熟度模型或评价体系

敏捷属于侵入式变革

敏捷对组织里每个角色的工作方式都有很大的改变

敏捷转型具有不可预测性

敏捷转型最终是对人与人以及人与人之间交互方式的改变

敏捷转型没有标准的模板，也没有最佳实践

同行的敏捷实践具有参考价值但不具有复制价值

如何系统化地转型

敏捷转型的3个阶段

实践敏捷

敏捷方法论应用比例来看，Scrum应用最为广泛，其次是多种方法混合应用、Scrumban、Scrum与极限编程混合应用、看板等

敏捷管理实践

广泛应用的是Scrum框架和精益看板方法

大型组织转型，有SAFe、LeSS和DAD等规模化敏捷框架

敏捷工程实践

TDD

结对编程

BDD

涌现式架构

架构重构

持续集成

敏捷测试

持续交付

DevOps

敏捷产品实践

精益创业

原型和用户画像等工具

设计思维

精益用户体验设计

影响地图和用户故事地图

思想敏捷

敏捷宣言

个体和交互高于流程和工具

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

客户合作高于合同谈判

响应变化高于遵循计划

从敏捷价值观中可看出以下内涵

敏捷以“人”为中心

敏捷以“价值”为驱动

敏捷鼓励与客户密切合作

敏捷积极地拥抱变化

敏捷原则（12条）

我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意

欣然面对需求变化，即使在开发后期也一样，为了客户的竞争优势，敏捷过程掌控变化

经常交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期

业务人员和开发人员必须相互合作，项目中的每一天都不例外

激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标

不论团队内外，传递信息效果最好、效率最高的方式是面对面交谈

可工作的软件是进度的首要度量标准

敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维护其步调稳定延续

坚持不懈的追求技术卓越和良好设计，敏捷能力由此增强

以简洁为本，它是极力减少不必要工作量的艺术

最好的架构、需求和设计出自自组织团队

团队定期地反思如何能提高成效，并依此调整自身的举止表现

文化敏捷

达到文化敏捷的团队会得到很大的收益

客户满意

工作开心

团队凝聚力增强

创新和创造力提高

持续学习

敏捷项目失败原因中占据首位的是企业文化与敏捷的核心价值观相左

组织文化模型

协作型

控制型

技能型

培养型

敏捷最核心的文化是协作型，其次是培养型文化

敏捷是以人为中心的文化

敏捷转型系统思考屋

转型目标：为什么要实施敏捷转型

通过敏捷转型，企业可以持续不断地在短周期内以低成本为客户交付高质量的产品和服务

敏捷转型开展前，企业领导者需向每一名员工清楚描述：我们为什么要实施敏捷，实施敏捷转型后企业要达到什么样的状态

转型核心：以人为核心

敏捷转型要以人为本，要识别出对转型至关重要的角色，哪些人会起到排头兵的作用，哪些人可能会拖后腿，并围绕这些人展开转型工作

转型策略：如何开展敏捷转型

开启转型前要制定转型策略

企业敏捷转型的路线图

思考如何选择试点团队

何时引入技术实战

如何一步步带领全员实施敏捷转型

如何巩固敏捷转型成果并最终将敏捷融入企业文化

转型方法与流程：将敏捷与精益实践落地

转型数据反馈：敏捷与精益数据分析框架

通过数据来量化并展示敏捷转型的进展和当前的问题，需掌握精益数据分析框架并在实操层面学会对重要的度量数据进行分析，才能采取有针对性的改进措施

转型基础：敏捷领导力

2、变革要以人为本

敏捷需要全员参与

不同角色对敏捷的误解

高管：敏捷是一种项目管理方法，让下面的职能经理及项目经理们搞敏捷就可以了

职能经理：我们经理层都懂敏捷，但我们不干具体的活，团队自己搞就可以了

开发工程师：领导怎么搞，跟我们没关系，我干我的活，领导让干的时候咱再动

产品经理、用户体验设计师：敏捷是研发团队的游戏，我们该咋干还是咋干

测试工程师：敏捷只在开发团队里转，咱们该怎么测就怎么测

不同角色参与者都需要作出改变

高管

需要深入理解敏捷，是组织转型的领导者和最终负责人

职能经理

实际上很多企业里成为转型障碍的往往就是职能经理，避免吆五喝六地指挥团队怎么工作、周报、日报以及用旧的度量体系衡量团队的工作进展

开发工程师

是产品每一行代码的真正交付者，交付方式、沟通和协作方式将会彻底改变，避免：闷头憋了好几天提交一次代码，未经自测便直接扔给测试，测试提交了BUG也不着急解决

产品经理

需求提供方式必须改变，不能再把几十页的需求文档扔给研发团队，然后就再也见不到人，需要与团队一起梳理需求，并对他们进行拆分和优先级排序，更重要的是，你需要每天都能让研发团队找到你

UX设计师

设计节奏要跟随团队的迭代节奏而快速迭代

测试工程师

避免每日闷头用手测试、提交BUG的生活

测试经理

提高产品测试自动化成熟度，避免测试人员与开发人员比例高

测试活动一定要逐步在团队里完成，而不是单靠测试部门来把质量关

敏捷发展到最终的境界，就是测试部门逐渐消亡

敏捷对不同角色参与者的价值

每个参与转型的人要的不是变革本身，而是变革给他们带来的价值

高管：转型成功会获得敏捷转型带来的收益，实现变革愿景

职能经理：如果部门转型成功，团队会通过自我管理、主动协作来解决问题，并且会在自己的职责范围内敢于决定和承担结果，会发现由团队逐渐产生的由内而外的驱动力激励他们工作

开发工程师：自己的工程技能得到了极大的提高，工作效率得到极大的提升

产品经理：1、可以看到自己提的需求在每个迭代产品中落地，可以在每个迭代结束后变更需求或提出新的需求，团队可以马上落实到产品中，让产品与市场或者用户当下的需要更加匹配，团队协作更加紧密，团队更懂需求，更懂你，也更懂用户；
2、会发现现在做的无价值或者低价值的需求比从前少了很多，而商业价值更高的需求占比高了很多

UX设计师：减少大量虽然精致美丽缺没有在团队中落地而浪费的设计稿，会为能够频繁获取用户到你的设计的反馈而兴奋

测试工程师：测试工作会大大提前，全程参与需求讨论，增加了测试对产品的话语权，测试效率会极大提升，工作从手工为主转变为全部为自动化为主，而将精力放在测试的设计、需求反馈及自动化测试开发上

识别敏捷转型的中坚力量

敏捷转型是一场漫长、艰苦的变更

敏捷转型的中坚力量有：

部门主管

理解敏捷、拥抱敏捷思想、改变管理模式、对敏捷转型的具体事项进行授权、是敏捷转型的首要领导者，需掌握如何系统化的为自己的组织策划敏捷转型，并建立强有力的变更团队来实施组织转型，实际上也承担了”敏捷教练“的职责

项目经理、项目组组长

传统项目经理采用计划驱动的方式，即项目范围是固定的，依据项目范围计划人力和进度

敏捷项目管理的核心一直是采用价值驱动的方式定义产品愿景，形成产品待办事项列表，再依据商业价值为产品待办事项列表排序，在做产品的过程中依据市场的最新动向来随时调整产品待办事项列表，从而确保团队在任何时候做的都是与市场最适配的产品

从流程的角度看，需要打通整个产品线，让产品经理、UX设计师、开发工程师、测试工程师、运维工程师等打破上下游职能间的壁垒，应用敏捷方法密切协作，从而实现整个产品线聚焦产品价值、快速交付的目的

需要转型为新的角色，如Scrum Master（简称SM)

这些角色的顺利转型是组织应用Scrum方法成功的必要条件

PMO、质量与流程部门人员

敏捷队伍的排头兵

这个群体非友即敌，在敏捷转型中必须充分发挥其正面作用

产品管理团队

从产品价值流的源头开始敏捷起来

如果是采用Scrum框架，产品管理团队的成员应该转型为Scrum里的产品负责人

培养敏捷转型的催化师：敏捷教练

为什么需要敏捷教练

企业应用敏捷，远不只是一些实践，更是一场思想、方法甚至文化的变革

需要专业的外部或内部的敏捷教练帮助组织将敏捷的理念和方法落地

敏捷教练的职责

打造自我思考、不依赖你发号施令的高效能敏捷团队

敏捷教练的能力模型

掌握敏捷与精益实践

引导技能和专业教练技能

需要引导各个团队及其成员凝聚组织目标，激发每个人潜能，为实现组织目标积极贡献自己的想法和力量

连接不同角色、不同成员的智慧，收集大家意见，意见有分歧的时候引导大家高效达成共识，因此需要具备一定的引导技能

指导和讲授能力

传道授业能力，为企业各个团队乃至全员培训敏捷知识，针对团队特点和不同角色，结合团队敏捷流程指导团队自我成长

企业转型能力

帮助企业识别敏捷转型涉及的关键角色，策划敏捷转型路线图，选择敏捷转型试点团队，辅助管理层领导并推进敏捷转型，辅导团队开展敏捷实践，帮助组织分析敏捷转型数据并制定改进措施，辅导领导者向敏捷领导力转型

精通产品和业务

会让他与团队有共同语言，便于开展工作，不是必备能力

敏捷教练要有强有力的教练职业立场

保持中立

不受别人的牵制和影响

在组织不适合引入敏捷时，不应该引入

服务客户的议程

敏捷教练的客户包括个人、团队、组织甚至整个企业

尊重客户自己的选择和决定

减少客户对你的依赖

努力帮助客户创建一个自我监督、自我纠正和自我持续成长的敏捷型组织

不粉饰问题

如果客户不敏捷，敏捷教练不能帮助客户假装说自己敏捷

有自己的声音

要提出自己独到的见解，表明自己的真实立场，不跟风

3、万里征途，如何迈出转型第一步

设计敏捷转型的路线图

第一阶段：团队级敏捷

指以5~9人的小团队为单位开展敏捷转型

每个团队各自独立交付产品，彼此之间不一定需要有关联

团队级敏捷的实践一般包括：

Scrum或者看板方法

持续集成

涌现式架构设计

领域驱动开发

行为驱动开发

自动化测试

结对编程

测试驱动开发

如果单个敏捷团队可以独立发布产品，可能会进一步尝试一些工程技术实践

微服务

持续交付流水线

自动化运维

关注单个团队的效率、质量和士气等

第二阶段：产品级敏捷

这个过程跨越了市场、产品、研发、设计、生产、销售、运营等多个部门

以整个产品的价值流为单位开展敏捷转型

关注的是一个产品或者产品每个版本的TTM（上市周期时间），旨在拉通产品价值流的上下游，将相互依赖的团队纳入同一个敏捷框架里，在需要的情况下调整组织架构、让价值流的每个团队协同交付，最大限度的减少交接、等待，去除价值流动过程中的浪费，从而缩短TTM，并通过缩短产品的质量反馈时间来快速提高产品质量，最终提升客户满意度

在整个产品范围内，团队一般会尝试一些规模化敏捷和精益实践以及工程技术实践，规模化敏捷和精益实践包括

价值流映射（Value Stream Mapping，简称VSM）

精益看板方法（Lean Kanban）

投资组合规划和管理

ART的组织架构及其流程

Scrum of Scrums

工程技术实践包括

主干开发

微服务

持续交付流水线

自动化运维

不是每个企业都需要经过团队级敏捷->产品级敏捷这两个阶段，一般对于几百人、上千人甚至上万人的大型产品线，需要经过这两个阶段

另一种转型策略：直接从产品级敏捷开始自上而下转型，即：以整个产品为单位试点转型，转型的第一天开始，将产品价值流涉及的上下游团队都纳入敏捷转型范围，调整组织架构，组建Scrum团队，导入敏捷思想和实践。优点：速度快，能够让管理层看到立竿见影的变化。采取这个策略的先决条件：领导需要有足够的魄力决定在整个产品级组织范围内转型。需要配敏捷教练，敏捷教练需深入每一个试点团队辅导，又要对整个产品级团队进行辅导和推动

第三阶段：企业级敏捷

经历了团队级敏捷->产品级敏捷，产品从无到有，直到产品发布的这个过程都已纳入敏捷范围，但这还不够，那些主持部门，如人事、行政、财务、市场、销售等部门也应该被纳入敏捷转型的范畴，他们现有的流程不能与敏捷相抵触，否则会成为组织转型的重力，拖累组织转型的步伐。比如服务器需要扩容，申请一台大容量的服务器需要七级审批流程，审批完后还需要至少3个月的时间，这样的效率严重拖累了产品交付效率

以客户的视觉来审视支持部门的效率和工作方式，考虑如何提升这些支持部门的敏捷型

先试点后全面铺开

创新接纳曲线

技术爱好者

产品尝鲜者

早期大众

晚期大众

怀疑主义者

企业选择合适的试点团队，进入”早期市场“做出效果证明给那些实用主义者和保守主义者，才能吸引”主流市场“，拥抱敏捷

敏捷不是一个通用的标准，在不同的企业里甚至在同一家企业的不同组织，落地的实践方法都可能会不同。通过试点，可以探索出敏捷在本企业、本组织如何应用，从而为后续开展敏捷的团队提供参考

如何选择试点团队？

项目规模

独立、规模在5~9人的团队

如果没有小规模的项目，可选择大项目中的一个小团队做试点

业务人员的参与度

具有产品决策权的人应该参与到Scrum流程中承担产品负责人的角色

项目周期

周期不能太短，团队组成比较固定

一般一个迭代的时间才能看到一个透明化、沟通协作高效、士气高昂的敏捷团队

如果通过数据量化看结果，则需要4-6个迭代的时间，待团队的迭代速率稳定后，团队效率才可能会有所提升

项目重要性

选择在主业务航道上重要程度为中等的项目做试点，但不要选择最关键的项目（对企业生死攸关的项目）或处于救火状态的项目

物理距离

尽量选择团队能在一起的项目，不要选择团队分布式的项目，除非这些团队是企业的主流团队

项目类型

最好选择新产品开发的项目，而非维护类项目（往往不能够引入太多的变化，无法用敏捷的方式实践新的想法从诞生到上线的整个过程）

优选项

选择纯软件项目试点，试点后再考虑硬件项目

试点团队何时引入技术实践

渐进式引入新事物的方式

第一个迭代不尝试任何技术实践，只引入Scrum或者看板方法

通过迭代回顾会议总结出需要开展的很多技术实践，引入一个技术实践，让大家深入掌握后，再引入下一个技术实践

4、领导组织转型的八个步骤

建立变革的紧迫感

从唤醒领导变革意识开始

与企业的竞争对手对比

分析业界趋势

敏捷与精益是大势所趋

导入意识

知识赋能

培训

他山之石

邀请业界知名的敏捷专家到企业里做专场分享（外来专家的分享所产生的信服力远大于企业内部员工所做的分享）

走出去，打开眼界

敏捷转型的推动者，可以引导组织的管理层、试点团队等经常参加业界各种与软件工程、敏捷和精益、DevOps相关的会议，触动大家的思考，同事获得其他企业一手的实战经验，在自己的企业里借鉴应用

让管理层产生危机感

转型迫在眉睫

怎么做？

一份数据报告

一个讲座

一次培训

组建强大的转型领导联盟

什么是敏捷转型委员会

从决定转型的第一天起，就应该成立敏捷转型委员会

由高层领导作为发起人任命委员会成员，一定需要最高管理层的参与，否则难以推动变更

敏捷转型委员会职责有:

设定敏捷转型的目标，并为敏捷转型的结果负责

向全员沟通敏捷转型的愿景，确保全体员工理解转型的紧迫性

成立敏捷教练团队，为管理层、试点团队提供敏捷知识的导入和实践能力的辅导

为各个敏捷团队提供障碍解决通道，即团队暴露出来的超出自己控制范围的组织层面的障碍，将上升到敏捷转型委员会解决

设计敏捷转型路线，推广敏捷转型的成果，扩大转型范围

敏捷转型委员会的构成

发起人：组织的高层领导，他需要对组织转型的结果、投资回报率负责

发起人需对敏捷转型高度支持，这种支持是身体力行地在行为中得以体现，以影响组织中的所有人，比如他需要有时间参与敏捷转型委员会的例行会议，并在需要时提供资源、作出决定以支持转型的开展

一般需要任命一位负责人来推动日常敏捷实施并移除组织转型障碍，此人就像Scrum团队中的Scrum Master，至关重要，理想情况下他需要具备如下条件

对新思想、新方法有很大的学习和尝试的热情

具有强烈的紧迫感

人脉广泛，在组织里具备强大的影响力

坚韧不拔，有耐心，遇到阻碍不妥协，遭到批评和指责不气馁

自身的领导风格属于教练型领导，而不是命令控制型领导

拥抱敏捷领导力的理念，在行动上实践敏捷领导力，是其他管理者学习的典范

应该找什么样的人来组建这个团队呢？？

对企业或所在组织以外的情况有一定了解的人，而非只埋头关注自己组织的人

在组织内部有一定的可信度、社会关系和权利地位的人

熟悉企业内部运作机制和研发流程的人

具备正式权威的人

具备沟通愿景和激励团队等领导技能的人

大型企业中，敏捷转型委员会可以包含多个团队

每个职能部门的经理

产品部总监

项目总监

PMO总监

试点团队的SM或团队领导者

敏捷转型委员会的运作方式

建立并维护组织企业转型的Backlog，并定期会晤，跟踪Backlog的进展

凡是与转型有关的一切事情都可以列入Backlog，由转型委员会排优先级

迭代式发展，持续检视和调整转型过程

树立转型的愿景和战略

为什么要树立愿景

转型发起人需向管理层及每一位员工清晰地描绘出开展敏捷转型的愿景是什么

为什么要实施敏捷

通过敏捷，未来想要达到什么样的状态

愿景描述企业未来的画面，提示出人们应该为这样的未来努力的理由

常踩的坑

任由其发展

发号施令

微观监督控制

如何制定转型愿景

有效的愿景应符合以下几个特点

可想象的

描述了未来式什么样的美好画面

值得做的

以员工、客户、股东等公司的利益相关者的长期利益为诉求

可行的

现实的，可实现的目标，可感知的目标，如三年内实现研发效率翻倍

聚焦的

对于决策制定起到清晰的指导作用

灵活的

允许在条件变化的情况下，推行个性化的创新计划及采取不同的应对措施

易于沟通的

能够在5分钟之内解释清楚

沟通转型的愿景

保守型企业选择的沟通策略

适合自身企业文化

选取试点团队并保持低调，不引起非试点团队部门主管的注意，待试点效果明显，再扩大规模

弊端：发展速度慢，试点团队不一定会认真对待，觉得只是试试而已，无法成立正式的敏捷转型委员会，只能搞个非正式组织，在一定范围内偷摸开小会

开放型企业选择的沟通策略

如果企业文化不抵制新事物，则可通过敏捷转型委员会通告全员（敏捷动员会）

我们面临什么样的紧迫性

为什么要转型

转型为了实现什么样的愿景

沟通愿景时要注意的问题

表达要简单

重复重复再重复

再三重复，解答大家的疑问，并不厌其烦

利用多种传播媒介

企业论坛

企业OA

敏捷宣传海报

电子宣传海报

敏捷转型委员会与各层管理者开展”一对多，一对一“的对话

倾听反馈

大家是否听懂了，有什么困惑或担心

领导层要发挥榜样作用

授权赋能，移除障碍

自上而下还是自下而上

需要自上而下地设计和沟通愿景，以及授权赋能并移除障碍，充分发挥每个敏捷团队、每个员工自下而上的力量

授权赋能的方法

建立敏捷实践社区

虚拟组织：Scrum论坛、持续交付俱乐部、测试自动化社群等

是由企业员工自愿组织的兴趣社团，本着交流敏捷实践、提升企业的敏捷能力为目的

是敏捷转型委员会Backlog中的一项，可以由企业员工自己主动认领（但不应该由领导自上而下任命组建）

可以由企业员工凭兴趣自发组建

组织的民间力量（敏捷转型委员会是组织的官方力量）

提供培训和辅导

重点针对以下角色辅导

每个试点团队的SM和产品负责人

职能经理层

开发和测试

敏捷教练的辅导可以从以下几个维度开展

对试点团队的辅导，要遵循试点团队的迭代周期，迭代计划、每日站会、每日开发工作、迭代回顾和评审都是可以辅导的时间点

对管理层的辅导，采取一对一的线下交流方式，敏捷转型委员会的例行会议上开展一对多辅导

对技术实践的辅导，要深入团队的每日开发和测试工作中，与团队坐在一起工作，便于开展辅导

对关键角色的辅导，如SM、产品负责人、职能经理等，采取一对一方式，视每个人的实际情况辅导

敢于解除与敏捷转型相左的流程桎梏

敢于改变组织现有体制中与敏捷转型相违背的流程，哪怕要承担风险，面对抵触和指责

转型委员会需针对每个冲突情况分析风险和代价来决策

积累短期成效，持续改进

当心挫伤期

学习和试验期的企业，其绩效会在短周期内下降

快速取得短期成效，能给拥抱敏捷的人带来信心，也会影响哪些悲观消极分子的态度，消除人们心中的疑虑，为开展敏捷转型建立必要的士气

积累短期成效的策略

尽早创造出第一个成效

第一个迭代的评审会上，演示迭代完成的特性，对利益干系人产生一定的震撼力，让其看到团队的交付成果

第一个迭代结束后，记录团队速率并呈现给利益干系人和管理层，让其看到价值产出效率

每日站会上，邀请一位管理者走到团队背后摸摸观摩站会，ta可以从看板上看到项目状态和风险，且每个工程师都主动在站会上反馈任务进展及遇到的障碍，这种积极的沟通方式也是前所未有的

在第一个迭代的回顾会议上邀请一位管理者默默观摩，让其感受团队主动反思改进的精神

让尽可能多的人看到成效

用量化数据证明成效

将数据呈现给各级管理层

扩展敏捷转型的范围和深度

拓展组织转型的范围

明确转型的责任主体

如果同一企业内部的组织A扩展到组织B，则负责B转型的总负责人应该是该组织的最高领导，而不是企业最上层的某个敏捷推动机构（如PMO)，因为它对组织B没有实权，所以应该组织B建立自己的敏捷转型委员会，由其承担转型的责任

不可一蹴而就

先试点再全面实施

横向跨组织传播敏捷种子

持续加强敏捷转型的深度

组织仍旧需要牵引每个敏捷团队进行自我改进、持续提升

将敏捷融入企业文化

理解企业自身文化

潜移默化地牵引思想的改变

巩固敏捷转型成果

新员工培训计划中纳入敏捷培训

根据敏捷转型路线图（团队级敏捷->产品级敏捷->企业级敏捷），牵引那些已经初见成效的团队和组织走向更高一层的敏捷

企业的最高领导者要保持危机意识，此外，最高领导者要让其下属的各层组织管理者保持危机感，让每个组织紧密跟踪业界的新型研发能力和技术，持续学习和尝试，从而保证组织的竞争力

5、Scrum还是看板：选择适合自己的敏捷方法

Scrum的精髓

Scrum的定义

3个角色

Scrum Master

产品负责人

开发团队

3个工件

产品待办事项列表

一份涵盖产品中已知所需每项内容的有序列表，是产品需求变动的唯一来源

Sprint待办列表

当前Sprint选出的产品待办列表项，以及交付产品增量和实现Sprint目标的计划

产品增量

团队在一个Sprint完成的所有产品待办列表项，以及之前所有Sprint所产生的增量价值的总和

5个事件

Sprint

Sprint计划

每日例会

Sprint评审

Sprint回顾

5个价值观

承诺

专注

开放

尊重

勇气

Scrum Guide指出：Scrum的角色、工件、事件和规则是不可改变的。从方法论的本质上，Scrum预定义了一个最小框架，这个框架里的元素不可缺少

Scrum的本质

三个拆分

拆分组织

把组织拆分成小规模、跨职能的自组织团队

拆分产品

把工作拆分成一系列小而具体的交付物，按优先级排序，估算每项任务的相对工作量

拆分时间

把时间拆分成固定大小的短迭代（通常为1~4周），在每个迭代结束时，对可交付的产品增量进行演示

两个优化

优化商业价值

在每个迭代结束后跟客户一起检查发布目标，并据此优化发布计划，更新产品待办事项列表的优先级

优化流程

每个迭代结束后进行回顾，对团队的实践过程做优化

看板方法的精髓

看板方法的历史根源

来源于日本丰田，意思是”信号卡”或“信号板”，用于下游向上游传递生产需要什么零件以及何时需要的信号

看板进入软件行业后，演进为一种在团队成员工作不过载的情况下，实现准时交付的管理方法

它将需求从定义到交付给客户的全流程可视化，并以拉动的方式处理

看板方法的4个原则

从现有的工作方式开始

实施渐进式变革

启动时，尊重现有的角色、职称和工作职责

鼓励各级领导力

看板方法不是一个预定义的框架，也没有固定的软件开发流程。团队可将看板方法的元素应用在现有的流程中，从而发现系统中存在的浪费、工作不均、团队过载、系统瓶颈及延迟交付的风险等问题，从而逐步引入改进措施

看板是经验式的渐进过程，有6大实践

可视化工作流程

限制在制品（WIP)数量，对每个流程中同时处理的在制品数量进行限制

度量和管理工作流：跟踪工作项是否以稳定、均匀的速度流动，如有前进不畅的情况，需要团队讨论，大家协作采取措施解决

显示化定义规则（如工作的流转规则等），并与利益干系人和团队就规则达成一致

构建反馈环，采用每日站会、持续改善、回顾会议等实践来构建反馈，持续改进看板系统

用科学的方法和模型评估改进机会，提升协作效率

Scrum和看板的区别

变更方式不同

Scrum-剧烈变革

需要拆分组织，成立跨职能小团队，任命新的角色

Scrum Guide对团队的定义：拥有完成工作所需的全部技能，不需要依赖团队以外的人

若采用Scrum方法，需要打破各个部门之间的壁垒，从涉及产品交付的每个部门抽出人员，组件能够不依赖于外部，可以独立交付产品增量的团队

看板方法-渐进式变革

看板方法不规定团队的组成、角色和责任分工

本身不规定具体的流程，几乎对任何工作方式都是开放的

它仅有的规范是讲流程可视化和限制在制品数量

看板方法从企业员工理解和分析现有的工作方式起步，再到应用看板的六个实践，逐步改进员工的工作方式

二者变革方式的差异，让那些稳不求变、不敢承担变革风险的企业更倾向于拥抱看板方法

基本流程不同

Scrum-时间箱

工作单位是时间箱固定的迭代周期，即对每个迭代周期都有明确的交付目标和需求范围，Sprint结束时要交付一个产品增量

固定时长的迭代是应用Scrum的前提

团队可以自己选择迭代长度，但一般都会在一定时间内让迭代长度固定不变，继而形成固定节奏

看板方法-工作流

看板方法的工作单位是一个个工作项，工作项是承载价值的单元，比如用户故事

看板方法没有规定固定时长的迭代，团队可以选择什么时候做计划、什么时候做回顾及什么时候发布产品

团队可以选择有规律的采取行动（如每周发布一次），或按需发布

看板方法的目标都是加速每个承载价值的工作项在看板上流动

因此，看板方法管理的是价值流

基于这个差异，维护类项目天然适合用看板方法，因为团队无法给维护类项目设置一个迭代周期，并且固定这个迭代的范围。即使团队做了Sprint计划，第二天也会被一堆更紧急的线上问题打断，导致原来的Sprint计划作废。此外，除了维护类项目，一些互联网团队为了快速响应业务变化，也开始打破时间箱的周期，转向看板方法

规则的显示化程度不同

Scrum-规则隐示化

Scrum流程

DoD来评估产品增量是否完成

Scrum Guide对DoD的定义是：当产品待办列表项或增量被描述为“完成”的时候，每个人都必须理解“完成”意味着什么

虽然DoD在不同的Scrum团队之间会有很大的差异，但是团队成员必须对“完成”意味着什么有相同的理解

Scrum对任务板的设计没有规定，团队可以自己设计，但是一般都是三列：准备好（To Do）、进行中（Doing）、完成（Done）

看板方法-规则显示化

价值流动的每个环节都被可视化在看板上，每个工作项处于什么状态一目了然

一个工作项从上游流转到下游需要达到什么条件有明确的规则，这个条件在看板方法里被称为“拉动条件”

这个拉动条件相当于被分解的DoD，只有价值流动的每个环节达到了拉动条件，才能最终保证整个产品增量达到DoD

看板方法对流程规则的显示化程度更高