敏捷转型：打造VUCA时代的高效能组织思维导图模板

看版指导(#7-4)

Gitlab看版

看版需要哪些要素

一目了然看标题知任务

清晰的标签定义和归类

泳道表达结合拉动模式

便捷的查询方式

顺畅的用户体验

为什么是看版而不是TODO？

大家看得见的任务才会有压力<br>

什么样的任务颗粒度适合放在看版？

2hr < load < 5day

看版只是当前状态，怎么解决？

人工/API记录进行累积图管理

看板实施总结

对于稳定的团队，团队看板胜于项目看板

导入期需要习惯将任务以卡片的形式表达并呈现出来

用户故事是打破开发、测试之间的界限，是需求的进阶表达

看版对我们的影响

不再发工作日报

从面向报告转为面向问题

工作量团队可见

任务有明确的生命周期

尊重用户原始需求

敏捷对我们未来的影响

注重CI/CD，提高价值流运转效率

接受持续迭代的开发模式并达到共赢

重视原始需求的描述，从实际场景出发解决痛点

适应新的软件开发模式更新管理流程

前言

时代特征VUCA

易变性（Volatility）

不确定性（Uncertainty）

复杂性（Complexity）

模糊性（Ambiguity）

如何应对

拥抱变化

应对复杂

迭代进化

快速交付

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

收益总结

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

提高了团队的交付效率

提升了项目的可视化程度

对软件产品的期望和要求

在短周期内迭代交付

持续不断地按需部署到生产环境

船货膜拜式敏捷

团队的组织结构仍旧是职能团队

团队的角色产品负责人不是来自于业务团队

关起门来自己创造并分析需求

会议主要进行任务分配没有进行密切协作和自组织

工程实践没有日常化

敏捷转型会遇到哪些困难

改变组织文化的能力

人们对组织变革的抵制

组织现有的瀑布式流程

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

敏捷是没有终点的

“持续改善”（Kaizen）

敏捷属于侵入式变革

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

敏捷转型具有不可预测性

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

敏捷转型的三个阶段

实践敏捷（Doing Agile）

敏捷管理实践

敏捷工程实践

敏捷产品实践

思想敏捷（ThinkingAgile）

敏捷以“人”为中心

敏捷以“价值”为驱动

敏捷鼓励与客户密切合作

敏捷积极地拥抱变化

文化敏捷（Being Agile）

最核心的是协作型文化

其次是培养型文化

第2章 变革要以人为本

敏捷转型的中坚力量

部门主管

项目经理、项目组组长

PMO、质量与流程部门人员

产品管理团队

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

打造自我思考，不依赖你发号施令的高效能敏捷团队

能力模型

掌握敏捷与精益实践

引导技能和专业教练技能

指导和讲授能力

企业转型能力

精通产品和业务

第3章 如何迈出转型第一步

设计敏捷转型的路线图

第一阶段：团队级敏捷

阻力

项目流程

管理和协作方式

实践

Scrum或看板方法

持续集成

涌现式架构设计

领域驱动开发

行为驱动开发

自动化测试

结对编程

测试驱动开发

微服务

持续交付流水线

自动化运维

第二阶段：产品级敏捷

以整个产品的价值流为单位开展敏捷转型

最大限度地减少交接、等待

规模化敏捷和精益实践

价值流映射（Value Stream Mapping，简称VSM）

精益看板方法（Lean Kanban）

投资组合规划和管理（Portfolio Planning and Management）

ART的组织架构及其流程

Scrum of Scrums

工程技术实践

微服务

持续交付流水线

DevOps

第三阶段：企业级敏捷

先试点后全面铺开

项目规模5～9人

具有产品决策权的人担任产品负责人

项目周期在4～6个迭代周期完成

不要选压力小的内部项目，也不要选生死攸关的项目

不要过多引入新的技术实践

第4章 领导组织转型的八个步骤

建立变革的紧迫感

组建强大的领导联盟

树立愿景

沟通愿景

移除障碍

计划并获得短期成功

巩固成果，持续深入开展变革

植入组织文化

第5章 Scrum还是看板：选择适合自己的敏捷方法

Scrum的精髓

三个角色

Scrum Master

产品负责人

开发团队

五个事件

Sprint

Sprint计划

每日例会

Sprint评审

Sprint回顾

三个工件

产品待办列表

Sprint待办列表

产品增量

三个拆分

拆分组织

拆分产品

拆分时间

两个优化

优化商业价值

优化流程

看板方法的精髓

四个原则

从现有的工作方式开始

实施渐进式变革

启动时，尊重现有的角色、职称和工作职责

鼓励各级领导力

六大实践

可视化工作流程

限制在制品（Work In Progress，简称WIP）数量

度量和管理工作流

显示化定义规则

构建反馈环

用科学的方法和模型评估改进机会，提升协作效率

Scrum和看板的区别

变革方式不同

Scrum：组建能够不依赖于外部，可以独立交付产品增量的团队

基本流程不同

Scrum：每个迭代周期都有明确的交付目标和需求范围

规则的显示化程度不同

运作单位不同

领导力不同

哪些项目适合Scrum，哪些项目适合看板

Scrumban

第6章 如何带领Scrum团队

组建Scrum团队

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

正确理解关键角色：Scrum Master

应该通过问问题的方式来引导团队思考

维护Scrum流程外没有其他权力

过程权威

负责保护团队不受外界干扰

清扫妨碍团队生产效率的一切障碍

教练的对象是产品负责人和产品开发团队

服务型领导（Servant Leadership）是领导力的一种

做组织变革的代言人是对Scrum Master最高的要求

Scrum Master是否可以兼职

为行使Scrum Master职责分配充裕的时间

角色切换时，明确此刻“我是谁”

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

做一名合格的产品负责人

首要责任是将产品的价值最大化

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

制定宏观愿景和进行长远规划的能力

沟通和谈判能力

洞察能力和创造能力

执行能力

团队工作协议

开场

几个字讲明该做什么，不该做什么

发散

默写工作建议

收敛

投票总结3～5条工作协议

承诺

没有异议后，团队共同承诺遵守

可视化

先期围绕站会来制定

工作协议需要与时俱进

把握Sprint节奏

设置合适的Sprint长度

不要推迟Sprint

DoD：怎样才算“完成”

夯实Sprint计划<br>

开展Sprint计划会议的步骤

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

产品负责人澄清产品需求

团队估算完成用户故事所需时间

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

拆分任务

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

承诺目标

避开每日站会的常见误区

时间误区

站会不是每天开

总是有人迟到

流程误区

只动嘴，不更新任务板

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

僵化站会的三个问题

领导力误区

团队向Scrum Master汇报工作

Scrum Master给每个同事分配任务

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

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

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

第7章 用看板加速价值流动

价值流映射

通过流程改进、组织调整等方法，减少等待、交接等非增值活动的时间

在第一步的基础上，提高团队的工作效率，缩短增值活动时间

价值流需要反映真实的价值流动过程，因为价值流映射是团队共创的

在知识工作领域，价值流映射只需四个步骤

分析工作项的类型

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

工作项的环节需要反映价值流的主体活动

价值流映射要体现出团队的真实价值流

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

估算每个环节的耗时

看板分级

团队级看板

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

职能型团队的管理范围只是价值流中的一段

产品级看板

在产品级看板上流动的是特性级大颗粒需求

服务级别及处理策略

服务级别

加急类

价值或损失极其重大，并随时间的变化持续攀升

价值或损失极其重大，并随时间的变化保持不变

固定交付日期

到截止日期后，价值或损失迅速上升，并随时间的变化持续攀升

到截止日期后，价值或损失迅速上升，并不随时间的变化而变化

普通类

投资类

看板可视化设计

定义过程改进的起始点和终止点

设计看板的列

设计看板的泳道

设计看板的工作项卡片

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

拉动式生产

Minimum Viable Product

限制在制品

缩短平均周期时间

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

如何限制和调整在制品

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

约定看板的工作节奏

构建三层反馈环

每日站会

站会以看板为中心

结果是更新看板

回顾会议

组织级运营评审<br>

第8章 用精益的方式做产品

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

浪费的代价

精益创业的反馈环

设计最小可行产品（MVP）

建立产品愿景

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

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

形成产品愿景

制订产品规划

卡诺模型

无差异属性（Indifference）

魅力属性（Attractive）

线性属性（One-dimensional）

必备属性（Must-be）

反向属性（Reverse）

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

洋葱圈规划法

敏捷需求管理

与传统需求管理的差异

需求所承担的作用不同

时限不同

需求的规模不同

参与人不同

优先级制定方式不同

保持产品Backlog的“深度”

D（Detailed Appropriately）：适度详细

E（Estimated）：估算好的

E（Emergent）：涌现的

P（Prioritized）：排好优先级的

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

Why：为什么要用“用户故事”描述产品需求

Who：哪些人创建用户故事

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

How：怎么创建用户故事

角色：谁要使用这个功能

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

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

故事需要满足

I（Independent）：独立的

N（Negotiable）：可协商的

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

E（Estimable）：可估算的

S（Small）：小

T（Testable）可测试的

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

定性评估法

延期成本

实现成本

风险和不确定性

依赖

定量计算法

让用户体验设计敏捷起来

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

正确发挥原型的作用

第9章 敏捷与精益数据分析

数据分析框架

度量价值

产品运营数据

访问用户量

新用户量

活跃用户量/活跃度

流失用户量

回访用户量

用户体验数据

H：愉悦感（Happiness）

E：参与度（Engagement）

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

T：任务完成率（Task Success）

度量效率

价值交付效率

速率

Sprint燃尽图

版本燃尽图

看板累积流图

看板周期时间分布图

工程效率度量

编译效率

版本构建效率

回归验证效率

全量功能验证效率

非功能性验证效率

度量质量

外部质量

用户满意度

产品的非功能性属性

缺陷密度

每千行代码的缺陷数

内部质量

代码质量度量

白盒测试覆盖率度量

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

度量学习和成长

发展组织能力

分配员工进新项目组

年度发展计划

组织级能力发展计划

发展团队能力

最好的敏捷团队是T型团队

每个人都有自己的专长，但也是个通才

评估敏捷转型的效果

面向结果的评估

定量评估

价值

效率

质量

学习

成长

定性评估

面向过程的评估

产品管理健康度（Product Ownership Health）

技术健康度（Technical Health）

潜在产品增量/版本健康度（Potentially Shippable Increment Health）

团队健康度（Team Health）

迭代健康度（Sprint Health）

第10章 敏捷领导力

敏捷领导力框架

激励员工

赋能团队

统一目标

提升能力

结构成长

全面改进

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

赋能团队：让团队自组织

被管理

自管理

自设计

自治

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

设立目标

要有高度

要足够远大

要现实

实现目标

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

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

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

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

向团队明确责任

招聘时把好关

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

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

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

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

以客户和市场为中心

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

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

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

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