京东敏捷软件开发精髓
大家好，我是今天的分享老师：姜信宝，Bob Jiang。我来自京东商城-技术研发管理部，是京东的敏捷教练。
很高兴受到“京技院“的邀请，能有机会与大家分享关于京东的敏捷软件开发商的一些心得体会，希望分享的内容能给大家带来一些收获。这次准备的时间有些仓促，同时我也是第一次通过微信的形式做这种交流，有不足的地方还希望大家能够理解。：)
今天我的分享话题会分为两大部分：
1.案例分享 2.敏捷软件开发的精髓
下面我们来看一下第一个案例，京麦团队。相信如果关注京东敏捷开发的朋友，对于这个团队并不陌生。京麦团队是京东的第一个敏捷团队。到目前为止该团队没有一个员工离职，这在互联网行业可以说是一个奇迹了。
案例1：京麦
2012年底，有一个屌丝团队，他们做的产品慢慢被边缘化，客户不满意现有产品，技术负债高，并且团队马上要被解散去做其他产品了。这个场景听起来熟悉吗？
很幸运的是，团队leader旁听了一次敏捷的工作坊，知道敏捷应该怎么玩，也知道了和其他团队之间的差距在哪里。因此京麦团队决定试一试，用敏捷开发的方式进行软件开发，有了想法马上行动。
第一步，组织团队进行敏捷培训，全员知道什么是正确的敏捷软件开发。这是敏捷软件开发的第一步，也是至关重要的一步。
第二步，团队坐在一起，这里团队指的是产品、研发、测试整个团队，而不仅仅是研发。团队坐在一起的好处有很多，比如有了问题，直接喊“张三这个问题我们一起看一下？” 又或者产品和研发正在讨论某个具体的需求，测试人员听到后立刻加入进来，信息快速共享并达成一致。
另外，团队坐在一起还有其他的好处，团队的每日站会更加容易同时一起开，代码评审也会随时随地的发生，任务板上的任务团队更容易更新。简言之，团队坐在一起更容易促成团队之间的沟通，以及信息共享。
第三步，按照Scrum框架的定义，严格地开展每一个会议，如迭代计划会、每日站会、迭代评审会、迭代回顾会以及产品列表梳理会。每一个会议都不能省略。
第四步，Scrum会议坚持开的情况下，团队可以尝试引入已经被证明有效的良好工程实践。如持续集成、结对编程、测试驱动开发等。
在坚持以上四步之后，京麦团队达到了如下的成果： 1.交付周期从之前的12周，降到现在的2周 2.同时在线的用户数提升了3倍 3.活跃用户数提升了5倍
京麦团队到现在敏捷转型接近三年，团队也已经拆分成4个小团队，整个团队还是在坚持着使用Scrum的方式，每两周一个迭代，持续交付价值，持续改进。下面是他们团队任务板的一个持续改进图，供大家参考。
这是他们第一版的任务板
第二版
第三版
最后在京麦团队的带动下，整个POP团队都已经开始了敏捷转型之旅，非常感谢京麦团队不懈的坚持。以上是第一个案例的分享。
案例2：物流开放平台
介绍这个案例之前，我想先说一下团队的收获。这个团队在人员数量不变的前提下，2015年上半年就完成了2014年一年的任务量，即团队效率至少提升了1倍。想知道这个团队是如何做到的吗？我们一起来看看这个团队的例子。
首先这个团队经理是很开放的一个人，喜欢新鲜事物，喜欢尝试。这是非常好的开端。 第一步，仓储团队的总监找到我们，商量进行大团队的敏捷转型。这里多说一下，为什么这个团队的总监会找到我们。前期我们（敏捷教练）在POP京麦团队的成功试点，很多团队也都听说了敏捷可以成功的，因此越来越多的团队也想进行敏捷转型。也就是说通过早期成功的样板团队，树立了榜样，也为后期的敏捷转型铺好了路。
第二步，敏捷导入，即进行普及性的培训。上面提到的团队经理和他手下的几个leader都来参加了ScrumMaster敏捷训练营的培训。
（这是团队经理听完培训之后的反馈：“在京东第一次接触敏捷研发管理的思想，是在今年春节前一次公司组织的敏捷培训课程上，听了敏捷教练BOB的授课，感觉这种管理模式既可以改善现有研发工作中的一些问题，又能给团队带来很多新鲜事物，真是我们迫切需要的。于是，在部门领导的倡导下，我们几个三级部门开始了各自团队的敏捷之旅。”）
第三步，团队开始按照Scrum进行敏捷软件开发，并且持续改进。大多数团队一开始都会选择两周作为一个迭代周期，因为两周是一个很好的开始点。
制定了团队规则之后，就要执行。比如“最初开站会的时候，大家都不是很积极，到了规定的时间，很多人还在忙自己的事情，不叫不来。后来敏捷团队制订了奖惩机制，每天不按时参加站会又不提前请假的，都要扣20块钱作为水果基金。这下大家的积极性提高了，每天参加站会的人也比较齐全了。有一次一个同事因为处理问题，晚来了2分钟，本来是有情可原的，但为了兑现承诺，他主动买了5盒草莓分给大家。”。
另外，回顾会议是非常关键的。“在敏捷回顾会上，大家都要总结上个迭代周期里工作情况，包括做得好的地方和需要总结提高的地方。会议由Scrum Master主持，每个人会拿到不同颜色的便签纸，蓝色的便签纸上写做的好的实例和总结，红色的便签纸上写的是待提高的事例和建议。在写完总结后，大家会按顺序轮流发言，提出自己的意见和建议，最终汇总到Scrum Master处。每次回顾会，都会让大家获得很多的经验和宝贵的意见，从而提升整个敏捷团队的工作质量。”
在部门领导和公司管理层的支持下，我们敏捷团队鸟枪换炮，从以前传统的墙面看板，上升为触摸电视屏幕的电子看板。怀着激动和感激的心情，我们几个小伙伴瞬时间将高大上的触摸电视和支架组装完毕。
在团队敏捷转型的一开始，为了让大家对Scrum有更全面的了解，团队还自发组织了读书行动。每天固定时间固定地点，团队花30分钟共同阅读同一本书，并且大家会就这一个主题进行讨论。
可视化的读书结果
以上就是第二个案例分享，物流开放平台。
案例3 - 京东途牛融合项目
5月8日京东和途牛联合宣布，双方展开深入战略合作。6月下旬，我作为敏捷教练进驻途牛团队，帮助途牛项目一期进行敏捷软件开发的辅导。
针对全新项目的转型，有以下几点需要注意。 第一，需要先梳理出第一版的产品列表（Product Backlog）。一开始我就和途牛团队的8位产品经理进行产品需求的梳理，并且使用用户故事地图进行了产品需求的大概规划。
第二，团队坐在一起。产品研发和测试全部坐在一起。由于这个项目的特殊性，需要和途牛进行频繁的接口测试和联调，途牛团队也安排坐在一起了。
第三，形成Scrum of Scrums（SoS）会议。这个项目有四个团队，跟团游、门票、平台、途牛方。每个团队都有自己的每日站会，固定每天下班前每个团队代表和产品经理一起开SoS会议，同步团队开发中遇到的问题、障碍和风险。
第四，团队坚持Scrum的会议。并不断改进产品和团队一起的工作方法。
以上就是京东途牛融合项目的案例分享。3个案例已经全部分享完了。
-———————————————————————————————————
下面重点来了，当当当当！来说一下京东的敏捷软件开发的精髓。这就是一个核心，四个基本点。
一个核心：价值驱动 四个基本点：透明、迭代、持续改进、教练
价值驱动
不以价值驱动为导向的敏捷转型就是耍流氓。我见过很多团队要进行敏捷转型，而如果你要问他们为什么要敏捷，则答案是五花八门。老板的要求，听说敏捷能让我们效率提升，质量提高。也有很多负面的声音，敏捷不适合我们团队，我们公司文化和敏捷不匹配，敏捷就是加班，等等。这些都没有回答到点子上。
而敏捷软件开发的精髓就是尽早频繁的交付商业价值（感谢Alistair Cockburn博士）。任何不以价值驱动的敏捷软件开发都是伪敏捷。那说了这么多价值驱动，以价值为核心，具体到实践层面要怎么做呢？
这里我给大家介绍一个非常非常有用而且简单的工具—产品列表（Product Backlog）。团队敏捷转型，在接受了普及培训之后，第一个要做的事情就是建立一个且是唯一的产品列表。为什么要这么做？最重要的原因就是需求统一入口。
一个产品只有一个产品列表。并且产品列表要符合DEEP原则，即Detailed Appropriately, Emergent, Estimated, Prioritized.
介绍一下DEEP原则，对应的中文分别是：
1.详略得当的。也就是说产品列表中的需求条目是有粗粒度的，也有细粒度的，不是完全一样的。马上要做的需求，一定属于细粒度的；而1个月后要做的可能就是粗粒度的。
2.涌现的。产品列表中的需求是涌现出来的。可能在产品开发过程中，用户或开发人员有一个很好的想法或点子，那么我们就把它加到产品列表中去。
3.估算过的。每一个需求条目需要是做过估算的。只有做过估算，我们才知道它的规模大小，再结合已知需求的价值大小，我们就能判断出这个需求的投入产出比。
4.排序的。每个需求条目都有一个唯一的顺序。
-———————————————————————————————————
下面谈一下四个基本点： A.透明 B.迭代 C.持续改进 D.教练
透明
先说一下第一个基本点，透明。
敏捷软件开发当中最重要的基本点就是，透明。回想一下上面的案例中，团队转型一定要尽量让团队坐在一起。这是保证透明的基础。团队坐在一起之后，团队间的沟通会比原来顺畅很多，信息也就很容易的暴露出来，即团队信息状态的透明。
还有，敏捷转型中的另一个很重要的基础设施是任务板。对于一开始实施敏捷转型的团队，我强烈建议使用物理的任务板。
这会有非常多的好处。
- 团队信息以及团队进展的公开。
- 每个人每天都需要更新自己的任务，受到同僚压力，团队中滥竽充数的人几乎不存在。
- 任务板可以任意的进行重新规划和设计。（相比电子任务板）。
迭代
第二个基本点是迭代。
有些人在说敏捷是什么的时候就说，敏捷就是快速迭代。这个说法有点过于片面，不过也说明了迭代是敏捷当中很重要的一个基本点。
两周一个迭代周期，并且迭代结束的时候一定要交付出潜在可交付的产品增量。
这样有什么好处呢？
- 两周固定的迭代周期，省去预定会议的行政事务，团队可以形成习惯。
- 两周就会有交付物，相比原来两个月甚至一年才有一次交付物，这是一个极大的提高。对于软件开发来说，用户能看到（或者使用）产品才是最关键的。
因为只有用户看到（或使用）产品，他才可以给出真实的反馈。团队才能基于用户的反馈做出调整，做出用户真正想要的产品。
而且只有两周真正交付出潜在的可发布的产品增量，才算是完成了有价值的工作，也是敏捷的一个核心的体现。
持续改进
第三个基本点是持续改进。
一提到持续改进我就想起一位日本友人的介绍。持续改进在日语中是Kaizen。他跟我们提到1次改进不是Kaizen，10次改进也不是Kaizen，100次改进也不是Kaizen，只有做到1000次改进才能算是真正的Kaizen，即持续改进。为什么一定是1000次呢，友人说到只有做到了1000次改进才能养成改进的习惯，才能算作持续改进。
在Scrum中有三个会议可以给团队提供持续改进的机会。
- 每日站会。每天团队在一起，同步团队整体的进展情况，相互鼓励并改进。
- 迭代评审会。团队和产品负责人一起回顾一下迭代内的产品增量，以及利益干系人都有哪些反馈。这是一个非常好的改进产品的机会。
- 迭代回顾会。团队在一起反思，作为一个团队我们哪里做的好，哪里可以做的更好，哪些是我们想要尝试的。
回顾会是一个团队工作流程改进的机会。
教练
第四个基本点是教练。
在我的ScrumMaster敏捷训练营培训课上，我会介绍Scrum的三条腿的基础，即透明、检视和调整。在写完第一个基础透明之后，我会问参与者下一个基础是什么。很多次大家会回答，敏捷教练。虽然Scrum的基础没有敏捷教练，但我还是想强调一下对于敏捷转型来说，敏捷教练是非常关键的。
敏捷教练会做哪些事情帮助团队呢？
- 培训。作为普及性的培训，让团队全员了解Scrum是如何工作的，以及团队需要如何一起工作。
- 辅导。 敏捷教练需要和团队在一起工作，指导他们的Scrum会议。
- 挑战。 作为敏捷教练，需要不断的挑战团队现状，让团队能够紧密的一起工作。
另外，敏捷教练还可以把一些新想法、新的尝试带入到团队，并让这些新的内容生根发芽。
好了，这些就是京东敏捷软件开发的精髓。那就是一个核心，四个基本点。一个核心是价值驱动。四个基本点是透明、迭代、持续改进和教练。
重要的事情说三遍： 一个核心是价值驱动。四个基本点是透明、迭代、持续改进和教练。 一个核心是价值驱动。四个基本点是透明、迭代、持续改进和教练。 一个核心是价值驱动。四个基本点是透明、迭代、持续改进和教练。
-———————————————————————————————————
Q&A 1、老师，我想问一下怎么评价敏捷团队实施的效果好与不好？也就是说什么样的敏捷才算成功呢？
答：评价敏捷团队实施的效果好坏，要由用户说了算。只有用户满意高兴了，就是做的好。回到我们刚才讲的一个核心，四个基本点。还是要以价值驱动为核心，即做对用户有价值的事情。 什么样的敏捷是成功的。这个问题问的很好，有很多敏捷团队经常会说，啊，我们成功啦，我们做到啦。其实这个是一个错误的想法。真正的敏捷是我们一直在路上，朝着敏捷这个目标一直在努力。敏捷是一个完美目标，而不是终点。
2、backlog的细粒度把握不好，求教？
答：进行产品列表条目的拆分有一套非常好的工具和套路。可以在我的博客上查找产品列表切分。 https://bobjiang.com
3、传统企业立项时，要限定QCD，敏捷开发的立项是如何约束的呢？
未回答。
3、请问敏捷能很好的控制需求蔓延吗?
答案是肯定的。 4、万事开头难，如何开始敏捷转型？
未回答。
5、敏捷开发怎样能真正的调动团队的激情呢？
答：首先这个问题和敏捷是木有关系的哈。 我来说一点小方法。前提你至少是一个团队经理。如果你希望团队每个人都积极发言并表达想法，那么就用各种奖励、表扬的方法去鼓励大家这么做，当团队知道这样做是正确的，自然就会主动了。
6、我的疑问是敏捷实践中关于结对编程的问题。现在基本上一个研发组里两两固定结对来开发一个小项目，想知道是否需要跟其他人轮换结对？理由是什么?
答： 进行结对编程是非常好的尝试。敏捷是非常强调反馈的。传统软件开发的反馈周期是以月为单位的进行反馈，Scrum的反馈周期是以周为单位的进行反馈，而如果团队能够加上工程实践，如持续集成是是以分钟为单位进行反馈的，结对编程则是秒级的反馈。 针对你这种情况，需要具体情况具体对待。如果是两个人结对不适合或者想做新尝试，就可以考虑进行轮换。所以答案是问问结对的团队。
7、在敏捷教练的培养和人才储备方面，老师有什么指导？
答： 对于敏捷教练的培养，我有两个建议，第一选择那些有激情或者说有兴趣的人，只有有激情才能把事情做好。第二个需要这个人喜欢尝试新鲜事物。其他的都可以慢慢学习。最后说一句非常实在的，也是我一个好朋友告诉我的。那就是不要培养内部教练。因为内部教练非常优秀之后，90%都会离开。
8、如何保证每两周持续交付？开发、测试、上线op 如何协调的？
答：两周是必须要交付的，包括上线。如果做不到这点往往说明了一个问题，那就是产品列表中的需求条目太大了。需要学习如何拆分需求。
9、Bob老师，敏捷和项目的辩证关系是？也就是说：什么时候该采用敏捷，什么时候该采用项目制度呢？他们是互斥的还是互补的？
答：敏捷和项目是可以并存的，在京东目前的情况下，就是敏捷和项目管理并存。不过我个人的观点是倾向于产品化而不是项目化管理。因为如果按照项目化管理，最大的一个弊端是产品管生不管养。如果是产品化，有利于产品的优化，以及长期稳定的团队。
10、如果团队是异地的虚拟团队，无法坐到一块，有什么好的办法进行敏捷？
答： 这个情况对于大公司非常常见。在这样的情况下，我的建议是， 1. 不要搞异地团队。 2. 如果真的搞异地团队，也要是一个地方一个团队，比如北京有一个团队，上海有一个团队，尽量减少团队之间的耦合和依赖。 3. 异地团队尽量是时区比较接近，比如北京一个团队，印度一个团队；千万不要北京一个团队，渥太华一个团队，这是最糟糕的选择。 4. 最最最最最糟糕的做法是北京2个人，印度2个人，旧金山2个人。 完全糟糕透顶的。如果是这样，我建议你先把团队梳理好再考虑其他的。
11、如何分配敏捷开发的合理时间？测试和开发的工作如何协调？
答：第一个问题不太明白。 我回答第二个问题。在敏捷开发中，测试和开发是共同工作的。比如迭代从计划会开始，在计划会测试就要参加。为什么要参加呢？因为从迭代一开始测试就知道这个迭代我们团队要完成哪些需求，这些需求是如何开发的（细节）。这样有利于测试编写测试用例，准备测试数据等。计划会之后，开发开始写代码，测试则准备测试用例，测试数据，测试服务器等相关工作。当开发完成一个需求的时候，测试就可以立刻测试了。然后下一个需求，下一个等等。
12、没有专业敏捷教练，传统开发团队是否应该按照案例一中的模式自行探索，我理解核心就是调动团队积极性持续优化实践过程，但是在未体现敏捷优势的情况下就是增加单个团队成员的工作成本和工序，这种情况下有什么好的方法来推进？
答：对于敏捷转型，这里我会给一个建议。就是 守-破-离。守的阶段，指的是一开始我们先完全学过来，不做判断。因为敏捷已经在很多公司证明是真的有效的。在守至少6个月之后才考虑下个阶段，即破。破的阶段指的是要打开思路，不仅仅是敏捷的好东西，还有很多其他领域的好东西也要吸收进团队，比如传统开发的时候的良好实践，比如项目管理当中的好方法，慢慢都纳入到团队中。 最后一个阶段是离的阶段，离是团队自我的挑战，团队不断设定新的目标，或者做出新的尝试，持续改进。 这是我对想要进行敏捷转型团队的一个建议。
13、敏捷与cmm过程体系是否冲突？新的产品我们团队一般是一周迭代一次，会不会太快了，不好？？？
答：敏捷和CMM不冲突，在业界也见到敏捷和CMM很好融合的团队。这两者融合的一个关键点是不断找出用最少的努力可以达到CMM要求的点。在这方面我自己是没有尝试的。 一周一个迭代做的非常棒。如果团队ok的话，我强烈建议一周一个迭代。因为迭代周期越短，反馈周期越短。那么我们也会越快的响应市场变化。
14、请教问题：我现在负责整个公司的项目管理，我们多个产品线的情况下，每个月做一次产品地图。但是这时候业务方先提交需求，还没有到达产品需求可估算的程度。我们怎么做产品地图？
答：需要进一步澄清，产品地图指的是什么？没有到达产品需求可估算的程度指的是什么？
15、对于技术实力整体偏低的团队中，敏捷开发是否合适？
答：适合的。敏捷的精髓除了一个核心和四个基本点之外，能解决的最大的问题就是让团队暴露风险。如果团队技术实力偏低，那么很可能在1，2个迭代之后你就知道这个团队不靠谱，无法 完成这个产品，或者产品的规划。那么就需要果断做出调整。
16、故事任务和开发中的任务是不一样的吧，如何从故事任务，转换为开发任务？
答：先澄清一个概念。这里故事任务，我猜指的是需求条目（如果我猜错了麻烦更正我一下）。那么需求条目和开发任务是完全不同的两个概念。需求条目对应的可能是一个功能，也可能是一个缺陷。把需求条目转换成开发任务，是团队一起在迭代计划会完成的。并且团队在日常工作中，也可以根据需要针对开发任务进行增删改。
17、敏捷和维护文档的完整性有没有关系？
18、在需求拆分合理的前提下，那么这些需求对应的prd需要详细到什么程度？或者是否有其他方式更合理输出prd
未回答。
19、敏捷开发中，文档重要吗？至少要有哪些文档？坐在一起大家更愿意面对面交流，都不愿意写文档了，如何应对？
答：首先文档是非常重要的。敏捷宣言当中提到“工作的软件 高于 详尽的文档”。大家一定不要被这句话所迷惑或者带到沟里去。这里首先承认了文档的重要性，其次说工作的软件比文档更重要。所以说呢，文档是必须写的。在我培训中，我必须肯定一定要强调的一点就是，敏捷不是不写文档，而是写有价值的文档。如何判断是否有价值，就要问几个问题。这个文档对用户有价值吗？这个文档对团队有价值吗？这个文档对利益干系人有价值吗？ 如果都没有价值，那么这样的文档就不要写了。另外针对传统软件开发，是以文档驱动的（或者说里程碑驱动），是用文档进行需求的传递。这样的文档可以仔细反复推敲其价值。
20、在一个迭代中，往往在过程中会出现其它的问题或需求（如临时需求，紧急或不得不处理的）处理，那必然会对迭代计划或周期造成影响，如何避免这种情况呢？
答： 针对这类问题，有几种解决方法可以供你参考，我带过的团队都有用过。 1. 设置一个值日生（可以是一天一换，或一周一换，如果你不想这个人离职的话就一定考虑轮换哈），在这一天或一周就是这个人处理所有的紧急情况。如果她不会，可以在合适的时间去寻求团队的帮助。 2. 设定上限。针对紧急处理的问题，设定一个上限，比如2.超过2个，那么就看看之前的2个是否都重要，保证不超过设置的上限。超过后需要排队等。 3. 设置固定时间处理。比如每天下午4-6点是集中解决问题的时刻，或者每周二和每周四是集中解决问题的时刻。 以上三种方法供你参考哈。
21、对于产品上线后，需求文档，设计文档和测试用例等组织过程资产是如何维护和管理的？如果新员工加入，这些文档是否可以帮助他快速了解产品及相关设计？对于测试用例，是否能够复用并执行快速回归测试？
未回答。
24、一、项目人员，不能做到100%投入，临时项目外任务会被打断，而且临时任务即紧急又重要而且其他人不可替代怎么办？二、与公司原有工作流程不兼容，项目内成员不配合怎么办？三、需求定义不够详细清楚，工作量预估不准确或者根本估不出来，任务做完了才给估期，要怎么才能解决？
未回答。
