京东敏捷团队看板与潜在交付物实践

编者按：

      王梓晨，2012年加入京东，在运营研发部担任架构师一职，匠艺全栈工程师。曾负责京东智能分单团队，主导了京东智能分单系统的架构工作，4个月内提升服务性能数十倍。还研发了地址配送网点分类模型，基于机器学习算法，实现了配送到路区的精准化分单，大幅提升了分单准确率，节省人工成本。热衷于敏捷开发，目前专注于自然语言处理、高并发架构设计、搜索技术。

       互联网思维被定义为“专注”、“极致”、“口碑”、“快”，这四项看似互斥的四个特性却恰恰被融合在了一起，我们通常所说的敏捷团队，是如何做到的呢？

      2017年3月1日，王梓晨在中生代技术群做了《京东敏捷团队看板和潜在交付物实践》的主题分享。本次分享来自京东一线团队的实践总结，该团队曾获得京东集团优秀项目与top100最佳案例等奖项，专注于互联网电商的服务高可用与自然语言处理。该团队早期便采用全敏捷方式的项目管理，而敏捷团队有效精准的识别sprint task中的潜在交付物（PSP）势必事半功倍，本次分享渗透敏捷迭代的细枝末节来详述京东的敏捷看板实践。

       如果你错过了分享直播，或者你参加了分享，还想回顾总结，本篇便是分享内容的干货总结。

      大家好，我是京东运营研发部架构师王梓晨。“青龙系统”是京东分拣配送系统的代号，既京东高效物流体验的支撑系统。而青龙智能分单系统是该环节的“大脑”，负责规划配送的全路径。即从您在京东网站下单后，货品出库到分拣中心运输到哪个配送站，以及由哪个配送员最终送达到您的手中，这些规划工作都是由智能分单系统来计算完成的。

       你是否曾有这样的疑问，系统业务流程繁杂、战略项目层出不穷、与日俱增的访问量与背后技术体系需要不断优化……今天我们就来分享京东一线作战连队，运营研发-青龙研发部，是如何运用敏捷精益化的管理方法，实现了产品的快速交付。

        传统的瀑布模式之所以被诟病，其核心是交付周期长，上线效果弱，用户差评高。而所有问题的根源，就在于无法实现产品的快速，持续交付和快速反馈。我们今天要看到的是敏捷精益管理中的看板部分，就像这样，一个普通的任务在看板里，被拆成了N个状态。把所有的项目和产品拆分为一个一个落地的产品需求，然后根据这些需求进行迭代跟进，一个迭代往往由两周构成。

       这是我们早期的看板，现在已经完全线上化了。这个不重要，且来看这看板的构成。从业务需求转化为可以落地开发的任务，再到可以交付使用的产品，都要一丝不苟地经历这样的成长与蜕变：

从需求到产品，往往经历这四个阶段：

IDEA => AGAIN => BACKLOG => NEXT
a) 倘若霎时间萌生一个想法：“我们要把挪威冰鲜三文鱼送到千家万户”，那么千万不要错过，随时记录下来，别遗忘、别丢弃，放在IDEA列里。
b) 当IDEA逐渐孵化，开始滋生萌芽时，我们再次细化，“是否热带水果也可以送？是否查干湖冻鱼也可以？…不仅仅京东自营平台要支持，物流开放平台也要支持…”，需求得以再次升华，体现在AGAIN一栏里。
c) 怎么结合现有的配送模式使得效益最大化，怎么全方位支持，网站下单后，经过订单流转的各个系统，如何有效的识别与控制……，这些问题逐一解决后，业务的一个想法便形成了初步的需求，有板有眼，列入Backlog栏里。
d) 当Backlog逐渐成熟，可以进入迭代中时，则正是挪入Next栏中。Next中的需求一般以用户故事的形式来体现，“作为….我想要…以便于达成….的目的”这样格式化的用户故事并不是形式主义，而是强迫我们去思考需求背后的目的，促使对需求本身的深度挖掘。
e) 再辅以Acceptance，以及Deadline。在主要方向的验证点和交付日期明确后，我们就可以正式进入开发了。

开发阶段也被拆分为“TODO-DOING-DONE”三个阶段。

a) TODO阶段，我们要对进入迭代内的任务，即Next栏中的每项内容进行拆分。架构设计、数据库建模设计、交互设计，统统体现在这里。根据细致的讨论，我们把需求任务拆分为一个一个可以安心开发的子任务。每个子任务的周期建议为1-2天，这样，风险就可以被我们控制在2天以内。
b) DOING阶段中，把TODO阶段拆分细化后的战利品拖动过来，进行开发。开发中有任何问题由开发人员主动召集大家讨论，若存在较大的风险或者需求有变化则及时变更航道，把影响控制在最小的范围内。
c) DOING完成后，就可以进入DONE阶段了。我们的每一个需求点都被拆解为落地的任务，并细化到天，每天晨会拖动看板的满足感和成就感是不言而喻的。任务拖入DONE就代表着已经开发完成，junit自测完成，可以交付测试了。

测试阶段，同样也细分为“TODO-DOING-DONE”三个阶段。

a)      TODO阶段，对任务需求的用例进行评估，并整理出测试用例。需要性能测试的部分，也在这个阶段尽可能的体现出，以便在以后的测试阶段可以考虑的周全。
b)     从每一个子任务的测试DOING到DONE，标志着该User Story测试通过，可以进入上线的准备了。

最后还要介绍DEPLOY、PENDING、WASTE三个阶段，这三个阶段分别代表着上线完成，挂起，垃圾站三种状态。

a) 由于外部资源的以来或者其他外部资源的介入而引起的搁置，故而PENDING必不可少，经过产品的推敲，和架构的升级，PENDING的任务可以重回DEVELOP或者TEST，同时也能从另外一个维度来审视任务制定的合理性。
b) 任务若被丢弃，则列入到WASTE一栏中。若是由于法务、合同等因素引起的，在情理之中；若是由于业务分析不够透彻，接口性能设计不合理，那么在Sprint Retrospective时就要被列入需要重点Review的对象了，当然，小伙伴们一起决策。

综上所述，可以纵向的审视看板。分为产品看板、研发、测试、上线以及其他五个部分组成。在敏捷重要的会议里，计划会往往是对backlog精雕细琢，并准备放入本sprint里大干一场的。而回顾会恰恰是对Deploy里的user story做整体点评，总结与反思。对于还停留在develop & test栏里的内容，更要分析原因以改进。展示会则不仅限于deploy，test done 甚至develop done亦可以展示，短期的展示更有利于需求及时响应变化。每日站立会则是关注于user story自身的状态、checklist、deadline等细节。

本次分享本来重点是在看板，但是关于每日晨站立会我想多说一些，我发现很多团队把平日该有的沟通都留到站立会做，致使站立会时间变得很长，其他成员难免会出现走神，看手机之类，就对站会氛围有损了。站立会本来只是说昨日做了什么，遇到什么问题需要谁来协助，今日需要做什么就可以了。8个人左右的团队以15分钟为限站会会比较有效果。而平时工作中遇到的问题，需要其他部门协调的，需要业务确认的，或者依赖中间件的…尽量尽快主动的协调。站会只是站会，不包含评审会、回顾会的职责。

那么，敏捷看板中的潜在交付物有哪些呢？

首先，如何衡量一个user story是否优质。
对于user story评价的时间节点在进入迭代开发之后。User story的拆分原则一般定义为半个迭代内可以上线完成的工作量。若涉及到多位成员的，最好可以再次细分为一位成员一个卡片。User story的名称需要一目了然，最好设计为项目名称-需求名称这样极易一眼识别的话术。当然其描述也至关重要，引起歧义或者对需求的思考不到位是最可怕的，故而描述也一定要按照As a <Role>, I want to <Activity>, so that <Business Value>的格式来书写。除此之外还需要定义checklist作为user story的补充，checklist按照阶段可以分为三类，产品业务的验证点，开发的开发点，测试的用例点，每个环节都需要在进入各自状态前制定完成。有了描述，有了完成列表，那么deadline自然是必不可少的，作为一种承诺。另外User story还需要一些Tags，可以包含“需要功能测试”、“需要代码review”、“需要性能测试”、“依赖外部系统”等提醒功能的标签。最后还可以基于任务本身的性质不同而制定不同的背景色，如按照业务需求、技术改进、bug类、业务优化类、紧急需求等来分类，一个迭代中最好适当包含一些技术提升的任务，和业务任务搭配起来使得团队氛围不那么单一。

从产品的idea到develop todo之间，可交付物大致分为事前分析、详细设计与运营反馈三部分。
事前分析主要包括需求的市场调研、ROI分析报告、BRD等。
详细设计包含业务流程图、产品设计PRD、系统技术概要设计等。很重要的一点是产品同学需要和主要研发同学沟通业务背景及业务细节，而不断迭代地完善产品的详细设计。 因为文档永远只能是思考和记录，绝对不能用来代替沟通。如若这些不到位，到develop或者test乃至deploy阶段之后才暴露出问题，付出的代价便随着迭代的周期而指数级增长。
运营反馈为需求上线以后，如何建立良好的运营报告分析，与业务期望的反馈，通常通过报表+监控的方式来体现。

Develop todo，这个环节绝非是可有可无的。因为user story的开发设计序列图，数据建模，架构设计图都要在这个环节完成，上手就写代码，然后再返工，相信痛过的人都知道。Develop doing至develop done之间，junit、接口设计文档、涉及的数据字典的wiki维护都是必不可少的交付物。Develop done至test todo之间，测试人员需要主导对照user story中checklist里逐一业务点核对junit是否覆盖完全。开发同学需要确认测试环境是否完备，如数据库表是否建立、索引是否完善、jar是否上传私服、rpc接口是否注册、网络权限、白名单、redis初始化数据是否正常、maven是否正常编译打包运行。脱离了这些环节，只是测试同学从git上download下来，编译打包出来的代码对于功能测试而言没有任何价值。

Test todo需要整理测试用例文档，需要用线上的包冒烟一次。同时在test done之前需要针对checklist中逐条内容进行核验，且能合理定义出边界测试场景，还要对接口幂等性、异常输入进行测试。

Test done后，是最容易出问题的时候，因为经过开发、反复测试，认为没有什么问题可以上线了，故而最容易疏漏。Depoly之前，一定要merge 代码后进行线上包的回归测试，且逐一梳理数据库是否完备、是否存在数据库白名单、rpc服务是否已经注册、redis主备是否到位、有没有跨机房的容灾、es是否读写分离、cassandra是否已经配置监控、回退方案是否可执行、有无业务影响、重要依赖外部系统是否有降级方案……天下大事必做于细，天下难事必做于易，严谨的思维是看板的基本素质。

Deploy时，对于web系统而言，除了系统日志，还要看catalina日志，以及cpu load 、mem、jvm、io、swap、线程进程、网络指标（流入流出、接收丢弃ip包数量、tcp等详细指标）、磁盘指标等情况。若是docker还要观察宿主机的运营情况，有没有异常的资源争用。当然，这些都应该有一套成熟的监控系统自动报警并做到可视化。确保程序发布成功后，仍然需要观察业务正常运行稳定一段时间。且需要有良好的运营监控反馈机制，可以方便的分析线上运营情况而不断的优化业务，系统产品都是在演进中逐渐完善的，这个阶段不可忽视。

看板是限制在制品的产物，是少即是多的最好诠释。“快”和“准”需要结合良好试错机制在有限的时间内最大限度的完美我们的产品。通过缩短交付的周期，持续进行交付，不断收获的喜悦，堆积，而在每个很小的跌代里不断发起冲刺，团队里的每个兄弟都关心所负责任务从IDEA萌芽到上线完成，到运营及用户的反馈，以及后续优化与改进，如老曹@曹洪伟 所描述的全栈工程师，真正成为产品的主人。