一、背景
敏捷，很多时候都推崇一个“小”字。做产品，小批量发布；做改进，小步快走，持续改善。演进式思维根植在敏捷的核心价值观里。用演进的方式做改进，用荀子的话说叫不积跬步无以致千里，用精益的语言叫kaizen，用某企业家的话说，就叫先订他一个小目标。
C 项目是一个二十多人规模的重点项目，业务目标是针对平安以外的客户打造云平台服务产品。产品在先期开发中，遇到了一些困难。受人员流失影响，团队成员绝大多数都是对产品不熟悉的新人，存在技能和经验瓶颈，同时业务需求众多，变化频繁。
在这种情景下，项目原有的基于瀑布模型的开发模式，已经不能够适应变化的需要。项目在前期的开发中，接连两次未能成功发布，缺陷率很高，业务和研发团队之间的互信也受到了一定的损害。
（原开发模式示意图）
二、小目标
在这个时候，研发和业务的领导一致把目光转向了敏捷改进，研发管理部正是在这个背景下，开始和项目展开了合作。
乍看上去，项目需改进的地方不少，如需求大批量移交，没有优先级划分；质量过程后置，缺陷始终难以收敛；业务和研发团队间工作不透明，互信较低；开发周期长，反馈慢等等，颇有一些老虎咬刺猬无从下口的感觉。
根据演进式改进的原则，项目团队经过充分的讨论和沟通，为当前开发的1.0.2版本制定了两个小目标：建立小批量快速交付节奏；建立阶段间流转的基本质量准则。这两个目标，直指当前项目核心的问题所在，同时看得见摸得着，通过努力，实现的现实性非常高。
1. 小批量快速交付
之前版本采用的是典型的瀑布开发方式，批量需求，批量开发，批量测试。整个过程缺乏透明性，也缺乏快速获取反馈的有效手段。因此，项目改进的第一个手段，就是借助看板建立小批量快速交付的工作方式。
（看板示意图）
在团队的共同努力下，首先对之前的大粒度需求进行了拆分，原则是独立可测试，同时粒度控制在1-2天的开发工作量，最大不超过3天。
接着设计了一个简单的看板，首先让所有工作透明化，进展和阻碍一览无余，并基于此开始项目的跟踪和控制。
借助这个简单的看板系统，团队改变了之前所有工作开发完一起转测，所有功能测试完一起转UAT的工作方式，而是一张卡片开发完，就立即移入“开发完成”。测试端只要资源和环境就绪可以开展测试，就拉入“测试中”。
目的就是使每一张卡片尽快从看板的一端移到另一端，快速获取真实的反馈，避免问题集中在后期造成的不可控风险。
2. 基本质量准则
工作流动的最重要的影响因素之一就是如何定义完成。如果在每一阶段,流动到下游的工作项不满足下游的入口标准，那么这种流动就属于虚假流动，无法达到拉动价值的目的。
团队基于当前的现状，定义了两个非常简单，易于掌控的流动出口准则：
－开发转测试：
测试环境下完成showcase
前端与后端完成联调
－测试转UAT：
所有功能（全量功能）可用
本次UAT范围内全部L2及以上缺陷全部修复
团队成员一致认可上述准则后，将准则制成卡片，贴在看板上，既是提醒，也代表了对自身对质量的承诺。
虽然只是两个看起来很小的目标，但认真贯彻实现之后，产生的作用却不可小觑。1.0.2版本的平均特性前置时间从2个月缩短到3周左右，版本缺陷率也由于质量过程的前置而出现了大幅的降低。缺陷的迅速收敛使得版本顺利地在1个月后成功发布。
三、以终为始
两个小目标相继实现，项目也成功地在敏捷转型的改进中收获了“第一桶金”。有了这段时间内建立起的工作方式，特别是树立起的对敏捷的信心作为原始积累，项目便有了在敏捷改进的道路上收获更大成功的宝贵资本。
1.0.2版本的成功发布，小目标的成功实现，正是下一段收获的开始……
（本资讯于2016-12-27首次发布）
