您好,欢迎访问企业学习网!

服务热线 hotline

15503768177

企业要想在敏捷赋能时做到“持经达变”,可以参考这三个原则!


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






参考原则一用户思维原则



1、用户思维要运用



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



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



2、赋能让人听进去



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



3、全部角色做赋能



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



4、实现端到端限流



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



参考原则二赋能假说原则



1、心态接受复杂性



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



2、赋能计划即假说



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



3、假说验证靠实验



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



4、失误难免可回退



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



5、指标举措要权变



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



6、小步迭代常改进



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



7、优选返工与瓶颈



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



8、质量内建可观测



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



9、指标仅为自提升



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



参考原则三分享警示原则



1、痛点拉动做培训



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



2、频繁分享警示牌



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



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