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