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

服务热线 hotline

15503768177

为什么很多企业想要敏捷转型时,却总是失败呢?


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



而很多企业在做敏捷赋能时,虽然怀着完美的初衷,却好心办坏事。就如同下面三个完美搞砸敏捷赋能的案例所表现的那样。






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



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



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



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



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



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



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



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



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



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



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