2017.09.08 丨 msup

【万字长文】何勉:精益、敏捷产品开发和创新管理线上分享实录

2017.09.08 丨 msup

本文为何勉老师线上分享《精益、敏捷产品开发和创新管理》实录,后附与学员的互动问答。

编辑:Cynthia


一、业务视角下的敏捷产品开发


1.1 敏捷开发的含义



敏捷产品开发,一百个人有一百种理解,敏捷本来就是一个集合性的名词,讲到敏捷大家可能会联想到:scrum、xp、测试驱动开发、看板、持续集成、持续重构、技术卓越等等这些词,还会联想到与价值观相关的部分,比如说:应对变化、自组织、适应性等等。

 


这样讲没有问题,但这对我们理解敏捷真正的含义并没有太多的作用。有一位软件工程界的宗师级人物曾说过:“如果你过去问我支不支持敏捷,我可能说支持或不支持,并给个理由,现在只能说支持了,因为现在敏捷指的就是软件开发中一切好的方面,如果有什么不好的东西那就表示不够敏捷。”这样的说法对于敏捷的推广或许有好处,但对真正理解敏捷和实施敏捷而言却不然。



德鲁克说:任何组织的绩效都只在外部反应出来。外部就是给你带来价值的地方,也就是用户或者客户。敏捷作为一种管理的手段或方法,存在的目的是帮助组织取得成效。其责任是协调资源取得成效。不管是方法或技术都是为了成效服务的。


1.2 敏捷的业务目标:更快(早)地交付价值




想要理解敏捷,必须回到业务目标,这是根本。敏捷的对立面经常是瀑布,上图左边就是一个瀑布模式,开发分成分阶段:需求-设计-开发-测试,每个阶段形成一个瀑布流,这种瀑布流的开发方式存在的问题是:价值交付只能是在最后。横坐标代表时间线,就是在全部做好之后一次性交付价值。


一次性交付价值存在的问题:根据摩尔定律,每18个月之后用同样的钱可以买到一倍的东西。反过来看, 18个月之后交付的话只能得到今天交付的一半的价值,越迟交付的是越少的价值,这是针对硬件产品来说的,对于软件产品和互联网时代做的产品而言影响更深,越迟交付的产品可能面世的机会都没有,获得超额利润的机会也没有。


面对在瀑布开发下延迟交付的情况,敏捷提出的解决方案很简单:迭代。每一个迭代交付一部分价值,这部分价值因为交付得早就意味着更多的价值。敏捷的业务目标:更快(早)地交付价值。这里的快不是绝对速度与流量的更大,而是指交付的时间更早。


1.3 敏捷的业务目标:更灵活的响应变化



再来看敏捷开发的第二个业务目标。图的左边也是坐标图,表示一个项目,横坐标是时间,从项目开始到结束;纵坐标是团队对这个项目或产品所拥有的知识和了解。 什么时候团队对于项目的知识和了解最丰富?显然是结束的时候。另外一个有意思的问题是 什么时候做出对项目最重要的决策呢?开始的时候。


也就是说我们往往在知识最匮乏、了解最不够的时候做出最重要的决策,并把这个决策当成事实来对待,后面发生的事情很难反映到项目中去,知识的累积也很难反映到项目中去。这是知识累积和决策时机之间的悖论。


敏捷应对这个悖论的方法是:决策是增量做出来的,每个迭代做出一部分决策,交付一部分产品,得到相应反馈,并根据反馈再做下一个迭代的决策,不断获取反馈应对变化,这个反馈可能是交付之后的,也可能是市场或竞争对手的变化带来的。


敏捷的第二个业务目标:更灵活的响应变化。也就是说通过增量出决策,不断交付获取反馈,积累更多知识,并应用这些知识做出更正确的决策,更灵活响应变化,这个变化包括主动的知识积累,也包括市场的变化、竞争对手的变化、团队对项目的了解。


1.4 敏捷就是敏捷



综上所述,可以从业务角度对敏捷做一个解释:敏捷就是敏捷

(able to move quickly and easily)。


对于产品开发而言,敏捷的目标是:创建一个组织更早地交付价值,更灵活的应对变化的能力。敏捷对于业务层面来说是一个目标,对于一个组织来说是一种能力,这种能力是必备的,帮助我们在今天的市场和业务环境下取得成功。


当我们清楚了敏捷是一种目标一种能力的时候,我们对敏捷的理解就能达成共识:我们需不需要这种能力?这是不是我们的目标?这对于我们取得竞争的胜利有没有必要?而在今天这个竞争的业态,敏捷是一种组织必须具备的基本能力。所以我们需要讨论的是如何具备这种能力,如何变得更敏捷。下面会讲一些方法和实践,都是为这个目标服务的。


1.5 敏捷产品开发的方法和实践



为了实现敏捷的业务目标,我们需要迭代和持续交付。这为我们带来的新的挑战是过去传统的方法不适用了。随着更多问题的提出,也相应地产生了一系列方法和实践:


  • 比如怎么管理迭代交付的过程呢?于是就有了scrum、FDD、测试驱动开发、XP(极限编程)的管理实践和框架来帮助我们管理迭代开发的过程,这些实践都是为目标服务的;

  • 每个迭代交付什么,怎么规划?于是就有了产品代办列表、用户故事、故事地图等实践。

  • 每个迭代都交付一些,那么测试工作量或回归工作量会不断递增,怎么应对不断增大的集成和回归测试工作?于是就有了测试驱动开发、自动化测试、TDD;

  • 如何沟通需求,于是就有了行为驱动开发、实例化需求等方法;

  • 如何保证代码的演进或演进式的迭代,于是就有了代码共有、简单设计、持续重构、领域驱动设计、演进式设计等方法。


业务目标是why,为什么要这么做。这些方法都是服务于业务目标,解决了how的问题。其实大部分时候这是必然的选择,必须实现这个目标,在这个前提下再来想怎么做。当然这并不容易,不是这些实践的简单累加就会敏捷了,还需要系统地形成方法。


二、精益产品交付过程


最近两三年的时间,精益这个词变得非常热门,凡提敏捷处必有精益,好像不提精益感觉就不酷似的。我们先看精益产品开发是什么?


2.1 现实的挑战



上图我们称之为waterfall,我们都知道waterfall不好,它不能应对变化、延迟了价值交付,那要怎么办?




现实的第一个挑战:开发环节的迭代并不带来真正的价值交付和真实反馈。


我们需要引入迭代开发,比如scrum、xp。图中的waterfall是从需求开始到测试结束,但是现实中可能不一定是,现实中在需求之前可能还有产品规划、产品定义,可能还有更早的一些探索,测试之后还有实施、验证、调整等,这时候我们发现在更大范围来讲其实还是一个waterfall,如上图所示,只不过在开发阶段实现了所谓的迭代,但并不能真正实现迭代的价值交付。


我们把这种模式称之为:water-scrum-fall,我们理想的目标是通过迭代更早地交付价值、更灵活的应对变化,但事实上仅仅是开发环节或者工程团队环节的迭代,并不能带来真正的价值交付,也不能得到真正真实的反馈,那么我们需要做得更多,需要更加端到端。




现实带来的第二个挑战:单个团队的实施也无法交付完整的用户价值。


在大的电信公司,比如华为,去做这个事情的时候会发现,为了交付一个价值需要多个团队,华为称为多个网元,不同的网络设备,每个设备都可能涉及到几百人上千人,这时每个设备下面可能会分成不同的功能团队、或者叫特性团队、模块团队。整个需求是分层的,在华为解决方案层面对应的需求是客户的原始需求;网元层面对应的是功能性需求;模块层面对应的是可分配需求,这时你会发现单个模块团队去敏捷不可能端到端,无法交付完整的价值,也无法得到反馈,所以我们为了更早地交付价值,其实就需要协调多个团队。


总结起来就看到了理想和现实的差距:理想是更快地交付价值,更灵活地应对变化;现实是:在开发阶段或者在团队实现阶段去做敏捷,或做单个团队的敏捷,往往不能带来价值的完整交付和灵活应对变化,这是很多团队面临的挑战。


2.2 精益:顺畅、高质量地交付价值



精益是解决这一类问题的方法,精益作为一个思想比敏捷产品开发诞生得更早,遇到这样的问题可以诉诸于精益。那么精益是什么?维基百科上对精益的定义是:精益思想是关于有效组织人类活动的一个新的思维方法,目标是消除浪费,更多地交付对个人和社会有用的价值。概括为两个核心点:消除浪费、增加价值。


针对产品开发来说是顺畅、高质量地交付真正的价值。


怎么去实现呢?精益真正区别于其他的方法并不是它的目标更好,而是它有与这个目标相适应的一整套方法学和实践,接下来要说的是如何实现顺畅和高质量地交付价值。


2.3 资源效率和流动效率的同步提升



上图是精益产品开发里一个比较核心的概念图,说的是我们对待效率的不同态度。很多改进一定程度上都是在提高效率。我们把效率分成流动效率和资源效率:


资源效率是资源的使用率和产出,比如工程师的产出、每个设备的产出,资源产出越高效率越高,这是资源效率;


流动效率是从用户的角度去看,一个用户的需求从提出到交付整个流动的速度,从提出到交付流动的时间,流动速度越快效率越高。


上图的四象限:


  • 左下是一人干活十人围观,其资源效率和流动效率当然都是很低的;

  • 右下是消防员,其实消防员的流动效率是很高的,一旦用户提出需求,他可以在第一时间响应,一点都没有等待,但他的资源效率很低,大部分时间都处于待命;

  • 左上是炼钢炉,炼钢炉的情况是它一旦开启后面的东西必须配合排队,因为炼钢炉的耗费是很大的,必须保证他资源的利用率而待加工的物料(用户价值)则在后面排队;

  • 右上是快递公司,快递公司对资源效率的要求是很高的,因为关系到成本,对流动效率的要求同样也很高,因为这关系到对用户的服务。


对于产品开发来说,我们希望效率跟快递公司类似,也就是说资源产出要高,对用户的响应速度要快,用户的需求从进去到出来的时间要短,绝对速度要高。如何达到这一点是我们真正要关注的地方。



在传统的方法里,我们都会更注重资源效率,这是有原因的,我们改进的的时候会改进开发的效率、改进需求产出的效率、改进测试的效率,因为对于我们的管理方式来说,我们看到的就是一个个职能部门,而这种效率的改进到最后往往都是起不到效果的,因为简单的改进你都会做到,剩下的局部优化往往会影响到系统的性能,即整个的有效产出。这就会产生一个个的效率竖井,设计开发运维,一个个看上去效率都很高,但是事实上有效地价值流动却不能产生,系统并不是最优化的。


我们习惯聚焦于资源效率,宏观地来看在整个开发过程中开发和运维这两个大部门其实也是在关注各自的资源效率,然而很多时候这种效率的提升是没有用的,局部优化带来系统的劣化,这是一个非常普遍的情况,所以仅仅聚焦于资源效率产生的是效率竖井,精益产品开发对此提出来不同的看法。



如图所示,如果我们沿着资源效率的改进继续下去,会发现过度的局部优化损害的是整体的效率,并带来全局协调的困局。也就是说你看上去提高了资源效率,但最后它由于整体协调的困局,资源效率的改进也是无以为继的,这种情况特别普遍,对于很多一直在做效率改进的部门,如果一直沿着这条路走下去,各个部门单独改进,最后流程变得原来越来越复杂臃肿,整体效率很难提升。


我们热衷于改进资源效率,因为我们每天都能看到资源效率,而流动效率则不然,用户需求从进去到出去这个过程是看不见的,我们看到的是谁忙不忙,一天能产出多少代码,因此我们更倾向于去改进看得到的东西,这是很正常的。



上图中一个醉汉在路上寻摸了差不多半个小时,警察一直在旁边看着,实在看不下去了就问醉汉在干什么。醉汉说我在找我的钥匙。警察看了一下说这儿没有钥匙。然后又找了一会儿说:你钥匙是丢在这儿了吗?醉汉说:不是呀。警察又问那你为什么在这儿找呢?你知道醉汉怎么回答的吗?醉汉说:只有这儿有光啊。


资源效率是我们能看到的地方,却不是关键(Key)所在。我觉得这个隐喻很精确。


2.4 精益产品开发三步走


有一个精益产品的大师说:在产品开发中,我们的问题几乎从来不是停滞的资源(或不动的工程师),而是停滞的产品需求(用户价值)。但这个问题是很难看到的,那么我们在精益产品开发中怎么来处理这个问题,其实就有了答案,首先得看到需求流动的过程,看到了才能去改变。




第一步:理清价值流,约束在制品数,改善流动效率


精益产品开发的第一步是:提高流动效率。让用户的需求批量降低,并减少排队和拥堵,让它在整个研发过程中顺畅地流动起来,从进去到出来的过程时间尽量短,等待尽量少。



我们首先要做的事情是以用户价值为核心,打通整个组织的价值交付链条。就是要去分析这个价值流,然后识别和消除那些明显不合理的部分,让从用户的问题到解决方案的过程越短越好,这就是改进流动效率的第一步。



要做到可视化,要分析和可视化端到端的价值流动过程。质量管理之父戴明说过一句话:如果你不能以一个清晰的过程来展示你所从事的工作,你就不会真正地了解你在做什么。产品开发所从事的工作就是交付用户价值,从用户问题出发到交付解决方案。


我们做的就是要可视化端到端的价值流动过程。


工具:看板



看一个团队的看板,这是一个端到端的交付过程,蓝色的纸条从需求提出到设计到向开发团队澄清然后是就绪,就绪后我们称之为用户故事,这里的就绪是指对开发团队就绪了,开发知道验收标准了,相应的技术风险也分析了,之后一大段是实现中,这个实现中被划分成很多横向的条,这些条被称之为泳道,每个泳道里是一个需求(白色的纸条),后面的蓝色和黄色纸条是这个需求对应的任务,任务里分属不同的列和模块。


当所有的任务结束后,这个故事就可以拿到验证、待验证、待验收、已交付,流经整个过程。《精益产品开发原则、方法与实施》一书对此有详细的介绍。



从这幅图可以看到,这是一个端到端的交付过程,最前面一段是产品,最后一段去验收交付的也是产品,中间一段是研发的过程,这是一个2B的产品,无法让用户直接参与,所以产品代表用户去发布和接收需求,一定程度上是从用户开始到用户结束的一个端到端的价值流动过程,我们也看到研发即所谓的实现阶段,反映了团队的协作,不同的模块团队协作去交付这个故事,也看到了需求分解和合并,需求分解成任务,任务完成后再合并成需求去测试。


右边需求上贴着红色纸条是bug或问题,表现缺陷、问题和阻碍。


这个看板清晰地反映了三个方面:需求的交付过程、各个团队的协作怎么去交付一个需求、需求的分解和合并。



这里能看到需求的流动,比如泳道数是有限的,团队并行开发的需求数目是有限的,这个有限有一个好处:我们要尽快地完成那些已经开始的需求,如果泳道满了,你也不应该开始更多的需求。也就是尽快交付已经开始的价值。如果这个交付过程中间有问题,因为泳道数量有限,很快能看到拥堵,问题也会及时暴露出来,及时解决。所以更加注重需求的完成,而不是需求的开始,也就是说我们是以价值交付来驱动整个过程的。



除此之外,我们还应该看到它反映的流动过程,及其背后的规则,比如一个需求从一个阶段进入到另一个阶段需要满足怎样的规则。上图给出了两个规则示例,所有进入就绪的故事必须满足:


  • 必须完成实例化需求活动,开发、测试和业务共同澄清需求,并定义明确交互过程和验收标准;

  • 大需求已拆分为工作量在两周以内的故事;

  • 已与业务关联方确认相关计划;

  • 识别大的技术风险并定义应对方案;

  • 需求已经入库;

  • 涉及三个(含三个)开发人员以上的需求,执行好协调人,负责进度协调。


所有移交测试的需求需要满足:

  • 并入正式的版本,并通过持续集成环境的检验

  • 开发对照实例化过程中的验收标准进行了自测。


其实这些流动过程加上规则就构成了团队是如何操作这些需求的,也就是戴明所说的我们以一个清晰的过程来展示我们所从事的工作。


这样一块看板

  • 清晰全面地反映需求和需求交付的过程;

  • 瓶颈和问题能在看板上得到即时体现;

  • 团队可以根据看板信息协作和做决定。


但这只是一个基础,它分析了价值流,也可能会对价值流做适当的优化,但是我们还需要基于这个基础对价值流做一些管理,让其顺畅流动,这是下一步要解决的问题。


第二步:有效地提高资源效率



我们最终要实现的是资源效率和流动效率的同步提高。但我们必须从流动效率提高,才能保证全局的协调,就是整个价值交付链的协调,涉及到需求、开发、业务,测试,如果从流动效率开始的话就能保证他们的协调一致,然后再以此为基础进行资源效率的改进,这时候的改进才可以为继,否则如果从资源效率开始就会陷入协调的困局。所以效率改进的第二步是:在流动效率保证的基础上有效地提高资源效率。


工具:实例化需求



看板记录了价值流,在此基础上我们要去管理价值流,比如一个需求怎么进入就绪,需求的分析过程这里不详细展开,通过实例化需求分析和澄清需求,或拆分需求,实例化需求是分解需求的很好的方式。


工具:站会



流动过程中看板反应了问题和瓶颈,怎么通过站会来促进价值流动?站会不是检查每天的工作的,而是促进价值流动的。标准的Scrum站会更多的是陈述每个人的工作,是以做什么优先,看板的站会是以价值流动优先的,关注流动,解决流动中的问题,所以一般效率会高很多。



前文讲的只是两个例子,怎么去管理价值的流动,主要是价值的输入,比如需求填充的过程、就绪队列的过程、价值流动过程的管理,还有输出,发布部署等,都是为了促进价值的顺畅流动。


现实是做了流动管理后,价值的流动过程还会有这样那样的问题,比如质量、进度、协调的问题,这时候怎么办?


为了分析和看到这些问题,就会引入精益的反馈和度量方法,在这里也不详细介绍。每个方法都会对应自己的度量,精益的度量有其独到之处:以价值流动为核心的,比如累积流图,是比较精确地再现了价值流动的过程、团队协作的过程,从而发现并衡量这些问题


持续改进是精益产品开发的一个核心,也是精益思想的一个核心,通过持续改进来实现价值的顺畅流动,通过各种度量来反应问题,支持这种持续改进,所以精益在这方面是有其独到之处的。

 


在这里我们讲的是,通过反馈来收集定性和定量的反馈,并定期分析这些反馈,然后落实为具体的行动,比如流程操作,而这种操作会反应到看板和背后的规则上去,也有可能是其他方面,比如基础环境、代码设计、测试守护、人员能力,具体行动改进落实后再通过反馈看改进的效果,我称之为反馈、分析、改进的循环。有点类似于戴明的PDCA。


和PDCA相比少了一个计划的过程,在精益产品开发中是把持续改进内建到产品开发过程中,所以没有单独的计划过程,反馈、分析、改进是一个持续的内建的过程,内建到开发和交付的过程中,其结果是反而比较容易落实。


第三步:提升效率边界



第三步是说效率是有边界的,不可能资源效率和流动效率同时达到100%,前面图片中消防员为了达到自己的流动效率,其实是牺牲了资源效率的,为了能及时响应火情,大部分时间是待命的,但产品开发希望两点都比较高,最好是能接近于理想值。所以怎么能突破这个平衡点是我们又一个要考虑的问题。《精益产品开发原则、方法与实施》一书对此有详细的介绍,时间关系就不多说了 


2.5 总结


精益产品开发的改进其实是从流动效率开始的,首先要可视化端到端的交付过程,然后管理好价值的流动,在管理好价值流动的情况下,再去发现这些问题,提高资源效率,我们希望保障全局的协调,这是以用户价值为核心的改进。怎么让它端到端的打通保证产品价值的交付,并做到真正交付有效的价值。这是精益思想的独到之处,


第二步也讲了,最终我们还是要改进产出效率,但是必须是基于可持续的改进,全局的改进,在全局协调、用户价值顺畅流动的基础上,再去改进和保证流动的速度更高。



媒体联系

票务咨询:赵丹丹 15802217295

赞助咨询:郭艳慧 13043218801

媒体支持:景    怡 13920859305

提交需求