发布于 2021-10-15 11:23:14   阅读次数：

企业的敏捷转型，由于涉及转变企业全体成员的工作习惯，提升敏捷实践能力，所以本质上属于教育和赋能。

 

而很多企业在做敏捷赋能时，虽然怀着完美的初衷，却好心办坏事。广东合协人力资源管理软件的小编给大家说说下面三个完美搞砸敏捷赋能的案例。

 

完美搞砸案例一，用培训推广最佳实践，但学员用不上。

某企业为一线开发团队安排了10门敏捷技术实践培训和编程操练课程，涉及重构、自动化测试、持续集成和整洁架构。这些可都是业界所推崇的最佳实践。但在练完根据《重构》第2版第一章所改编的代码重构编程操练后，一位听课学员对讲师说，”这些重构手法固然很好，但在实际工作中，开发人员一般不会为了消除代码腐臭，而做这些重构。你所讲的通过决策树来设计测试用例，开发人员也都知道，但他们一般也不会使用。“或许有些开发人员还没有意识到重构和自动化测试的重要性，此时给他们讲这些，这就好比给一个口渴的人一个馒头，解决不了他的问题。

 

完美搞砸案例二，集中性地推广某实践，但很快倒胃口。

某企业领导认为自动化测试很重要，于是相关部门安排了为期一年的自动化测试集中推广。推广活动包括一线开发人员观看相关视频课程，编写并发布了组织级自动化测试实践指南，每月组织一次自动化测试收益分享，设计了推广活动的宣传口号“新八零”（指新增代码测试覆盖率要向80%看齐），利用企业内部研发效能工具平台统计自动化测试覆盖率，并设置了组织级自动化测试达标评判指标和进度。这样做了几个月后，发现有人开始抱怨推广活动给他们带来了额外的工作量，在内部论坛里大量吐槽评判指标不合理，参加每月自动化测试收益分享的人数越来越少。这就好比每天吃妈妈做的红烧肉，连续吃一年，吃到后来感觉就是在受罪。

 

完美搞砸案例三，靠成熟度评级来推动，但过后删测试。

某企业领导认为一线开发团队实践敏捷技术实践缺乏动力，于是想借助第三方的DevOps能力成熟度评估来促进敏捷实践的落地。为了在达标中获得好成绩，某团队在达标考核前2周，抽调8人加班加点，在原先500个自动化测试的基础上，又增加了2000个自动化测试。但在达标考核的前夜，将这2500个测试运行在流水线上后，发现即使运行了2个多小时，这些测试还没跑完。最后只好将这2000个测试从流水线上移除。而当该企业通过了达标后，为了加快流水线的运行速度，开发人员开始在流水线上移除更多的自动化测试。

 

上述三个案例，都属于不顾一线开发团队具体情况，“拍脑袋”式推广的做法。

 

“拍脑袋”式推广的不祥之兆在于缺乏用户思维。即在敏捷转型的组织内，规模化推广业界敏捷最佳实践时，缺乏为一线开发人员创造价值的心态，不针对他们的具体痛点，不因人、因地、因时制宜，不做频繁小批的迭代复盘和调整，只是一味地推广未经在本组织内验证过的业界最佳实践，从而完美搞砸敏捷赋能。

 

“拍脑袋”式推广的后果，就是浪费严重。因为赋能内容在工作中“用不上”，内部教练与团队成员对敏捷赋能缺乏兴趣，而仅仅应付差使，等风头过后就恢复原样，造成赋能投入的大量浪费。

 

那么该如何救场被完美搞砸的敏捷赋能呢？要持经达变地为一线开发人员创造价值。经书一般不会随意修改，持经就是说要坚持良好的敏捷实践原则。而一旦面临一线开发团队具体的痛点时，要在“持经”的基础上随机应变，根据团队具体情况灵调整，从而做到“达变”。

 

要想在敏捷赋能时做到“持经达变”，可以参考三个原则：用户思维原则、赋能假说原则和分享警示原则。

 

用户思维原则

用户思维要运用

要针对一线开发人员的痛点创建若干实践社区，作为用户思维的基础，并将其中的一线开发人员视作敏捷赋能的用户。

 

要运用电梯演讲、用户画像、用户目标等技术，明确敏捷赋能要解决的用户问题。

 

赋能让人听进去

想要敏捷赋能产生成效，离不开一线开发人员。要让他们改变工作习惯，需要抱着为他们分忧的心态来进行赋能。与他们沟通时，要站在他们的立场，使用他们能听进去的方式来讲话。比如，将“要为关键业务逻辑编写自动化测试”，改为“本来项目进度就很紧张了，但bug所造成的返工，会导致加班，伤害身体。而为容易出错的业务逻辑添加开卡、验卡和自动化测试等环节，会有效减少返工。”

 

全部角色做赋能

软件产品的价值会流经业务、开发、测试、运维等人员之手。而每个角色的研发效能和质量内建，都会决定端到端的交货时长和产品质量，所以需要对价值流经的所有角色进行敏捷赋能。

 

实现端到端限流

当双十一激增的用户访问量，逼近电商网站的最大负荷（已经使用了容量伸缩机制）时，要想让网站能继续提供服务，唯一的方法就是对用户请求限流，能继续处理的请求接着处理，超出处理能力的请求就一一谢绝，这样才不至于压垮电商网站。对于软件开发团队也同理，当技术债或祖传代码中所积累的毒素，快要达到开发效能崩溃的临界值时，就需要从业务上游开始，进行端到端全链路的限流，减少甚至停止开发新需求，给开发团队留出清除代码毒素的带宽。

 

赋能假说原则

心态接受复杂性

Ross Ashby在1958年所提出的“必要多样性法则”指出，“对于能够完全控制系统B的系统A，必须至少与系统B一样复杂。”要想用软件实现日益复杂的业务，相关的软件开发过程，必然是一个包含大量组件及其关联关系的复杂系统，无法将其简化为简单系统。所以，要从心态上接受软件开发过程是复杂系统的事实，接受其“事与愿违”和“难以预测”的特点。

 

赋能计划即假说

既然软件开发过程“事与愿违”和“难以预测”，那么对其中的人员进行赋能前所制定的赋能计划，就属于假说。比如，“一线开发人员通过为业务主流程编写单元测试，并将其作为回归测试运行在流水线上，以减少返工”。这个假说既可能完全成立，也可能部分成立，也有可能完全不成立，依这个一线开发团队具体情况而定。

 

假说验证靠实验

验证敏捷赋能假说是否成立的唯一手段，就是做实验。由于实验可能失败，所以要在规划实验时，将实验的范围限制在可控的范围内。

 

失误难免可回退

由于软件开发过程是一个“事与愿违”和“难以预测”的复杂系统，所以个人的大脑无法对整个复杂系统完整建模，当对这个过程进行敏捷赋能时，出现失误在所难免。为此应该为赋能过程设计“失误可回退”的机制，一旦发现赋能假说不成立，就可快速回退到之前的状态。

 

指标举措要权变

每个开发小组的开发过程，会根据其所开发的软件产品的生命周期的阶段的不同而不同。比如，一个正处于开发阶段的产品，后端有5位开发人员协作开发，那么每天做半小时集体代码评审就有意义。但对于正处于维护阶段的软件产品，维护人员只有一人，此时就无法实现集体代码评审。所以敏捷赋能的指标和举措，都要根据开发小组的具体情况，作出权变，不可一刀切。

 

小步迭代常改进

因为敏捷赋能是个复杂系统，赋能计划即假说，所以敏捷赋能规划，不可一下就做一年的计划，而应该用小步迭代的方式，不断根据反馈进行改进。

 

优选返工与瓶颈

当在进行敏捷赋能迭代时，由于在迭代周期内只能小批量地做实验，所以确定赋能优先级十分关键，因为这决定了本次迭代要做哪些赋能。根据约束理论，优先赋能的环节，应该是价值流的最大瓶颈。而在做基于遗留系统的软件开发维护工作时，返工的危害会大于瓶颈。因为返工不仅会耽误时间，还会让价值流再次穿过瓶颈，让本以缓慢的软件开发过程雪上加霜。所以，敏捷赋能的迭代待办项，要优选返工最多的环节进行赋能，其次是对瓶颈进行赋能。

 

质量内建可观测

要想确定存在返工与瓶颈问题的环节，需要确定指标，以观测质量内建的过程。

 

指标仅为自提升

 

由于人员会根据指标做出一些急功近利的调整，从而花费最小的代价来达成指标，所以指标一旦用于控制和绩效考核，就会变得不再可靠。要想让指标发挥作用，不能将其与绩效考核直接挂钩，也不可做跨团队的横向对比，而仅用于开发小组自身的改进。

 

分享警示原则

痛点拉动做培训

培训分两种。一种是相对抽象的理念普及，另一种是更加落地的实际操练。要想让这两类培训获得更好的成效，需要先基于用户思维，了解听众实际工作中的痛点，再针对痛点来定制培训内容。

 

频繁分享警示牌

要想应对复杂系统的不确定性，除了接受复杂性，做到失误可回退之外，还要做到树立警示牌，将前人所踩的坑进行分析和沉淀，并分享给后人，让后人不再重蹈覆辙。

 

“拍脑袋”式的敏捷赋能，虽然初衷良好，但会好心办坏事。既解决不了一线开发团队的痛点，也会因形式主义造成大量浪费。要想扭转这一局面，需要本着用户思维原则、赋能假说原则和分享警示原则，持经达变地为一线开发团队创造价值。

• 人力资源管理软件职场干货：公司好不好，看HR就知道了
• 人力资源管理软件职场干货：HR如何解决跨部门沟通带来的困扰？
• 南沙科金控股集团携手合协EHR软件
• 人力资源管理软件职场干货：“我有五年招聘经验”“不，你根本没经验！”
• 人力资源管理软件职场干货：只要认真搞，没有什么KPI搞不挎的企业
• 人力资源管理软件职场干货：ChatGPT能否成为一位资深的HR？