什么是真正的敏捷开发?阿里资深技术专家内部分享公开
    2018-10-31    何勉

阿里妹导读:从本质上讲,敏捷开发的一个重要目标是建立持续价值交付的能力。这种能力最终必须服务于业务的创新,促进业务的成功。

 

今天,阿里巴巴云效平台敏捷教练团队负责人、资深技术专家何勉老师,将从敏捷开发的目标、定义这两个维度带我们探索敏捷研发的冰山一角(本文内容来自阿里巴巴内部培训课程整理)。

敏捷开发业务目标

 

我们经常会说敏捷模式,那什么开发模式是不敏捷呢?对,我们通常说“瀑布”是不敏捷的。

 

瀑布开发模式把开发分成一系列阶段,如需求、设计、开发、测试,就像上图它画出来的,看起来很像瀑布,所以叫瀑布开发。问题是需求的交付难道不都是要经历这些阶段吗?

 

瀑布开发的本质问题并不是阶段,而是批量。需求批量地在一起进行设计,然后是批量地开发,批量地测试、交付等等。批量有什么问题? 首先,批量让价值交付延迟,所有需求在最后的阶段才能交付,价值交付比较晚。

 

 

价值交付比较晚又怎么样?看这幅图。左边是Intel的创始人摩尔,摩尔定律的提出者。摩尔定律告诉我们,18个月之后,用同样的钱能买到多一倍的东西,比如计算能力、存储量、晶元数等等。而右边这位是Google执行董事长施密特,他提出了反摩尔定律,表述为:“如果18个月之后我们只能卖出跟今天一样的东西,我们就只能得到一半的收入。”

 

反摩尔定律是摩尔定律的一个简单推论,它告诉我们,越迟交付的价值也是越低的价值。对硬件公司这很关键,甚至决定它们的的宿命——技术进步必须跟得上摩尔定律,否则利润就会被摩尔定律吞噬,让产品或公司走向灭亡。

 

软件或互联网服务又怎样呢? IBM在上世纪90年代,意识到不能做一家硬件公司,转而主攻服务和软件行业,它的确过了一段好日子。然而,很快互联网时代到来了,软件和服务行业的创新一下子加速了。这时,相对硬件公司,反摩尔定律在软件和互联网服务公司的作用是有过之而无不及的,时间的迟早可能不仅仅决定价值的多少,有时错过整时间窗,可能会一无所获。

 

 

反摩尔定律告诉我们,越迟交付的价值也是越低的价值。所以对于软件开发来说,瀑布模式延迟了价值交付,得到的价值也更少。相对瀑布,我们提出了迭代交付,我们把开发分成迭代,每个迭代交付一部分价值,更早交付的价值往往意味着更多的价值。就这一点来说,迭代相对瀑布的本质是,更小批量的快速交付,从而更早获取更多价值,和获取市场竞争的先机。

所以敏捷开发有第一个目标就是更快的交付价值,这里的快指的不是绝对速度,而是更早的交付。

第二点,我们再看一个坐标图,这个坐标是项目的时间历程,最左是项目开始,最右是项目结束。纵坐标是团队拥有的这个项目和产品的知识,比如说用户要什么,采取什么样的产品方案,应该做什么样的功能,以怎样的形式来协作,选择什么样的技术方案等等。

 

我们想问一下团队(包括产品也包括开发、业务)什么时候对于产品和项目的知识最充分、最多?大家的答案都很一致,项目结束的时候。这显而易见,我们在项目进程中积累了知识,特别是当向用户交付产品后,用户反馈:“我要的不是这个啊,我说的明明是……”,这时候你瞬间狂涨知识,并感叹道“你怎么不早说呢?”。这中间可能有沟通问题,但更多可能的是,用户这时才清楚或能够描述他们要的是啥,更有甚者,我们可能一开始连用户是谁也未必能准确地定义。产品和业务开发本来就是一个探索的过程,开始时一定是最无知的时刻。

 

再问一个问题。项目中的大部分决策,是什么时间做出的呢?大家的答案也很明确——项目开始的时刻。这里埋藏了一个重大的悖论,我们在最无知的时刻,做出了最重要而且是绝大部分的决策,并把它作为随后执行的依据。面对不确定的技术、市场环境,传统开发模式已无法适应要求,悖论越发突出。

 

 

对于这一悖论,敏捷的对策还是迭代。开始时,我们会做出一些初始的决策,比如说总体目标是什么,大概的策略和打法是什么,从哪里开始,怎么检验等等。但这些只是初始决策,定义了大致的方向。在整个开发过程,我们迭代交付需求,获取市场的反馈和最新的信息,并基于这些反馈和信息,积累和修正对产品的认知,增量地决策和调整。

产品开发过程中,技术环境、市场环境、竞品策略、团队认知都会发生变化。面对变化的环境,我们必须承认自己的无知,在开发过程主动有效地学习,不断地汲取反馈,灵活地调整。这也是敏捷的第二个业务目标,有效学习和灵活响应变化。

 

 

综合上面提到的敏捷开发的两个业务目标,我们就可以给敏捷开发下一个定义了。敏捷指的是创建一个组织更快(早)的交付价值,和更有效学习和灵活应变的能力。

 

 

从能力的角度,敏捷的核心是持续交付价值的能力,以及以持续交付为基础的快速反馈学习能力。为了具备这样的能力,产品的开发和交付方式需要做出根本变化。这幅图从概念上体现了,传统批量式的开发方式到敏捷的持续交付方式的转变。

 

传统开发方式下,需求成批量的流经各个阶段和组织部门,如产品、UED、开发、测试、运营等直至交付,各个职能各自优化自己的工作,形成效率竖井。由于批量的原因,需求等待整个批量完成,才能集中进入下一阶段。从单个需求的角度看,需求大部分时间都处于等待状态。

 

上图的右半部分表达了这一过程,单个需求的实际处理的时间很短(图中折线中上面绿色的短线),它们大部分时间都处于等待状态(图中折线下面红色的长线),最终表现出的实际交付周期很长。

 

通过敏捷实施,我们希望整个组织协调一致,更紧密协作,缩短交付周期。图中左半部分是理想的敏捷开发模式,它体现了敏捷开发的基本目标——持续价值交付和快速反馈、学习,这其中持续价值交付是基础。

问题是如何才能建立和改进持续价值交付能力呢?

 

定义

 

管理学之父德鲁克说:“如果你不能度量它,你就无法改进它。”对于持续交付能力,这同样适用。

 

有效的度量体系应该围绕核心问题展开。在这里,这个根本问题就是团队的持续价值交付能力如何?我们将用五组指标来回答这一问题,它们分别是:

 

第一:发布能力,具体包含两个细分指标,分别是:

 

1)发布频率,也就是团队平均多长时间发布一次需求。它约束了团队对外响应的最大可能;

 

2)发布前置时间,也就是从代码提交,到功能上线所需要花费的时间。如果时间开销很大,团队就不太可能去加大发版的频率。

 

第二:需求响应周期,它包含两个细分的指标,分别是:

 

1)交付周期时间,也就是从用户提出需求并被确认,到需求上线所要经历的时长。它反映团队(包含业务、开发、运营等职能)对客户问题或业务机会的整体响应速度;

 

2)开发周期时间:从开发团队理解并确认需求,到需求可以上线所经历的时长。它反映研发的响应能力。

 

第三:交付的吞吐率,也就是单位时间内交付的需求的个数。

 

第四:内建质量的能力,也就是整个交付过程的质量。它包含两个细分的指标,分别是:

 

1)开发过程中缺陷的创建和修复时间的分布。我们希望缺陷能够及时且持续地发现,并且在发现后尽快修复;

 

2)缺陷库存,我们希望能在整个开发过程中控制缺陷库存量,让产品始终处于接近可发布状态,奠定持续交付的基础。关于内建质量的能力的具体度量方法,我们后面还会详细介绍。

 

第五:对外交付质量。它包含两个细分的指标,分别是:

 

1)单位时间(线上)问题数目;

 

2)(线上)问题平均解决时长。

 

 

好的度量体系应该回答一个根本问题,并为此讲述完整的故事。为回答团队交付能力如何这一问题, 上面5组指标,分别从响应能力、效率和质量三个方面提供一个完整的故事。其中,持续发布能力和需求响应周期这两组指标反映的是响应能力,也就是价值的流动效率;交付吞吐率这一指标反映的是团队效率,也就是资源的产出效率;内建质量的能力和对外交付质量这两组指标是质量指标。这些指标综合起来,让我们可以全面了解当前交付等能力,与目标的差距,以及改进的机会。

 

 

以上是度量体系的总体设计,我们把周期时间作为衡量团队响应能力的核心指标。这幅图更直观地展示了两个周期时间的计算方式,以看板的工作流为基础,客户周期时间的起点是从需求被选择开始,到需求发布结束;开发周期时间则从待开发开始,到待发布结束。

 

基于上面的度量指标体系,我们选择和设计了相关的图表,来呈现这些度量。下面我们介绍其中的一些例子。

 

 

第一是累积流图。累积流图再现了团队协作交付价值的过程,它的横坐标为日期,纵坐标为各阶段累积完成的需求数目。从左至右的各条线,反映各个阶段累积处理完成的需求数量。例如:图中最上面这条线是已经就绪的需求的个数,最下面这条线是已经上线的需求的个数,中间这条线分别是已经开发的、开发结束的、已经测试的、测试结束的等等。

 

 

累积流图综合反映了平均交付周期、在制品数量、到达和交付速率三类指标。

 

第一:平均交付时间。交付时间指需求交付之前从开始到结束所经历的时间。图中,到3月26日这一天累积计划了40个需求,而到5月15日这一天累积交付了40个需求。假设需求符合先入先出(先计划的先交付)的规律,那么第40个需求的交付周期时间就是 5月15日 - 3月26日 = 50(天)。之所以要在交付时间之前加上“平均”,是因为并非所有的需求都是先进先出。从累积流图上还可以进一步看出交付时间在各个阶段的分布。

 

第二:在制品的数量。在制品(Work in Process)指正在处理的需求的数目,也就是所有开始但还没有完成的需求的数目。如:上图中4月15日这一天,累积开始的需求有61个,累积上线的需求是8个。在制品数量 = 61- 8 = 53(个),它们已经开始,但还没有交付。从累积流图上还可以进一步看出在制品在各个阶段的分布,如开发中的,待测试的,测试中的等。

 

第三:需求的到达和交付速率。指单位时间内到达和交付需求的数目。图中,从3月1日到3月30日,4周时间交付需求数目从10个增加到50个,共交付40个需求,到达速率 = 40 / 4 = 10 (个/周)。从4月1日到4月30日,4周时间交付需求数目从10个增加到30个,共交付20个需求,到达速率 = 20 / 4 = 5 (个/周)。从累积流图上还可以看出不同阶段的产出速率,以及它们的变化趋势。

 

累积流图再现了团队协作和交付过程,从中我们能够解读出团队的开发模式,演变趋势和改进机会等。例如:从图中上边线阶梯可以看到批量计划模式,而4月开始计划的批量变得更小,发布频率加大,相应的并行的在制品的数目也变少了,周期时间随之变短了,交付的效率(交付线的斜率)也有所提高。

我们再看另一幅图表——缺陷趋势图,它反映了团队引入、发现及移除缺陷的行为模式。图形的横坐标是日期,横坐标上方红色竖条代表当天发现缺陷的数量;横坐标下方绿色竖条代表当天解决的缺陷的数量;橙色曲线代表缺陷存量。通过缺陷趋势图希望引导用户的行为是:持续且尽早发现缺陷并及时移除它们,从而控制缺陷库存,保证系统随时处于接近可发布状态,奠定持续交付的基础。 上图的左右两个部分比较了两种交付模式下的缺陷趋势图。

 

左半部分:“迭代”前期团队集中设计、编码引入缺陷,但由于并未即时的集成和验证,缺陷未被即时发现。到了项目后期团队开始集成和测试,缺陷集中爆发。小瀑布模式过程质量差,带来大量的返工、延期、赶工和交付质量问题。该模式下,产品的交付时间依赖于何时缺陷被充分移除,无法做到持续交付,降低了团队对外的响应能力。

 

右半部分:在整个迭代过程中,团队以小粒度的需求为单位开发、集成、测试,即时发现并解决问题。这样,缺陷库存得到控制,系统始终处于接近可发布状态,做到持续发布,提高团队对外的响应能力。缺陷趋势图可以从一个侧面反映团队的开发及交付模式,衡量团队的持续交付能力,引导团队向持续交付演进。

好的度量应该为回答一个根本问题,讲述完整的故事。我们回答的问题是团队持续交付能力及其改进机会,并针对这个问题讲述了完整的故事。也正是基于以上的体系, 云效项目域对度量体系做了一次重构。上面的图是一个概念说明,大家可以去使用,我们也会根据大家的反馈,持续优化度量体系的设计。

 

阿里内部分享现场阿里内部分享现场

嘉宾简介:何勉老师,阿里巴巴云效平台敏捷教练团队负责人、资深技术专家,国内最早的精益产品开发实践者之一,畅销书《精益产品开发:原则、方法与实施》作者。专注于精益产品交付、精益创业创新及精益产品设计等领域,帮助组织提升研发效能。曾成功帮助阿里内部多个事业部、华为、平安科技、招行以及多家创业公司建立或引入精益产品开发和创新方法。

评论加载中...