敏捷转型：打造VUCA时代的高效能组织
2022-07-25 11:11:51 1 举报AI智能生成
《敏捷转型：打造VUCA时代的高效能组织》读书笔记
作者其他创作
大纲/内容
看版指导(#7-4)
一目了然看标题知任务
清晰的标签定义和归类
泳道表达结合拉动模式
便捷的查询方式
顺畅的用户体验
看版需要哪些要素
大家看得见的任务才会有压力
为什么是看版而不是TODO？
2hr < load < 5day
什么样的任务颗粒度适合放在看版？
人工/API记录进行累积图管理
看版只是当前状态，怎么解决？
Gitlab看版
对于稳定的团队，团队看板胜于项目看板
导入期需要习惯将任务以卡片的形式表达并呈现出来
用户故事是打破开发、测试之间的界限，是需求的进阶表达
不再发工作日报
从面向报告转为面向问题
工作量团队可见
任务有明确的生命周期
尊重用户原始需求
看版对我们的影响
注重CI/CD，提高价值流运转效率
接受持续迭代的开发模式并达到共赢
重视原始需求的描述，从实际场景出发解决痛点
适应新的软件开发模式更新管理流程
敏捷对我们未来的影响
看板实施总结
易变性（Volatility）
不确定性（Uncertainty）
复杂性（Complexity）
模糊性（Ambiguity）
时代特征VUCA
拥抱变化
应对复杂
迭代进化
快速交付
如何应对
前言
增强了应对需求变更的能力
提高了团队的交付效率
提升了项目的可视化程度
收益总结
快速交付、快速回馈
在短周期内迭代交付
持续不断地按需部署到生产环境
对软件产品的期望和要求
MVP(Minimum Viable Product)
团队的组织结构仍旧是职能团队
关起门来自己创造并分析需求
团队的角色产品负责人不是来自于业务团队
会议主要进行任务分配没有进行密切协作和自组织
工程实践没有日常化
船货膜拜式敏捷
不要为了敏捷而敏捷
改变组织文化的能力
人们对组织变革的抵制
组织现有的瀑布式流程
敏捷转型会遇到哪些困难
以终为始，先明确目标
“持续改善”（Kaizen）
敏捷是没有终点的
组织里每个角色的工作方式都有很大的改变
敏捷属于侵入式变革
敏捷转型具有不可预测性
敏捷没有标准的模板，也没有最佳实践
敏捷转型不是一场普通的变革
先转变理念，然后持续进行，不断受益
敏捷管理实践
敏捷工程实践
敏捷产品实践
实践敏捷（Doing Agile）
实践敏捷和敏捷转型是完全不同的两个层次
敏捷以“人”为中心
敏捷以“价值”为驱动
敏捷鼓励与客户密切合作
敏捷积极地拥抱变化
思想敏捷（ThinkingAgile）
先做思想铺垫，认同敏捷再实践敏捷
最核心的是协作型文化
其次是培养型文化
文化敏捷（Being Agile）
敏捷转型的三个阶段
第1章 敏捷转型不易，但它是必走之路
部门主管
项目经理、项目组组长
PMO、质量与流程部门人员
产品管理团队
敏捷转型的中坚力量
不论是否采用了偏平组织，每个角色都要发自内心的认同并参与敏捷转型活动中，哪怕是尝试的态度，否则就会固守已有工作模式而抵制变化，成为转型障碍，这与之前的理论相呼应，首先转变的是理念
打造自我思考，不依赖你发号施令的高效能敏捷团队
掌握敏捷与精益实践
引导技能和专业教练技能
指导和讲授能力
企业转型能力
精通产品和业务
能力模型
敏捷转型的目的不是经历过或是实践过，而是让参与者具备用敏捷的思维方式来思考，此时已不用讨论怎么做敏捷，因为团队可以自我思考，甚至不依赖外界指令而自发行动，引用之前章节的描述，终极目标是通过思想敏捷达到文化敏捷，而不是做过某某敏捷项目
培养敏捷转型的催化师：敏捷教练
第2章 变革要以人为本
项目流程
管理和协作方式
阻力
既然叫敏捷转型，就一定是相对于非敏捷的过去，在转型初期，原有的工作流程、管理方法和协作方式必然会变成阻力，此时需要做的就是勇于站出来建立新的、适于敏捷成长壮大的环境、制度，变革一定不会一次到位，但一定要迈出这一步
Scrum或看板方法
持续集成
涌现式架构设计
领域驱动开发
行为驱动开发
自动化测试
结对编程
测试驱动开发
微服务
持续交付流水线
自动化运维
实践
在团队敏捷实践方法中，最可行的、最能让产品团队快速获得收益的是持续集成、自动化测试和持续交付，自动化测试是持续集成的内在动力，是持续交付的可靠保障和信心来源，持续交付是持续集成的终极目的。
第一阶段：团队级敏捷
以整个产品的价值流为单位开展敏捷转型
最大限度地减少交接、等待
价值流映射（Value Stream Mapping，简称VSM）
精益看板方法（Lean Kanban）
投资组合规划和管理（Portfolio Planning and Management）
ART的组织架构及其流程
Scrum of Scrums
规模化敏捷和精益实践
工程技术实践
DevOps
第二阶段：产品级敏捷
软件过程中常会听到、看到信息流、数据流，如今在敏捷领域有一个无形的价值流，类比商业中的现金流，价值流的快速流动才会推动我们向\"更少需求、更大价值\"的方向转型，同时抛弃低价值产品和无价值需求，商业行为是趋利的，软件开发过程可以说应要趋价值，当今环境不是比能与不能，而是比创造价值的效率
第三阶段：企业级敏捷
设计敏捷转型的路线图
项目规模5～9人
具有产品决策权的人担任产品负责人
项目周期在4～6个迭代周期完成
不要选压力小的内部项目，也不要选生死攸关的项目
不要过多引入新的技术实践
先试点后全面铺开
试点项目需要关注书中\"先试点后全面铺开\"章节所介绍的规模、角色、周期、重要度及新技术等几个方面，更重要的是团队成员有一致的目标和价值观，即使没有敏捷这样的概念，也愿意通过主动承担额外的工作，为他人、为团队、为项目、为客户创造更多的价值，因为这样的团队已经具备思想敏捷的雏形，更易成功
第3章 如何迈出转型第一步
建立变革的紧迫感
组建强大的领导联盟
树立愿景
沟通愿景
移除障碍
计划并获得短期成功
巩固成果，持续深入开展变革
植入组织文化
第4章 领导组织转型的八个步骤
领导组织转型的八个步骤被强调说是有顺序，应需逐步执行，在此基础之上，个人理解树立愿景应置于建立领导联盟之前，敏捷转型的目标是思想敏捷、文化敏捷，深究其动力源泉是有共同的愿景去改善现状，只要达到效果，是不是敏捷都已不是关键，今天被冠以的名词是敏捷，以后或许还有别的，但只要有持续改善的追求和主观能动性，这些名词已不重要
Scrum Master
产品负责人
开发团队
三个角色
Sprint
Sprint计划
每日例会
Sprint评审
Sprint回顾
五个事件
产品待办列表
Sprint待办列表
产品增量
三个工件
拆分组织
拆分产品
拆分时间
三个拆分
scrum中的拆分不是目的而是手段，这一点在实践中才会有深刻体会，对于一个稍大的任务，通过拆分可以让团队看到其中尚未澄清的细节，并在分解用户故事至任务的过程中不断达成共识，对于需要探索的问题可以单独设置优先级较高的前置任务先行解决，可以看到，scrum不会让问题消失，但会让问题尽早暴露，尽量避免因任务执行中发现问题而导致人力的浪费。
优化商业价值
优化流程
两个优化
Scrum的精髓
从现有的工作方式开始
实施渐进式变革
启动时，尊重现有的角色、职称和工作职责
鼓励各级领导力
四个原则
可视化工作流程
限制在制品（Work In Progress，简称WIP）数量
度量和管理工作流
显示化定义规则
构建反馈环
用科学的方法和模型评估改进机会，提升协作效率
六大实践
看板方法的精髓
Scrum：组建能够不依赖于外部，可以独立交付产品增量的团队
变革方式不同
Scrum：每个迭代周期都有明确的交付目标和需求范围
基本流程不同
规则的显示化程度不同
运作单位不同
领导力不同
Scrum和看板的区别
敏捷落地的方法被归纳为Scrum和看板法，虽然两者被清晰定义，但最后也被作者说可以混用，而两者之和几乎涵盖所有情景，实际上，只要有对敏捷的愿景，属于哪一类已经不重要，甚至很有可能是一个项目在不同阶段采用不同的策略，而重要的是结果
Scrumban
哪些项目适合Scrum，哪些项目适合看板
第5章 Scrum还是看板：选择适合自己的敏捷方法
跨职能团队拥有完成工作所需要的全部技能，不需要依赖团队以外的人
组建Scrum团队
组建Scrum团队的重点是稳定的、全职能的、在能涵盖所有功能范围前提下规模尽可能小，参考康威定律，甚至可以先思考理想的软件架构是怎样的，然后再设计规划理想的组织架构
应该通过问问题的方式来引导团队思考
维护Scrum流程外没有其他权力
过程权威
负责保护团队不受外界干扰
清扫妨碍团队生产效率的一切障碍
教练的对象是产品负责人和产品开发团队
服务型领导（Servant Leadership）是领导力的一种
做组织变革的代言人是对Scrum Master最高的要求
为行使Scrum Master职责分配充裕的时间
角色切换时，明确此刻“我是谁”
Scrum Master要被正式任命，并在绩效目标里体现其工作职责
Scrum Master是否可以兼职
正确理解关键角色：Scrum Master
首要责任是将产品的价值最大化
与产品相关领域的知识能力
制定宏观愿景和进行长远规划的能力
沟通和谈判能力
洞察能力和创造能力
执行能力
做一名合格的产品负责人
产品负责人，之所以不是产品经理是因为其重要的职责是对产品负责，所以没有代表管理职能的经理头衔，开发团队需要围绕产品展开工作，而产品是团队的成果和目标，所以产品负责人首要职责是产品价值最大化产品负责人的责任就是将产品价值最大化，除了建立产品愿景、规划产品、交付产品，最重要的是管理产品待办事项列表，需要清晰表述产品待办事项列表、对列表进行优先级排序、保证下一个sprint的工作是确定且足够细化的、确保团队对产品待办列表项有足够深的了解
几个字讲明该做什么，不该做什么
开场
默写工作建议
发散
投票总结3～5条工作协议
收敛
没有异议后，团队共同承诺遵守
承诺
先期围绕站会来制定
可视化
工作协议需要与时俱进
团队工作协议
设置合适的Sprint长度
不要推迟Sprint
DoD：怎样才算“完成”
把握Sprint节奏
自动化集成、自动化测试、自动化部署三个环节对制定、遵守Sprint节奏至关重要，Sprint相当于软件开发中的节拍，具备紧迫感、可预测性、减少事务性成本的特点
产品负责人陈述Sprint目标，讲用户故事
产品负责人澄清产品需求
团队估算完成用户故事所需时间
团队选取Sprint Backlog，调整Sprint目标
拆分任务
判断Sprint Backlog是否达到产能上限
承诺目标
开展Sprint计划会议的步骤
清晰明了的用户故事有助于团队对需求的理解以及把控，在此基础之上的时间预估、任务拆分、目标承诺才有意义
夯实Sprint计划
站会不是每天开
总是有人迟到
时间误区
只动嘴，不更新任务板
啥都谈，就是不谈障碍和风险
僵化站会的三个问题
流程误区
团队向Scrum Master汇报工作
Scrum Master给每个同事分配任务
团队以外的人到站会上指手画脚
领导力误区
避开每日站会的常见误区
站会需要每天开，除非没有工作，内容在言简意赅的基础上还要以沟通障碍和风险为主要目的，站会的目的是让团队能自组织的运作，成员主动认领工作任务，相互带动，共同努力达成目标
充分利用产品的反馈环：Sprint Demo
让Sprint回顾成为团队改进的发动机
第6章 如何带领Scrum团队
Scrum Master应该是全职的，被周知的角色定义，并在绩效目标体现了这个工作职责，过程中扮演的维护流程的角色，并且为确保团队实施敏捷屏蔽外界对团队的干扰、扫清内部沟通的障碍、引导团队思考模式、以服务为宗旨的领导风格
SprintDemo是对产品的改进和调整，Sprint回顾是对团队工作方式的改进和调整。前者应该有产品负责人参加，先发生；后者视团队意愿决定需要谁参加，后进行。Sprint回顾会议可参考Start-Stop-Continue-Chang框架进行展开，主动性很重要
通过流程改进、组织调整等方法，减少等待、交接等非增值活动的时间
在第一步的基础上，提高团队的工作效率，缩短增值活动时间
价值流需要反映真实的价值流动过程，因为价值流映射是团队共创的
价值流映射
价值流是团队经过沟通确认后的共识，价值流动效率贯穿产品周期，相对于片面的追求开发效率而言，价值流动效率是更全面的增值效率。分析价值流的过程中，价值流映射的单元是价值，要以客户的视角进行思考该工作是否有价值，该过程以价值流活动为中心，不以人的角色为中心，在此基础上评判那些等待的、非增值环节
分析工作项的类型
工作项的环节需要反映价值流的主体活动
价值流映射要体现出团队的真实价值流
列出选定工作项从诞生到交付的各个环节
分析哪些环节是增值环节，哪些是非增值环节
估算每个环节的耗时
在知识工作领域，价值流映射只需四个步骤
跨职能团队来说，他们的看板管理的是端到端的价值流
职能型团队的管理范围只是价值流中的一段
团队级看板
看板管理中，参与团队级看板的团队应该是跨职能团队，即是完成某个特性的全职能团队，否则效果会大打折扣，为什么？因为看板所要管理的是价值流，提高流动效率，消除流动过程中各环节无效的等待，如果团队是职能型团队，等待环节被置于不可管理状态，价值流被割裂，脱离了实施敏捷的意义。
在产品级看板上流动的是特性级大颗粒需求
产品级看板
看板分级
价值或损失极其重大，并随时间的变化持续攀升
价值或损失极其重大，并随时间的变化保持不变
加急类
到截止日期后，价值或损失迅速上升，并随时间的变化持续攀升
到截止日期后，价值或损失迅速上升，并不随时间的变化而变化
固定交付日期
普通类
投资类
服务级别
投资类服务不直接产生价值或损失，对团队效率产生间接价值，如果一直不做会因积累而造成经济损失，这是对软件开发过程中技术债最恰当的定义，做了未必马上看到价值，但不做一定会有潜在影响，甚至在一些条件下转为紧急工作，所以不要轻视这些重要而不紧急的技术债，比如持续集成、自动化测试、代码重构。
服务级别及处理策略
定义过程改进的起始点和终止点
设计看板的列
设计看板的泳道
设计看板的工作项卡片
看板可视化设计
看板应具备可视化、端到端的全过程，为了体现拉动模式，看板中的列应具备“完成”子列，否则无法体现完成状态，从而让下游无法实现拉动；看板中的泳道应具备投资类服务专项，重要不紧急的事情更需要优先处理。
Minimum Viable Product
拉动式生产
缩短平均周期时间
打破在制品堆积的恶性循环
限制在制品
将实际的在制品数量作为限制的初始值
如何限制和调整在制品
限制在制品，实现拉动式生产
文中在看板推演软件拉动的过程无异于纸上谈兵，完全没有考虑软件开发的特性，那么如何实现拉动？实际上拉动本质是信息流与工件流是反向的，信息流的透明化才是减少在制品的根本，当下游工作完结时，上游可根据全局进展决定投入哪些适当的功能，确保每个工序尽可能无积压的开展工作，毕竟软件开发属于智力活动，不能避开其很难度量的特性。在特性功能、复杂度相当的前提下，软件团队交付特性的吞吐率是由团队自身特性决定的，增加人力或延长工作时间往往收到适得其反的效果，破局的解决方法就是投资敏捷技术实践，在自动化测试、持续集成、加速构建、持续交付、自动化运维等领域进行投资，着手重要但不紧急的事情会让我们少遇到些紧急事件降低软件在制品的方法就是缩短交付周期，也就是加快交付速度，尽早、尽快的得到客户反馈，避免一些“假设有价值”，“以为有帮助”的特性投入过多人力而导致浪费，在此过程中，除了软件功能，软件质量也需要快速交付而尽早得到反馈，往往质量问题越多，越拖延上线日程；上线间隔越久，积累的问题越多，恶性循环形成后，会给开发团队和用户带来信任上的危机。工作项看板化后需要调整工作模式，首先确保在制品（进行中的人物）都是正在进行、非搁置状态的；然后确保看板中的工作项数量是被限制的，渐进式的降低工作项数量；最后控制、调配每一列中工作项的数量，当某一列中的数量明显积压时，上游不要按照自己的节奏继续堆积工作，而是要协助下游降低在制品，这才是拉动式工作的重要意义。
约定看板的工作节奏
站会以看板为中心
结果是更新看板
每日站会
回顾会议
组织级运营评审
构建三层反馈环
看板方法也需要每日站会，但方法与Scrum流程不同，因为后者是对Sprint进行陈述和检查，而看板方法是以看板为中心，对已经可视化的工作项进行走读，从后向前拉动，最后的结果是更新看板，对于因调整工作项而产生的讨论不应在站会中进行
第7章 用看板加速价值流动
需求从Backlog进入就绪状态的前提是已经确定，不再改变，同时研发团队承诺技术可行，条件具备。进队列有节奏，出队列也有节奏，即上线节奏，两者相互配合才能最大程度减少在制品。软件开过程中，往往因为部署投入过大导致节奏失衡，所以持续化部署是必需攻克的问题。
浪费的代价
精益创业的反馈环
设计最小可行产品（MVP）
精益创业：创新产品的方法论
开发产品最大的浪费不是bug，而是没有用户，过程越努力，浪费越严重。避免浪费的唯一途径就是尽早接触用户，以MVP的形式持续产品迭代，直至达到预期效果。不要误认为等做的完美了才能拿给用户，如果方向错了，结果也只能是个完美的浪费。
精益画布：从一个想法开始建立商业模式
用户画像：定位目标用户群体
形成产品愿景
建立产品愿景
精益画布和用户画像有助于思考商业模式，形成产品愿景，而不是用于制作商业计划书，执行上述过程的角色是产品负责人，最后达成的愿景需具备3W1H要素
无差异属性（Indifference）
魅力属性（Attractive）
线性属性（One-dimensional）
必备属性（Must-be）
反向属性（Reverse）
卡诺模型
规划最小可发布版本（MMR）
洋葱圈规划法
制订产品规划
通过MVP确认客户预期的功能，利用MMR及时获得用户真实反馈，前者是验证假设的实验，后者是可以被用户购买的产品，结合核心价值主张的分析，最终的目的就是尽早获知用户真实反馈，避免所有不必要的人力和资源浪费
需求所承担的作用不同
时限不同
需求的规模不同
参与人不同
优先级制定方式不同
与传统需求管理的差异
D（Detailed Appropriately）：适度详细
E（Estimated）：估算好的
E（Emergent）：涌现的
P（Prioritized）：排好优先级的
保持产品Backlog的“深度”
Why：为什么要用“用户故事”描述产品需求
Who：哪些人创建用户故事
When：什么时候创建用户故事
角色：谁要使用这个功能
功能：需要完成什么样的功能
目的：这个功能可以达到什么目的
I（Independent）：独立的
N（Negotiable）：可协商的
V（Valuable）：对用户或客户有价值的
E（Estimable）：可估算的
S（Small）：小
T（Testable）可测试的
故事需要满足
延期成本
实现成本
风险和不确定性
依赖
定性评估法
定量计算法
如何决定需求的优先级顺序
How：怎么创建用户故事
用户故事：以用户为中心来描述需求
用户故事要以真实用户的角度来描述，这样才会体现产品所带来的价值。虽然不是每个任务都可以使用用户故事模版进行描述，但在开始阶段可以借此形成思维习惯。在描述用户故事的时候可由开发和测试人员一同参加，使得用户故事能被正常场景和异常场景推敲，同时也可以大幅降低后期产品送测过程中的沟通成本。用户故事需要满足INVEST原则，除了要对客户有价值，尤其是要重视规模小(SMALL)，故事将被分解为任务，规模过大的故事会导致细节模糊、不可估算、不易协商的困局，在建立故事的阶段如果沟通不充分，会导致在执行过程中加倍的补偿，从某种意义上看，故事也可被视为一种特殊的MVP，如果在构思用户故事阶段就尽可能澄清细节、难点，在实施过程应会顺畅很多。
将用户体验设计纳入敏捷流程
正确发挥原型的作用
让用户体验设计敏捷起来
原型是MVP的一种，是用户能切实感受到的体验，而不是凭借文字进行的脑补、想象。原型是需要经过反复推敲、确认、修改的，所以其是在整个产品生命周期存在的，只要有用户需求，就有原型存在的必要。制作原型，需要融合精益设计方法论，只要不是文字，只要能引起用户共鸣，哪种方式高效就用哪种方式。
敏捷需求管理
需求的作用是理解客户的诉求，而且贯穿产品生命周期，参与需求讨论的不只有产品负责人，还有研发团队，只要需求没有被启动就可以随时被修改。当需求被拆分到最小粒度时才能保证产品特性持续发布，并且因为需求的细化，才可以定义出明确的优先级。
第8章 用精益的方式做产品
数据分析框架
访问用户量
新用户量
活跃用户量/活跃度
流失用户量
回访用户量
产品运营数据
H：愉悦感（Happiness）
E：参与度（Engagement）
A：接受度（Adoption）和R：留存率（Retention）
T：任务完成率（Task Success）
用户体验数据
度量价值
速率
Sprint燃尽图
版本燃尽图
看板累积流图
看板周期时间分布图
价值交付效率
评估价值交付效率的几种方法中，看板累积流图是一个不错的工具，对于看板类项目，结合每日统计可以根据完成线、进入测试线、进入开发线、进入backlog线的高度差、斜率等数据进行效率评估，包括在制品数量、平均周期时间、吞吐率、需求范围变化，甚至交付日期的预测，建议看板类项目可以尝试使用
编译效率
版本构建效率
回归验证效率
全量功能验证效率
非功能性验证效率
工程效率度量
度量效率
用户满意度
产品的非功能性属性
每千行代码的缺陷数
缺陷密度
外部质量
代码质量度量
白盒测试覆盖率度量
持续交付流水线运行的成功率
内部质量
对于质量度量中的内部质量，结合持续集成流水线和接口测试的确是比较务实的实践之路，接口测试能确保系统对外接口的稳定性，也是持续集成的动力和目的，在此过程中人力一次投入后可以带来重复运行、持续监测质量的回报，没有接口测试的持续集成必然会无功而返。
度量质量
分配员工进新项目组
年度发展计划
组织级能力发展计划
发展组织能力
最好的敏捷团队是T型团队
每个人都有自己的专长，但也是个通才
发展团队能力
度量学习和成长
不论是组织能力还是团队能力，最关键的是学习能力，敏捷团队是促使团队学习的途径之一，因为成员不但要在专业技术领域精通，还要学习需求分析、团队沟通、问题表达等方面，每日站会则是不断练习的最佳机会
价值
效率
质量
学习
成长
定量评估
定性评估
面向结果的评估
产品管理健康度（Product Ownership Health）
技术健康度（Technical Health）
潜在产品增量/版本健康度（Potentially Shippable Increment Health）
团队健康度（Team Health）
迭代健康度（Sprint Health）
面向过程的评估
评估敏捷转型的效果
第9章 敏捷与精益数据分析
激励员工
赋能团队
统一目标
提升能力
结构成长
全面改进
敏捷领导力框架
激励员工：让每个人积极主动起来
被管理
自管理
自设计
自治
赋能团队：让团队自组织
团队的能力/意愿模型不是本书的重点，但能够让团队自组织的确是、也应该是带团队的目的，加以引导让团队的大方向不偏航，在发挥团队积极性的前提下充分授权，同时也要让团队切实感受到你是其中一员，在此基础上不论是组织扁平化、还是学习型组织、亦或是敏捷转型都是辅助团队取得更多成就的方法论而已。
要有高度
要足够远大
要现实
设立目标
保持团队稳定，不要将团队拆来拆去
保护团队不受打扰、不被中断
实施基于数据的透明、量化的管理
实现目标
统一目标：让大家齐心协力
当团队能够自组织，需要尽量保持其稳定，即确保一个稳定的全功能团队是做好产品的基础，过程中团队需要不受打扰的执行既定的目标，辅以量化的管理手段，利用数据促进团队不断自我完善，在一个不稳定的组织中成员无法专注、产品也无法延续
向团队明确责任
招聘时把好关
与员工制定“一对一”的个人成长计划
制订组织的整体能力发展计划和衡量体系
让员工感受到来自同行的压力
培养能力：让团队卓越起来
以客户和市场为中心
围绕产品价值流，搭建跨职能团队
及时调整组织结构，不拖延
不让沟通效率因组织规模的扩大而降低
结构成长：建立敏捷型的组织结构
敏捷型组织必然是跨职能的，怎样算是跨职能？要包括设计、开发、测试、产品、市场、运维和运营，在此基础上业务线以该跨职能团队为最小组织单元。现在康为定律不断被提及，在认同该定律的基础上组织结构是由业务决定的，为了能够快速响应客户、适应市场变化，符合产品方向、稳定的跨职能团队是事半功倍的保证。
全面改进：持续提升组织能力
第10章 敏捷领导力
自组织团队、成员自我驱动、持续改善组织是每个领导者，包括成员所期待的，这需要花心思去营造，将组织经营成为良好的学习平台，并且能够符合大多数成员的职业发展目标，激发出每位成员的内驱力，这样的组织才能做到自组织、自驱动，反观敏捷转型，学习型组织应该抱着积极态度去尝试、敢于试错，对转型成果充满预期。
持续改进包括团队层面、产品层面、组织层面，所能使用的工具和方法论也很多，比如SAFe，Kaizen，PDCA等等，不论是什么样的方法，只要能顺应软件开发变化趋势，持续推动价值流高效运转，事业的飞轮就会有源源不断的动力
0 条评论
回复 删除
下一页
