Bob Jiang Blog

正直、乐观、高效、助人

京东敏捷软件开发套路

Bob Jiang Posted at — Apr 6, 2019 阅读

京东敏捷软件开发套路

##开场语 京东,作为国内最大的电子商务公司,是如何进行敏捷转型的呢?在转型过程中,都碰到过哪些坑,然后又用了哪些套路,得到了什么样的结果。

我将结合自己在京东进行敏捷转型的实践,告诉大家:敏捷的核心是什么?如何进行敏捷团队转型?团队转型需要注意什么?

##背景 京东到家,2014年作为京东一个内部项目,在移动互联网的大浪潮下从一开始就注定了不平凡。京东在2015年重点打造的战略级项目,其中就包含京东到家,即基于京东强大的物流体系,整合各类O2O(线上线下)服务,主要以提供生鲜和超市产品为主。

这次分享中,我主要会介绍在2016年中,给京东到家其中一个20+的团队进行敏捷转型的案例。这个团队主要是负责京东到家的商家入驻后台,内部会和京东到家的各个团队,如业务团队、app团队、结算团队等有交集,外部与京东(包含但不限于法务、财务、审计等团队)、入驻商家、入驻商家IT团队等对接。

##如何转型 前面简单介绍了这个团队的背景,那么这个团队的转型中我们都做了什么,为什么要做这些事情呢。下面和大家一一进行拆解。 ###前提 取得信任,达成一致。

####度量(绩效管理) 达成一致的一个体现就是度量。下面稍微展开说一些关于敏捷度量的事情。更多的信息可以参考吴穹的“研发组织该如何设计绩效体系”

绩效管理的目标

  1. 提高个人业绩表现
  2. 改善组织结果
  3. 决定加薪或升职

1. 提高个人业绩表现
绩效管理的目标之一就是帮助个人提高,或者换个说法,个人在公司里工作的主要动力之一也是可以自我学习、提升个人价值。

反观大部分公司的绩效管理是如何做的呢?

多数公司都是等到了年底的时候,直接经理进行一次性的打分(针对这一年的表现),然后根据这样的打分来决定个人一年的总体表现。这样做,对于提高个人表现有多大的帮助呢?总之,我认为作用不会很大。

2. 改善组织结果
很多组织会有一大堆考核组织(或者团队)的度量指标——多的甚至达到20+。这么多的指标究竟有哪些可以指导组织(或团队)的改进,有哪些有负面作用?

另外,这些考核组织(或者团队)的指标往往掌握在管理者手里(团队成员并不知道)。那么这样的绩效管理对于改善组织结果的作用有多大,是值得商榷的。

3. 用于加薪或升职
正如绩效管理第一个目标(提高个人绩效)中提到的,多数公司是每年(好一点的是半年)做一次绩效评估,然后根据这次评估的结果来决定一个人的加薪或者升迁。这样的话就会导致评估结果不能真实反映实际情况,举个例子,某员工小明,在11月底的代码提交中引出一次线上事故,而在前10个月中小明表现都非常优秀。在这个情况下,小明这一年的绩效评估结果会怎么样?很不幸,估计不会太好。原因如下:1. 尽管小明之前表现非常优秀,但这次犯了错误。2. 尤为关键的是这个错误恰好在绩效评估之前,管理者记忆犹新。

前面我们列举了绩效管理的目标,以及传统按年进行绩效评估的缺陷。那么在敏捷软件开发中,如何进行绩效管理呢?

度量指标的分类
在谈及绩效管理度量指标之前,我先对度量指标做一个粗略的分类。度量指标可以分为:

  1. 内部度量指标
  2. 外部度量指标

内部度量指标
内部度量指标,指的是度量组织(或团队)内部的指标(从内部看)。举个例子,比如个人或者团队的代码行数,单元测试覆盖率,缺陷数等等。

内部度量指标主要用于提高组织(团队或个人)的效率。

外部度量指标
外部度量指标,指的是度量组织(或团队)外部表现的指标(从外部看)。举个例子,比如ROI,客户满意度,NPS等。

外部指标主要用于指导组织(团队或个人)的方向,从而组织盈利或获得成功。

敏捷软件开发的度量指标
选择度量指标的时候,有几个因素需要着重考虑:

最后,针对绩效管理度量,还有两个重要原则:

###推与拉 取得信任并达成一致后,还需要考虑的问题就是推敏捷,还是拉敏捷。

上面分析的是敏捷转型前判断团队的状态,是推还是拉。
那么推拉现象在软件开发当中是否存在呢?比如某个组件的责任,当没有明确到团队或个人的时候,大部分情况下,并不会有人主动去做(同时推)。非常少的情况下出现同时主动去做(同时拉)。

另外软件开发中,大部分的任务是推出去的。打比方,需求方做好需求调研之后,即写好需求文档后就推出去(可能并不是非常显性的)。推出去可能意味着需求方宣布,我们做好了需求调研,写好了需求文档(隐含着说“现在开始需求和我们没有关系”)。这样就做到了推出去了。任务与责任不在需求方了,这时需求方开始进行下一份任务。而实际上对于需求而言,仅仅推出去是不利于需求的完成。需要另外转变一下思路,即进行拉动式生产。

拉动式生产来自于丰田生产系统,是丰田非常成功的理念之一。即生产是根据客户需求进行拉动的。比如有客户付钱要买一辆车,这时产生一个购买信号,这个信号传递到汽车工厂,在汽车工厂的最下游(比如装配车间,不一定准确,这里只是做个简单介绍)就产生一个装配一辆车(是非常具体的什么型号,什么颜色等)的信号。这个信号继续向上游传递(比如车体框架、引擎、轮胎等不同车间或供应商)后,会陆续带动上游的生产。拉动式生产可以保持较小的库存(积压),另外每个环节由最终的结果(客户购买)来驱动,很容易达成一致。而如果是推动式生产呢?每个环节只关心我的任务是否完成或达标,而不是根据生产信号来生产。这样势必会造成更多的浪费(库存)。

那么对于软件开发,这种拉动式生产是否可以应用呢?很显然是可以的。那么如何应用实施呢。让我们看看如何进行产品梳理。

###产品梳理 前期准备好之后,就需要和产品经理(或产品负责人)以及团队一起来梳理当前的产品需求。梳理产品需求我最常用的工具有用户故事地图(还有其他工具,比如影响地图、客户体验地图等,限于篇幅这里就不一一描述,有兴趣的小伙伴可以自行查找)。这里着重描述一下用户故事地图。

####什么是用户故事地图

用户故事地图是一门在需求拆分过程中保持全景图的技术。 – Martin Fowler

用户故事地图可以使我们专注于用户和用户体验,产生更好的沟通效果,最终做出更好的产品。 – Jeff Patton

用户故事地图是以用户的视角来讲故事,然后团队整体达成统一的理解。–BoB Jiang

@todo a photo

####为什么用户故事地图有效 用户故事地图在产品梳理(需求梳理)方面为什么很有效,这有如下几个原因:

####如何使用用户故事地图 这里有一个简单的步骤介绍:

  1. 团队每个人用便签写下自己对于产品的理解,如需要完成哪些任务。这个环节不需要讨论,每个人自己写。
  2. 每人把自己的便签按照完成任务的顺序贴在一面大墙,或者地板上。
  3. 所有人的任务,整合到一起。相同或类似的分成一组活动,并给该组活动起名。
  4. 找出最简版本需要完成的任务

注意:如果步骤1、2中大家写出不同用户的任务,可以根据用户做成不同的地图。比如对于一个电子商务网站,可能的用户有最终消费者,运营人员,系统管理员等。

最后推荐大家阅读《用户故事地图》,以及参考如下两篇博文:

到这里,我们已经为团队准备好了要工作的内容。接下来就是如何交付。

###Scrum 我们采用的敏捷转型是完全遵循Scrum框架的。具体Scrum框架的内容可以参考Scrum指南。由于业务方需求和客户的需求变化非常快,我们选择一周为迭代周期。具体的活动包含:

####计划会 计划会主要分为两部分:做什么和如何做。 团队一起决定他们要做什么,以及如何构建、测试承诺的工作。在计划会议过程中,产品负责人的重要职责之一是解释澄清模糊的需求。最后的产出为迭代目标和迭代列表。

####每日站会 每天的 15 分钟站立会议。 团队一起回答三个问题:

  1. 从上一次例会到现在我完成了什么(重点在于是否完成承诺,以及暴露风险)?
  2. 从现在到下一次例会我计划完成什么(重点在于承诺)?
  3. 有什么风险或障碍(尽早暴露问题风险)?

####评审会 在评审会上,产品负责人接受或拒绝团队完成的用户故事。(注:产品负责人应该在平时的工作中进行评审,而不只在评审会上进行这些工作)。

####回顾会 团队一起检视和调整他们的工作方法,以达到成熟高效的自组织团队。

上述的活动看起来简单,但在实践过程中会出现各种意外的情况。这里就需要有经验的人帮忙进行辅导。有关每个会议更详细的内容,可以参考Scrum指南

##坑 这里给大家一些警示,也是在这次敏捷转型当中踩过的一些坑。

###不以客户价值为核心的敏捷转型都是耍流氓 前面那个案例,到后来并没有带来很多客户价值的提升。最多的结果是研发内部的透明,以及与业务方沟通的顺畅。但最终供应商入驻,仍然是那么长时间。所以后面并没有过多描述案例,而我希望大家能够引以为戒,在进行敏捷转型的时候,一定要看着客户价值。不能给客户带来价值的敏捷转型都是耍流氓。

回归到案例中,客户价值可能体现在:

##敏捷转型的核心 回顾前面讲述的内容,真正重要的就如下几点:

##注意 最后,一定是最重要的!

Scrum不是万能的!
Scrum不是万能的!
Scrum不是万能的!

而Scrum只是暴露问题。暴露问题之后需要团队一起努力奋斗去解决问题。
本文很多的做法和Scrum没有太大关系,而是就暴露出的问题采取具体措施。