如何实现敏捷赋能？
企业的敏捷转型，由于涉及转变企业全体成员的工作习惯，提升敏捷实践能力，所以本质上属于教育和赋能。
而很多企业在做敏捷赋能时，虽然怀着完美的初衷，却好心办坏事。就如同下面三个完美搞砸敏捷赋能的案例所表现的那样。
完美搞砸案例一，用培训推广最佳实践，但学员用不上。
某企业为一线开发团队安排了10门敏捷技术实践培训和编程操练课程，涉及重构、自动化测试、持续集成和整洁架构。这些可都是业界所推崇的最佳实践。但在练完根据《重构》第2版第一章所改编的代码重构编程操练后，一位听课学员对讲师说，”这些重构手法固然很好，但在实际工作中，开发人员一般不会为了消除代码腐臭，而做这些重构。你所讲的通过决策树来设计测试用例，开发人员也都知道，但他们一般也不会使用。“或许有些开发人员还没有意识到重构和自动化测试的重要性，此时给他们讲这些，这就好比给一个口渴的人一个馒头，解决不了他的问题。
完美搞砸案例二，集中性地推广某实践，但很快倒胃口。
某企业领导认为自动化测试很重要，于是相关部门安排了为期一年的自动化测试集中推广。推广活动包括一线开发人员观看相关视频课程，编写并发布了组织级自动化测试实践指南，每月组织一次自动化测试收益分享，设计了推广活动的宣传口号“新八零”（指新增代码测试覆盖率要向80%看齐），利用企业内部研发效能工具平台统计自动化测试覆盖率，并设置了组织级自动化测试达标评判指标和进度。这样做了几个月后，发现有人开始抱怨推广活动给他们带来了额外的工作量，在内部论坛里大量吐槽评判指标不合理，参加每月自动化测试收益分享的人数越来越少。这就好比每天吃妈妈做的红烧肉，连续吃一年，吃到后来感觉就是在受罪。
完美搞砸案例三，靠成熟度评级来推动，但过后删测试。
某企业领导认为一线开发团队实践敏捷技术实践缺乏动力，于是想借助第三方的DevOps能力成熟度评估来促进敏捷实践的落地。为了在达标中获得好成绩，某团队在达标考核前2周，抽调8人加班加点，在原先500个自动化测试的基础上，又增加了2000个自动化测试。但在达标考核的前夜，将这2500个测试运行在流水线上后，发现即使运行了2个多小时，这些测试还没跑完。最后只好将这2000个测试从流水线上移除。而当该企业通过了达标后，为了加快流水线的运行速度，开发人员开始在流水线上移除更多的自动化测试。
上述三个案例，都属于不顾一线开发团队具体情况，“拍脑袋”式推广的做法。
“拍脑袋”式推广的不祥之兆在于缺乏用户思维。即在敏捷转型的组织内，规模化推广业界敏捷最佳实践时，缺乏为一线开发人员创造价值的心态，不针对他们的具体痛点，不因人、因地、因时制宜，不做频繁小批的迭代复盘和调整，只是一味地推广未经在本组织内验证过的业界最佳实践，从而完美搞砸敏捷赋能。
“拍脑袋”式推广的后果，就是浪费严重。因为赋能内容在工作中“用不上”，内部教练与团队成员对敏捷赋能缺乏兴趣，而仅仅应付差使，等风头过后就恢复原样，造成赋能投入的大量浪费。
那么该如何救场被完美搞砸的敏捷赋能呢？要持经达变地为一线开发人员创造价值。经书一般不会随意修改，持经就是说要坚持良好的敏捷实践原则。而一旦面临一线开发团队具体的痛点时，要在“持经”的基础上随机应变，根据团队具体情况灵调整，从而做到“达变”。
要想在敏捷赋能时做到“持经达变”，可以参考三个原则：用户思维原则、赋能假说原则和分享警示原则。
用户思维原则
用户思维要运用
要针对一线开发人员的痛点创建若干实践社区，作为用户思维的基础，并将其中的一线开发人员视作敏捷赋能的用户。
要运用电梯演讲、用户画像、用户目标等技术，明确敏捷赋能要解决的用户问题。
赋能让人听进去
想要敏捷赋能产生成效，离不开一线开发人员。要让他们改变工作习惯，需要抱着为他们分忧的心态来进行赋能。与他们沟通时，要站在他们的立场，使用他们能听进去的方式来讲话。比如，将“要为关键业务逻辑编写自动化测试”，改为“本来项目进度就很紧张了，但bug所造成的返工，会导致加班，伤害身体。而为容易出错的业务逻辑添加开卡、验卡和自动化测试等环节，会有效减少返工。”
全部角色做赋能
软件产品的价值会流经业务、开发、测试、运维等人员之手。而每个角色的研发效能和质量内建，都会决定端到端的交货时长和产品质量，所以需要对价值流经的所有角色进行敏捷赋能。
实现端到端限流
当双十一激增的用户访问量，逼近电商网站的最大负荷（已经使用了容量伸缩机制）时，要想让网站能继续提供服务，唯一的方法就是对用户请求限流，能继续处理的请求接着处理，超出处理能力的请求就一一谢绝，这样才不至于压垮电商网站。对于软件开发团队也同理，当技术债或祖传代码中所积累的毒素，快要达到开发效能崩溃的临界值时，就需要从业务上游开始，进行端到端全链路的限流，减少甚至停止开发新需求，给开发团队留出清除代码毒素的带宽。
赋能假说原则
心态接受复杂性
Ross Ashby在1958年所提出的“必要多样性法则”指出，“对于能够完全控制系统B的系统A，必须至少与系统B一样复杂。”要想用软件实现日益复杂的业务，相关的软件开发过程，必然是一个包含大量组件及其关联关系的复杂系统，无法将其简化为简单系统。所以，要从心态上接受软件开发过程是复杂系统的事实，接受其“事与愿违”和“难以预测”的特点。
赋能计划即假说
既然软件开发过程“事与愿违”和“难以预测”，那么对其中的人员进行赋能前所制定的赋能计划，就属于假说。比如，“一线开发人员通过为业务主流程编写单元测试，并将其作为回归测试运行在流水线上，以减少返工”。这个假说既可能完全成立，也可能部分成立，也有可能完全不成立，依这个一线开发团队具体情况而定。
假说验证靠实验
验证敏捷赋能假说是否成立的唯一手段，就是做实验。由于实验可能失败，所以要在规划实验时，将实验的范围限制在可控的范围内。
失误难免可回退
由于软件开发过程是一个“事与愿违”和“难以预测”的复杂系统，所以个人的大脑无法对整个复杂系统完整建模，当对这个过程进行敏捷赋能时，出现失误在所难免。为此应该为赋能过程设计“失误可回退”的机制，一旦发现赋能假说不成立，就可快速回退到之前的状态。
指标举措要权变
每个开发小组的开发过程，会根据其所开发的软件产品的生命周期的阶段的不同而不同。比如，一个正处于开发阶段的产品，后端有5位开发人员协作开发，那么每天做半小时集体代码评审就有意义。但对于正处于维护阶段的软件产品，维护人员只有一人，此时就无法实现集体代码评审。所以敏捷赋能的指标和举措，都要根据开发小组的具体情况，作出权变，不可一刀切。
小步迭代常改进
因为敏捷赋能是个复杂系统，赋能计划即假说，所以敏捷赋能规划，不可一下就做一年的计划，而应该用小步迭代的方式，不断根据反馈进行改进。
优选返工与瓶颈
当在进行敏捷赋能迭代时，由于在迭代周期内只能小批量地做实验，所以确定赋能优先级十分关键，因为这决定了本次迭代要做哪些赋能。根据约束理论，优先赋能的环节，应该是价值流的最大瓶颈。而在做基于遗留系统的软件开发维护工作时，返工的危害会大于瓶颈。因为返工不仅会耽误时间，还会让价值流再次穿过瓶颈，让本以缓慢的软件开发过程雪上加霜。所以，敏捷赋能的迭代待办项，要优选返工最多的环节进行赋能，其次是对瓶颈进行赋能。
质量内建可观测
要想确定存在返工与瓶颈问题的环节，需要确定指标，以观测质量内建的过程。
指标仅为自提升
由于人员会根据指标做出一些急功近利的调整，从而花费最小的代价来达成指标，所以指标一旦用于控制和绩效考核，就会变得不再可靠。要想让指标发挥作用，不能将其与绩效考核直接挂钩，也不可做跨团队的横向对比，而仅用于开发小组自身的改进。
分享警示原则
痛点拉动做培训
培训分两种。一种是相对抽象的理念普及，另一种是更加落地的实际操练。要想让这两类培训获得更好的成效，需要先基于用户思维，了解听众实际工作中的痛点，再针对痛点来定制培训内容。
频繁分享警示牌
要想应对复杂系统的不确定性，除了接受复杂性，做到失误可回退之外，还要做到树立警示牌，将前人所踩的坑进行分析和沉淀，并分享给后人，让后人不再重蹈覆辙。
“拍脑袋”式的敏捷赋能，虽然初衷良好，但会好心办坏事。既解决不了一线开发团队的痛点，也会因形式主义造成大量浪费。要想扭转这一局面，需要本着用户思维原则、赋能假说原则和分享警示原则，持经达变地为一线开发团队创造价值。
