从敏捷转型到精益企业
2019-12-16
来源：ThoughtWorks商业洞见 肖然
[摘要]作为国内第一批敏捷咨询顾问，笔者通过自己八年的咨询经历， 展现了大型IT组织敏捷转型的 演进历史，帮助读者更清晰地分析敏捷转型对一个组织的价值，以及随之而来的变革。从简单的小团队引入敏捷管理框架开始，敏捷转型经历了对技术实践的更深入尝试、对团队规模的更大范围采用、以及对整个组织的更广阔精益变革。随着IT行业的颠覆式发展，敏捷转型涉及的范围也在不断扩大，今日我们谈论「 精益企业」时，已经把敏捷的思想运用到了企业运营的方方面 面，对价值的追求也不再局限于高效的软件交付，而是持续创造真正市场价值。不知不觉之间，精益生态圈的商业模式正在逐步形成！
数字化大时代下传统企业面临着种种挑战：效率永远跟不上市场业务需求，质量总是修修补补过日子，协同在部门墙面前无从谈起。很多企业结识了「敏捷」，开始尝试用敏捷组织转型来应对这些问题。2008年我在国内接到了第一个敏捷转型项目，一转眼八年过去了。尽管在这个领域里，持续交付（Continuous Delivery）、开发自运维（DevOps）、规模化敏捷框架等一系列新概念如雨后春笋般冒出来，但敏捷宣言没变，敏捷核心实践没变，敏捷咨询好像也没有太大变化。
最近在研讨和推广「精益企业」的时候，「精益企业和敏捷的关系」这个问题突然让我有机会反思这八年不同组织里「敏捷」到底发生了什么样的变化：显然目标没变，都是组织敏捷转型，解决的问题也都是上述这些挑战，那么这个领域里什么变了呢？
要回答这个问题首先要澄清对时下流行的「规模化敏捷」这个提法的理解。由于一些框架的提出，如SAFe、LeSS等，「规模化」成为了这两年敏捷转型领域里的热点（也被大家看成了敏捷转型领域的发展）。但我尝试过在一个组织里询问不同角色对规模化的期望，结果是大相径庭的。比如在一个典型千人规模的IT组织里交付团队认为「规模化敏捷」应该标志着绝大部分团队已经采用了迭代开发的模式，而业务人员却认为这样的「规模化」对他们没有意义，「规模化敏捷」的实施应该是让团队具备在开发过程中快速响应市场变化的能力。所以「规模化」的提法是模糊的，咱们需要更实例化地来看组织敏捷转型这些年的演进历程。
更深入的敏捷实践
2008年请我去做敏捷教练的组织是一个传统行业的线上服务平台IT团队。这个组织拿出了一个网络平台组来实施敏捷开发。于是我们从Scrum入手，建立了两个全功能团队，把以前部门割裂的需求分析、开发、测试拉到了一起。由于组织领导者的高度关注和试点「特区」运作的模式，这两个团队很快按照迭代的模式运作了起来。
三个迭代后这两个团队都能够自发的组织各种关键会议，如迭代启动、回顾会议等，大家的交流沟通也日趋默契。如果身临其境，你会觉得这个团队很敏捷，但外部看来问题还是挺严重：迭代计划的需求基本上完不成，测试普遍滞后，用户故事（User Story）普遍达不到完成(DoD， Definition of Done）标准。
当然现在看来问题很明确，稍微有经验的读者都会说他们需要加强技术实践了。在后期，团队敏捷教练的时间主要都投入到了如持续集成、自动化测试这样的技术实践辅导里。作为程序员出身的我当时并没有从组织转型的角度思考，只是在解决现实问题罢了。如果你想提升用户故事的交付效率，显然必须考虑工程技术方面的问题。
2009年我又作为教练加入了一家大型通讯设备厂商的敏捷转型。面对复杂的组织结构和百人的开发团队，我自己有些迷茫了。经常会被一些部门领导问得不知所措，怎么把Scrum这种小团队模式在百人的团队里实施成了一个难题。回想起来，如何应对当时组织里的各种约束条件，比如绩效考核怎么搞、预算怎么做，这些企业转型后必须面对的问题，我当时并没有答案。
但有意思的是，在我参加的几个试点团队里，由于我们同步推进了不少技术实践（如重构、TDD），得到了出乎意料的认可。经典的案例是在一个项目上通过代码重构减少了三分之一的代码量而实现了同样的功能，并且代码结构变得清晰简洁。现在可能这样的案例或成果已经随处可见了，但大家可以想想在2009年，大多数企业度量程序员效率还是依靠单位时间代码行产量的环境下，这会带来什么样的冲击。
在之后的咨询生涯里，每个企业我都会要求管理和技术实践同步进
免责声明：
1、IT项目管理界发布的所有资讯与文章是出于为业界传递更多信息之目的，并不意味着赞同其观点或证实其描述。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，请浏览者仅作参考，并请自行核实相关内容。
2、本站部分内容转载于其他网站和媒体，版权归原作者或原发布媒体所有。如文章涉及版权等问题，请联系本站，我们将在两个工作日内进行删除或修改处理。敬请谅解！
-
延伸阅读：
-
