大家好，我是京东运营研发部架构师王梓晨。“青龙系统”是京东分拣配送系统的代号，既京东高效物流体验的支撑系统。而青龙智能分单系统是该环节的“大脑”，负责规划配送的全路径。即从您在京东网站下单后，货品出库到分拣中心运输到哪个配送站，以及由哪个配送员最终送达到您的手中，这些规划工作都是由智能分单系统来计算完成的。
你是否曾有这样的疑问，系统业务流程繁杂、战略项目层出不穷、与日俱增的访问量与背后技术体系需要不断优化……今天我们就来分享京东一线作战连队，运营研发-青龙研发部，是如何运用敏捷精益化的管理方法，实现了产品的快速交付。
传统的瀑布模式之所以被诟病，其核心是交付周期长，上线效果弱，用户差评高。而所有问题的根源，就在于无法实现产品的快速，持续交付和快速反馈。我们今天要看到的是敏捷精益管理中的看板部分，就像这样，一个普通的任务在看板里，被拆成了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萌芽到上线完成，到运营及用户的反馈，以及后续优化与改进，如老曹@曹洪伟 所描述的全栈工程师，真正成为产品的主人。
精彩问答
“开发同学需要确认测试环境是否完备，如数据库表是否建立、索引是否完善、jar是否上传私服、rpc接口是否注册、网络权限、白名单、redis初始化数据是否正常、maven是否正常编译打包运行。脱离了这些环节，只是测试同学从git上download下来，编译打包出来的代码对于功能测试而言没有任何价值。” 这个后一句，能具体说说么？是完全没有价值么，还是功能测试覆盖不全
这个问题是这样，如果没有做过前面的检查，直接maven打包就部署，很有可能冒烟测试都无法通过。所以前面那些索引是否建立、网络权限、db白名单等是先决条件。主要是说提测的代码不是代码写完提交就可以的，还得准备好所有依赖。
传统的瀑布模式的优势在于，可以在需求分析阶段，做好减法。而敏捷过程的弊病在于，由于当前的上下文是局部的，很容易一叶障目，不见泰山。这个观点您怎么看？
首先敏捷是为了缩短交付时间，所以把很大的任务拆分成了许多小的任务来进行迭代。但是每个进入sprint的小任务一定不可以是脱离项目的，所以在写用户故事时需要按照我文中提到的 As a <Role>, I want to <Activity>, so that <Business Value>的格式来书写，也是为了迫使思考任务背后的业务目的，真正的业务诉求。当任务从idea进入sprint时，则其潜在交付物： 事前分析、详细设计与运营反馈 应该完备了。
看板方法有那些不足呢？
越成熟的团队，敏捷度越高的团队，使用看板是一大利器。这个团队已经敏捷转型好几年了，这些经验都是摸爬滚打中磨练出来的。而对于非成熟的团队，如果直接照搬，较难快速上手。且成熟的团队如果有一定比例的新成员加入，会在一定程度上影响团队的整体节奏和迭代方式，从而影响sprint的达成。
比如我在产品增值服务的设计上，就遇到一个很棘手的问题。作为单个增值服务的价格，用户心理，用户体验都可能会衍生出一大堆东西，而老板只关心如何能实现利益的最大化，而这个模型，我们发现很难建立。针对这个问题，有什么建议吗？
老板关心的目标的达成与最佳实践，这与增值服务的价格、用户心理、用户体验其实是不冲突的，这些方面也是为了利益最大化来服务的。关键点在于明确限制条件，比如实践，比如资金，比如人员投入，外部专家等。明确了这些之后，再根据老板的愿景而做规划，设置合理的里程碑。要注意市场的反馈，切勿一开始无限制的追求细节，要及时用市场来检验。
多个增值服务间，可能是相互制约的，如何实现利益的最大化，这个问题该怎么思考，这个问题敏捷方法可以解决吗？
如果这些增值服务都是同属于一个项目的，那么需要找到他们之间的平衡点，总有共同之处的，且需要从共同的愿景角度来思考，如果一个服务严重依赖于另外一个服务，那么一定要做好sla，要做好风险应对方案。
研发同学保障质量有那些措施，和习惯养成?
首先，团队需要制定较为合理的上线流程checklist，研发同学必须遵守。再有就是通过培训分享来提升技术水平和做事习惯。大公司和小公司的区别就在于大公司有很好的一套实践规范，严格执行就不会太差。最后，引用右导的说法，池塘荷花先后开，总有先开的，让先开的去影响后开的。
“Deploy时……”研发人员需要有对底层很深入的理解么，比如详细了解cpu,load,mem,jvm,io,这个troubleshooting的能力可能是需要有一定经验才能积累下来的，尤其是刚做时间不长的研发可能没有这方便的敏锐度，怎么提高人员的能力呢，是研发去做还是运维去做呢？小公司可能没有这么完备系统，有什么建议么，是自己研发呢，还是从外面采购呢？
系统不够完备没有关系，我提到的指标也是根据实际系统而有所差异的，但是监控不得不做，大公司可以有一套完备的主动报警与监测平台，那么小公司写几个shell来检测top的结果也是可以的，目的都是一样。在于管理者需要制定一套完整的方案，比如制定上线一定要看cpu利用率，一定要看jvm，怎么去做其实还是比较容易形成最佳实践文档的。一般都是开发同学协同运维同学一起来验证的，自动化运维做的好不好，也是看运维人员的开发水平，现在我部门的运维同学都在参与开发:)
来源：中生代技术