想做好敏捷转型需要打通三条关键链丨IDCF

来源：敏捷DevOps那些事儿

作者：杨久成

前段时间一个朋友问了我一个问题，他说他所在的公司正在尝试敏捷转型，他们在内部选择了一批“积极分子”牵头在团队落地Scrum，但是，从结果上来说好像并不尽如人意。我大概了解了他们的做法，主要是把Scrum里的典型实践跑起来，团队开始尝试迭代，迭代开始会开展计划会，过程中会进行每日站会，迭代尾声会组织评审会和回顾会。

但是，每个实践都只聚焦在实践本身是不是按照“教科书”做好了，并没有关注实践之间的关联性以及实践落地后交付效能是否真的有提升。所以他们的最大问题不是实践本身做得好不好，而是做了实践后从需求到交付的链条是否真的有变得更加顺畅。

有时候我们在组织中落地敏捷实践，往往容易陷入实践的误区，认为实践必须做的非常标准化，恨不得所有的团队都要采用一模一样的流程。但是回到解决问题本身，实践做得好不好并不会直接产生价值。在当今时代下，敏捷做得好不好核心判断依据还是能不能给业务交付带来正向收益。类似的衡量指标很多，比如企业中效能度量常见的需求交付周期，一次性通过率，迭代完成度等等。而在诸多衡量指标之外，我认为业务交付的流畅度更具有画面感。流畅度不是一个单一指标，而是结合诸多度量指标综合出的评价维度。

回到案例本身基于业务流畅度提升的视角，我给到这位朋友的反馈就是要打通三条关键链。今天稍作整理分享给小伙伴们。

在上述案例中，他们似乎并没有理解敏捷到底是做什么，解决什么问题。而是认为跑了敏捷实践就应该有效果。一方面局限在scrum的几个割裂的实践上，另外也缺乏端到端的视角去思考敏捷的核心关注点。笔者认为敏捷转型要从流程链、组织架构链和工具链三条链路上发力，才能保证敏捷转型获得应有的成效。

从流程的角度来说，起点应该从业务愿景开始，从愿景一步步拆解到业务战略和目标、业务举措、业务需求，以上可以认为是问题域。而继续向下流转就到了解决方案域，也就是大家常规认为的“敏捷舒适区”，我们拆解需求形成功能需求并通过迭代的方式进行交付。而最后一个是持续改进域， 我们通过产品上线后的运营动作以及数据反馈对业务进行规划调整形成闭环。至此才是完整的流程链路。而上述案例关注的实践都集中在解决方案域，一头一尾都没有，效果甚微也就不奇怪了。

从流程链我们可以洞察到敏捷的端到端流程需要业务和研发的紧密协作，而从职能上可能涉及更加广泛，领导层、战略、产品、研发、运营等等。那么如果组织架构链路不通畅势必造成基于流程链的工作流动会受到组织架构的反作用力。这也是为什么在敏捷当中一直提倡要建立特性团队的原因。除了特性团队，犹如Spotify中的小队和部落也是类似的逻辑。

工具的重要性不需要过多强调，但是工具链的打通却是组织容易忽略又比较困难的部分。组织中工具的引入和演变往往是根据具体的甚至是单点的诉求而来。所以容易出现的现象是想解决开发问题就引入一个开发工具，想解决测试问题就引入一个测试工具，甚至在一些企业DevOps这个完整的概念落实到工具层面依然会变成多个单点工具的结合。

从组织的角度来说，流程链和组织架构链打通后最大的阻碍点就是工具链路。想象下在一个特性团队中，我们每天喊口号要快速交付，适应变化。而在需求录入，迭代管理和测试管理上又要切换不同的工具平台。甚至在同一个组织的不同团队中使用的工具和方式也不一样。一方面工具切换让效率降低，另一方面，效能度量也无法真正的做起来。

以上是对三条关键链的解读。如果三条关键链都能打通就为提升团队业务交付流畅度打下了坚实的基础。归根结底，核心的思维还是来源于精益中的价值流理念，在此基础上再进行分层。不管用什么方法和框架，价值流的度量永不过时。

#IDCF DevOps黑客马拉松挑战赛，独创端到端DevOps体验，精益创业+敏捷开发+DevOps流水线的完美结合。

2023年3月25-26日将在上海举办，36小时内从0到1打造并发布一款产品。

企业组队参赛&个人参赛均可，赶紧上车~????