敏捷转型：打造VUCA时代的高效能组织
2022-07-25 11:11:51 1 举报AI智能生成
《敏捷转型：打造VUCA时代的高效能组织》读书笔记
作者其他创作
大纲/内容
看版指导(#7-4)
Gitlab看版
看版需要哪些要素
一目了然看标题知任务
清晰的标签定义和归类
泳道表达结合拉动模式
便捷的查询方式
顺畅的用户体验
为什么是看版而不是TODO？
大家看得见的任务才会有压力
什么样的任务颗粒度适合放在看版？
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计划
开展Sprint计划会议的步骤
产品负责人陈述Sprint目标，讲用户故事
产品负责人澄清产品需求
团队估算完成用户故事所需时间
团队选取Sprint Backlog，调整Sprint目标
拆分任务
判断Sprint Backlog是否达到产能上限
承诺目标
避开每日站会的常见误区
时间误区
站会不是每天开
总是有人迟到
流程误区
只动嘴，不更新任务板
啥都谈，就是不谈障碍和风险
僵化站会的三个问题
领导力误区
团队向Scrum Master汇报工作
Scrum Master给每个同事分配任务
团队以外的人到站会上指手画脚
充分利用产品的反馈环：Sprint Demo
让Sprint回顾成为团队改进的发动机
第7章 用看板加速价值流动
价值流映射
通过流程改进、组织调整等方法，减少等待、交接等非增值活动的时间
在第一步的基础上，提高团队的工作效率，缩短增值活动时间
价值流需要反映真实的价值流动过程，因为价值流映射是团队共创的
在知识工作领域，价值流映射只需四个步骤
分析工作项的类型
列出选定工作项从诞生到交付的各个环节
工作项的环节需要反映价值流的主体活动
价值流映射要体现出团队的真实价值流
分析哪些环节是增值环节，哪些是非增值环节
估算每个环节的耗时
看板分级
团队级看板
跨职能团队来说，他们的看板管理的是端到端的价值流
职能型团队的管理范围只是价值流中的一段
产品级看板
在产品级看板上流动的是特性级大颗粒需求
服务级别及处理策略
服务级别
加急类
价值或损失极其重大，并随时间的变化持续攀升
价值或损失极其重大，并随时间的变化保持不变
固定交付日期
到截止日期后，价值或损失迅速上升，并随时间的变化持续攀升
到截止日期后，价值或损失迅速上升，并不随时间的变化而变化
普通类
投资类
看板可视化设计
定义过程改进的起始点和终止点
设计看板的列
设计看板的泳道
设计看板的工作项卡片
限制在制品，实现拉动式生产
拉动式生产
Minimum Viable Product
限制在制品
缩短平均周期时间
打破在制品堆积的恶性循环
如何限制和调整在制品
将实际的在制品数量作为限制的初始值
约定看板的工作节奏
构建三层反馈环
每日站会
站会以看板为中心
结果是更新看板
回顾会议
组织级运营评审
第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章 敏捷领导力
敏捷领导力框架
激励员工
赋能团队
统一目标
提升能力
结构成长
全面改进
激励员工：让每个人积极主动起来
赋能团队：让团队自组织
被管理
自管理
自设计
自治
统一目标：让大家齐心协力
设立目标
要有高度
要足够远大
要现实
实现目标
保持团队稳定，不要将团队拆来拆去
保护团队不受打扰、不被中断
实施基于数据的透明、量化的管理
培养能力：让团队卓越起来
向团队明确责任
招聘时把好关
与员工制定“一对一”的个人成长计划
制订组织的整体能力发展计划和衡量体系
让员工感受到来自同行的压力
结构成长：建立敏捷型的组织结构
以客户和市场为中心
围绕产品价值流，搭建跨职能团队
及时调整组织结构，不拖延
不让沟通效率因组织规模的扩大而降低
全面改进：持续提升组织能力
0 条评论
下一页
