跨越敏捷 — 闲鱼研发效能升级之路

摘要：摘要在第二届研发效能嘉年华专场上，来自阿里巴巴集团研发效能张燎原为听众带来了跨越敏捷闲鱼研发效能升级之路的精彩分享。根据敏捷思想，闲鱼团队对现有的软件开发方式进行转型提效。

摘要： 在2018第二届研发效能嘉年华专场上，来自阿里巴巴集团研发效能张燎原为听众带来了《跨越敏捷 — 闲鱼研发效能升级之路》的精彩分享。在分享中，他从以业务为导向的跨职能协作、按需求进行协作和流动、让功能服务关联目标、度量数据服务转型提效四个方面详细阐述了闲鱼敏捷转型之路。

在2018第二届研发效能嘉年华专场上，来自阿里巴巴集团研发效能张燎原为听众带来了《跨越敏捷 — 闲鱼研发效能升级之路》的精彩分享。在分享中，他从以业务为导向的跨职能协作、按需求进行协作和流动、让功能服务关联目标、度量数据服务转型提效四个方面详细阐述了闲鱼敏捷转型之路。

以下是精彩视频内容整理：

VUCA时代瀑布开发方式的弊端

当今时代又被成为VUCA时代，在这样一个时代里，越来越多的企业和组织都面临着软件开发的转型。根据摩尔定律和反摩尔定律，企业应该尽可能地缩减产品的研发周期。

然而，在绝大多数软件开发过程中，传统的软件开发策略采用的是瀑布式开发方式，尤其是一些传统型企业，通常会保留几个月去做需求分析，再花费几个月的时间去做设计、开发、测试，到最终发布，整体周期可能很长。而最早决定做什么是在产品的需求分析阶段，也就是在产品项目知识最缺乏的时候进行的决定，这就是一个悖论，即在知识积累最少时，为产品的未来做来决定，决定产品的未来发展方向。

因此，在这种环境下，我们不能再采用传统的方式进行软件开发，而需要更新开发策略：在开始阶段进行初始决策，在一个迭代周期之后，根据用户的反馈、对产品的认知以及技术环境和市场环境的变化进行知识积累，此时再根据所积累的知识逐步进行增量决策和调整，也就是说迭代之后交付出去的产品特性能够帮助我们验证市场、用户，帮助我们持续调整，进而使得我们在下一个迭代过程中再次试水，这种持续地反馈，让我们不断调整去适应变化的能力，即敏捷力。

显然，绝大多数互联网产品都应该按照敏捷的方式进行开发。根据敏捷思想，闲鱼团队对现有的软件开发方式进行转型、提效。

闲鱼转型提效策略

闲鱼转型提效策略首先明确了211目标，即2周交付周期、2周开发周期以及1小时发布时长。对于确定的目标，将其分解，利用交付散点、累积流图、缺陷趋势、发布效率等过程度量对其进行衡量。对其抓手，主要是从三方面展开：

·需求侧：明确目标、打法、功能，确定产品需求组织，将需求拆分、针对性沟通；

·交付协作侧：保障业务价值流顺畅，梳理工作流程，围绕业务组织协作；

·反馈调整侧：在整个开发过程中，需要不断地进行反馈调整，可以通过效能度量、业务运营数据等进行复盘调整。

下面我们具体来进行分析。首先看一下团队协作方面：

业务为导向的跨职能合作

在互联网开发过程中，常常会发生一些让人苦笑不得的事情：例如我产品设计已经设计好了，剩下的就交给你们了，或是我代码已经全部编写，剩下的就交给你你们了等等。这种就是我们在软件开发过程中各种职能竖井的协作方式。在传统的软件开发过程中，经常是以职能为单位进行相互协作。

如上图所示，产品在其竖井里进行产品设计、开发在其竖井里进行开发、测试和运维也分别对应着自己的职能竖井，彼此之间协作是靠“梯子”来完成，可想而知，在传递过程中效率是极其低下的。组织协作之间为了提高效率，通常会做一大批产品需求交付给开发，开发再将这一批需求开发完成后交给测试，测试再...在整个过程中产生了批量。在整个协作过程中，绝大多数时间都是在等待，从用户视角观察，真正处理事情的时间很少（如上图绿色线条所示），整体效率相当低下。

在不同工作职能之间往往还存在博弈关系，例如产品经理希望开发的功能越多越好，所需时间越短越好，而开发人员则希望尽可能减少开发需求，并增加开发时间以实现功能完善。那这个问题应该如何解决呢？

我们采用的解决方案是从职能之间的抛接变成以业务为导向的跨职能合作，将项目所涉及的人员按业务进行区分，例如A业务包含自己的PD、UED、前端、后端和测试。这种以业务为目标的组织方式，所涉及的人员的目标就变成了从完成对应的任务，到尽快交付特定业务需求；另外，这种组织方式使得开发、测试、前端等之间的沟通变得顺畅，大家基于相同的上下文进行探讨，提高了沟通效率。之所以仍保留职能团队，是为了促进个人的技能培养。因此，从业务交付角度出发，以业务能导向组建跨职能团队；从人员技能培养方向出发，以职能为导向组建职能团队。另外，我们也提倡在一段相对固定的时间内，团队成员比较固定在某一业务团队、服务某一特定业务，这种方式使得每个业务都有相对固定的人员配置，资源调配就更不容易出现瓶颈。；同时也支持一定的跨业务的人员流动，以保证人员对业务知识广度的积累。

这是从人员的组织角度出发以业务为导向进行的跨职能合作，下面我们将从协作的角度出发来分析提效策略。

按需求进行协作和流动

在软件开发的协作过程中，存在大量细节和合作，整体过程中很难去区分关键点所在。因此，可视化就显得尤为有必要。

在闲鱼提效转型过程中，我们设计、制作了很多块上图所示的板。在上图所示的白板上，首先明确了协作工作流，如需求开发过程中所经历的阶段、上下游之间的关系；另外一点是所有步骤均是以需求为单位进行协作。板上蓝色框中表示整体工作流，红色五角星是确定每个需求的流转规则。

为什么以需求为单位进行协作和流动？首先，我们交付给客户的是业务价值、特性、功能。最早采用的任务板方式，发现所有人都很忙，每天做了很多事，但是一回溯，发现需求没有完成。因此，关注任务板不如关注价值板，因此我们制定了上图所示的需求价值版，关注价值的流动，让价值更快的流动出去。价值板包括很多阶段，上图红色框中包括横向五条甬道，它表示在开发过程中，开发团队最多只支持五个需求的并行开发。之所以限制并行的数量是为了提高缩短开发周期，使得需求更快速流动。

橙色框在价值板上呈现的是发版节奏，涵盖web和移动端；图中绿色框中表示的是可视化资源池，资源池中的每个人对应两个点，表示参与两个需求，清晰地展现人员在需求上的配置。通过价值板，我们能够清楚地看到需求累积的位置，上图显示需求累积在选择阶段，并且在视觉出现了中断，这样就很容易地可视化所有问题并定位。此外，通过价值板还可以关注发布版本的节奏，每天站会时从右往左沟通，是否有需求发布、灰度、测试、走查、开发，形成拉动的过程（优先级自上而下）。最左下角是未来可能开发的产品和需求，提前确目标和打法，提前组织和沟通。

有了这么一块价值板之后，效果怎么样呢？

上图是之前和现在每天晨会的对比图。之前是项目经理同步项目进度和状态，绝大数人都在做自己的事；而现在，以业务为导向的团队在一块板前做晨会，团队中每一个人都在协调需求的流转。

看板视图取自云效公有云(https://www.aliyun.com/produc...

当团队成员处于异地工作时，在一块物理板前开晨会不太现实。针对此类问题，我们将物理板升级为云效电子板，内容同物理板相似，使得远程同步变得更为简洁。通过价值板的方式，我们将工作流程可视化出来，通过晨会、板上限制并行数目等方式控制价值流动。

那么价值板上需求和业务目标存在什么关系呢？需求之间有哪些关系呢？业务目标和需求之间的关系是什么呢？下面将从功能服务关联目标的角度回答这些问题。

让功能服务关联目标

如上图所示的过河，不同的人采用不同的方式，过河是目标，从河上过是架桥、从河下过是挖隧道，如果打法不一致，显然会对不齐。

在软件开发过程中，我们也会面临类似的问题，因为业务职能和开发职能面对的语言不同，业务职能面对是领域方面的概念，而开发面对的是某一设计模型、算法等。这时，如何打破业务职能和开发职能之间理解、沟通和协作的隔阂就显得尤为重要了；另一个挑战是业务目标和产品功能之间的关系较为模糊，不一致。比如业务目标是转化率提高百分之三十，那么对应的产品功能应该增加什么呢？它们彼此之间的联系是什么呢？

我们可以通过黄金圈法则的方法表示从业务目标到产品功能项。如图所示，在黄金圈的最内层是Why，中间层是How，最外层是What。其中Why表示业务目标，How表示的是业务打法或业务场景；What表示产品功能。通过Why、How、What的方式进行梳理，我们可以确定所开发的产品功能的业务目标，也能够很好确定功能需求的开发顺序。

上图是根据黄金圈规则制定的具体案例。从业务大图中确定产品路径，在产品路径中根据业务目标分解成若干个关键指标，识别关键功能，要实现比如搜索相关性提高多少倍等关键指标，针对不同的方式，采用的方式也不尽相同，这里分别列出来Why、How和What。这一路径图通常贴在价值板的旁边，定期组织业务团队同步目前所处的业务目标、打法和功能，实现团队的对齐。

前三部分更多讲的是业务团队、协作和功能识别，最后来看一下如何实现持续改进。

度量数据服务转型提效

没有度量的洞察，管理无异于盲人摸象。因此我们需要完整的度量数据或能够提供洞察的数据来帮助我们识别所管理的对象。

更多数据度量维度参考云效度量功能

回到交付响应周期/开发响应周期上来，通过需求在不同阶段的流动过程，很容易确定需求的前置时间、在某个阶段的耗时。上图左侧显示的是需求占用的时间较长（蓝色表示需求时间、绿色表示开发时间），而右侧图需求阶段和开发阶段是1：1的关系，那么我们就需要思考为什么在需求侧耗时这么久。

另外一个衡量方式是交付频率、缺陷和累积分布。

交付频率、缺陷和累积分布

更多数据度量维度参考云效度量功能

上图分别是交付频率、缺陷和累积流图。需求交付散点图中每一个点代表一个需求发布，纵轴表示发布时累积时间长度，横轴表示发布的时间点；左侧需求累计图表示需求在不同阶段累积的数量，高度表示积压的在制品的数量，横向可以确定其在某个阶段的前置时间长度；缺陷趋势图中红色柱子表示新发现的缺陷数目，绿色柱子表示当天修复的缺陷数目，随着时间推移累积而成。

度量或指标存在两面性，有时选择的指标不够好时，对团队整体的杀伤性非常大，因此应该选择好的度量或指标。那么，如何确定好的度量或指标呢？

更多数据度量维度参考云效度量功能

好的度量一是应该简单，不复杂；第二好的度量应该表达是一个完整“故事”，而非某个信息点；第三好的度量应该能够触发一个行动。正如需求在电子看板中呈现，在云效中，也可以将度量数据可视化，如上图所示，可以展示需求累积流图、有效缺陷平均关闭时长、缺陷趋势图、需求研发阶段平均停留时长等数据，通过这些数据能够帮助我们在研发效能进行改进。

未来发展规划

建立功能业务闭环

对于产品交付之后的反馈机制，我们仍在努力中。下一步的工作一是建立功能业务闭环，首先确定产品阶段目标和打法；之后快速进行功能需求交付；此后再根据运营数据的反馈和分析，再确定下一阶段的产品目标和打法，形成功能业务闭环。

持续集成发布体系

未来的另一个工作重点是建立持续集成发布体系，主要包括如下工作：

·缺陷回顾分析机制的建立（RCA/EDA）；

·持续集成/发布管道的梳理完善；

·持续测试分层

·自动化

通过上述机制保障，能够显著提高产品发布效率。