本期的分享嘉宾是阿里巴巴阿拉丁团队的资深技术专家何勉老师,何老师也是国内最早的精益产品开发实践者之一,专注于产品开发和产品设计及创新两方面的探索和实践,帮助组织提升效能,使其顺畅、高质量交付有用价值。
本期课程将围绕着敏捷产品开发维度,从敏捷开发的目标、定义和提高持续交付能力、敏捷在持续交付的基础上的创新实践和全栈敏捷四个维度,带我们探索敏捷研发的冰山一角。
大家好,今天我们分享的主题是:《从持续交付到业务创新》,我将从敏捷产品开发讲起。
从本质上讲敏捷开发的一个重要目标是建立持续价值交付的能力。这种能力最终必须服务于业务的创新,促进业务的成功。相对应的,今天分享的内容,包含两个方面,第一:什么是持续交付以及如何建立持续交付能力;第二:以持续交付能力为基础,落实业务创新的实践,形成有效的创新闭环。这是今天分享题目——“从持续交付到业务创新”的由来。具体包含以下4个部分:
第一:敏捷开发的目标;
第二:定义和提高持续交付能力;
第三:在持续交付的基础上落实创新实践;
最后是一个总结,我们会提出全栈敏捷 Full Stack Agile 的概念,它是技术和管理的综合,也是交付和创新的综合。
第一部分:敏捷开发业务目标
我们经常会说敏捷模式,那什么开发模式是不敏捷呢?对,我们通常说“瀑布”是不敏捷的。
瀑布开发模式把开发分成一系列阶段,如需求、设计、开发、测试,就像上图它画出来的,看起来很像瀑布,所以叫瀑布开发。问题是需求的交付难道不都是要经历这些阶段吗?
瀑布开发的本质问题并不是阶段,而是批量。需求批量地在一起进行设计,然后是批量地开发,批量地测试、交付等等。批量有什么问题? 首先,批量让价值交付延迟,所有需求在最后的阶段才能交付,价值交付比较晚。
价值交付比较晚又怎么样?看这幅图。左边是Intel的创始人摩尔,摩尔定律的提出者。摩尔定律告诉我们,18个月之后,用同样的钱能买到多一倍的东西,比如计算能力、存储量、晶元数等等。而右边这位是Google执行董事长施密特,他提出了反摩尔定律,表述为:“如果18个月之后我们只能卖出跟今天一样的东西,我们就只能得到一半的收入”。
反摩尔定律是摩尔定律的一个简单推论,它告诉我们,越迟交付的价值也是越低的价值。对硬件公司这很关键,甚至决定它们的的宿命——技术进步必须跟得上摩尔定律,否则利润就会被摩尔定律吞噬,让产品或公司走向灭亡。
软件或互联网服务又怎样呢? IBM在上世纪90年代,意识到不能做一家硬件公司,转而主攻服务和软件行业,它的确过了一段好日子。然而,很快互联网时代到来了,软件和服务行业的创新一下子加速了。这时,相对硬件公司,反摩尔定律在软件和互联网服务公司的作用是有过之而无不及的,时间的迟早可能不仅仅决定价值的多少,有时错过整时间窗,可能会一无所获。
反摩尔定律告诉我们,越迟交付的价值也是越低的价值。所以对于软件开发来说,瀑布模式延迟了价值交付,得到的价值也更少。相对瀑布,我们提出了迭代交付,我们把开发分成迭代,每个迭代交付一部分价值,更早交付的价值往往意味着更多的价值。就这一点来说,迭代相对瀑布的本质是,更小批量的快速交付,从而更早获取更多价值,和获取市场竞争的先机。
所以敏捷开发有第一个目标就是更快的交付价值,这里的快指的不是绝对速度,而是更早的交付。
第二点,我们再看一个坐标图,这个坐标是项目的时间历程,最左是项目开始,最右是项目结束。纵坐标是团队拥有的这个项目和产品的知识,比如说用户要什么,采取什么样的产品方案,应该做什么样的功能,以怎样的形式来协作,选择什么样的技术方案等等。
我们想问一下团队(包括产品也包括开发、业务)什么时候对于产品和项目的知识最充分、最多?大家的答案都很一致,项目结束的时候。这显而易见,我们在项目进程中积累了知识,特别是当向用户交付产品后,用户反馈:“我要的不是这个啊,我说的明明是…”,这时候你瞬间狂涨知识,并感叹道“你怎么不早说呢?”。这中间可能有沟通问题,但更多可能的是,用户这时才清楚或能够描述他们要的是啥,更有甚者,我们可能一开始连用户是谁也未必能准确的定义。产品和业务开发本来就是一个探索的过程,开始时一定是最无知的时刻。
再问一个问题。项目中的大部分决策,是什么时间做出的呢?大家的答案也很明确——项目开始的时刻。这里埋藏了一个重大的悖论,我们在最无知的时刻,做出了最重要而且是绝大部分的决策,并把它作为随后执行的依据。面对不确定的技术、市场环境,传统开发模式已无法适应要求,悖论越发突出。
对于这一悖论,敏捷的对策还是迭代。开始时,我们会做出一些初始的决策,比如说总体目标是什么,大概的策略和打法是什么,从哪里开始,怎么检验等等。但这些只是初始决策,定义了大致的方向。在整个开发过程,我们迭代交付需求,获取市场的反馈和最新