很多同学把“敏捷”与“快”画了等号，也有的同学把敏捷与Scrum/看板/XP极限编程/站立会/结对编程等方法框架/方法实践画了等号。

        有些尝试过敏捷的团队这样反馈：实施过敏捷开发，但是结果是没有快反而比之前慢了？他们尝试过Scrum，结对编程，测试驱动开发等等。

        那敏捷是什么？敏捷是个持续改进的过程，敏捷开发涉及到道法术器四层，详细内容可以阅读《初识敏捷开发》。

        敏捷推行的成功涉及到对的人、对的方法、对的时机等问题。这里边推行过程中的问题，是推行的真的敏捷？还是推行的自己认为的敏捷，这个问题先不论。假设我们敏捷推行的人/方法/时机都是对的、是合理的，本文我们仅讨论下敏捷的快与慢的问题。

        敏捷的快：1是要更快的交付核心价值，优先级高的先交付，减少重要价值的延期交付成本；2 短周期、高频率交付价值（将需求按优先级、按迭代拆分，每次交付最小可行性的产品），频繁交付、频繁的得到反馈，不断的根据发布后客户/市场的反馈情况做后续决策的调整。

        而很多人会基于原来“瀑布开发模式”（大需求、大批量交付的方式）去衡量敏捷的快。

        另外，“快”，是大家对交付效率的一种解读，是对单位时间内人均产出的衡量。但是针对VUCA时代，效率必须考虑“流动效率”和“资源效率”两种。敏捷的快是基于这两种效率考虑的。

效率可以分为两大类，资源效率和流动效率：

资源效率：是资源的使用率和产出，比如每个研发工程师单位时间内的产出，资源产出越高效率越高。

流动效率：是从用户的角度去看，用户的需求从提出到交付整个过程流动的速度，流动速度越快效率越高。可以用需求端到端的交付时长和整个交付过程中的等待时长占比来看。

        资源效率和流动效率是有潜在冲突的，不可能同时提升到100%。流动效率要达到100%，意味者部分资源在某个时间段是空闲的，这样才能保证新任务来的时候能马上进行受理，那资源效率就达不到100%；资源效率要达到100%，意味着，一个任务从某个阶段流转到下一阶段时，下一阶段没有资源可以马上处理此任务，从而导致流动效率低于100%。所以需要做个平衡取舍，平衡如何做到价值最大化。

        图1 展示了流动效率低下的一个例子，需求处理过程中等待时间占了一半多。

——图片选自《研发精益数字化管理》一书

                                        图1需求处理过程中的有效处理时间和等待时间

        流动效率低下可能有很多原因，但是企业中“职能型组织机构”是绝对会中招的一个原因。

        职能型组织结构中，业务是业务部门，UI是UI部门，研发是研发部门，研发部门中前端开发、后端开发、测试又分别在不同的部门。

        这种职能型组织结构，天然存在部门墙，改进的时候会很容易按职能分别改进，比如会各自改进需求产出的效率、改进开发的效率、改进测试的效率。这就会产生一个个的效率竖井，产品、开发、测试各自看上去产出效率（资源效率）比较高（这样人可以充分利用，工作可以统一安排的满满的，不会有闲置资源）造成了高效率的假象。

       但是隐含的流动效率会很差（就是对于用户来说需求的响应速度不高）。因为职能部门的各自目标是分段。可能只有产品经理是提出来需求并关注这个需求多长时间能最终上线的。而UI、开发、测试只是任务流到这个阶段，自认为做好这个阶段的事情就好了（人均产出率高、没有积压等），他们不会为产品的整个交付时长做更多的思考。产品、前端开发、后端开发、测试各职能部门的目标不太一致，导致了各部门之间的矛盾，出现问题会互相推卸责任互相吐槽，以为证明责任不是自己的了就没事了。

        在职能型组织结构下，很多时候也不是大家故意不配合，因为大家都太忙了，忙着完成自己手头的任务，忙着达成自己的人均产出。没有时间帮别人想。出了故障，review的时候，争锋相对，互相推卸责任，因为站在各自的立场上，不是自己的责任就比是自己的责任强。至于共同改进是第二步的事情。

        但是当大家是一个团队，目标一致的时候，大家就会共同为目标努力，想解决方案，敏捷开发鼓励跨职能型的敏捷团队，消除部门墙。（固定产品线的产品、开发、测试等是一个团队，有共同的考核目标）。大家是一个团队的时候，就会都为目标完成考虑，出现问题共同解决，发现瓶颈共同改进。

         比如，1）有这样的问题，临近节假日前有个很紧急的需求已经制定了ddl，但是需求迟迟确定不下来，交给开发的时候已经只剩下几天了，开发加班加点的搞。因为时间原因，项目质量就无法保证。如果大家是一个团队，产品为了最后目标也会考虑开发测试的情况，尽量提前沟通达成一致，开发测试能有设计缓冲的时间。2）研发会吐槽产品经理写的文档不够规范、不够细，吐槽产品经理考虑的不够清楚等，产品上线后的问题，会归结于产品设计的不到位、产品需求没讲清楚等。如果大家是一个团队，大家是为了最终交付负责的，不是为了自己完成任务就可以的。所以大家一起合作会都尽各自努力沟通达成一致，文档写的好从一定程度上是可以提高开发的质量效率，但不是根本。根本是双方沟通达成共识。都往前走一步，开发测试可以跟产品共同探讨产品设计的合理性，如何更好，产品/开发可以帮助测试去测试需求保证快速高质量上线。

         但是话又说回来了，注重“流动效率“需要与注重“资源效率”有个平衡点，这时需要考虑公司目前的战略方向，产品目前所处的阶段（如图2），是快速强占市场、快速扩张的阶段，还是处于产品的衰退期，是个维持阶段。产品所处的不同的生命周期和业务的战略也决定了，我们现在应该主要考虑哪个效率，还是要两者兼顾。

                                                                 图2 产品生命周期阶段