庖丁解牛——解密京东360评估系统研发团队的敏捷之路

团队找到了京东的敏捷创新教练，虽然敏捷开发不是万能的，但是给团队带来了巨大的帮助。让我们一起回顾下360评估系统研发团队的敏捷之路吧。

敏捷方法采用了Scrum框架，如下图所示

按照Scrum框架，我们组建了如下敏捷团队。

业务代表（Business Representatives) 、产品负责人（Product Owner）、开发团队(Development Team)、ScrumMaster、项目经理。

为了更好的统一目标，形成团队合力，敏捷教练带领团队进行了项目的快速启动仪式，包括了加深团队成员之间的认知和信任的相互画像环节，高绩效京东战队的精神、氛围、品质讨论环节，以及团队脑暴团队的名字和Logo的环节，形成了团队的文化墙。最终团队确定了团队名字：日月星辰战神队，背后的寓意你懂得。

为了更好的促进全员准备好即将进入迭代的需求条目/用户故事，我们讨论了“准备好的定义（Definition of Ready）”，并且，为了进一步准确估算用户故事规模，并保证真正完成，我们明确了“完成的定义（Definition of Done）”，统一了所有人的认知。

在进行团队快速启动之后，针对产品负责人的设计方案，团队在产品负责人的引导下，首先将需求条目化（将一大堆的需求说明和页面，转化成一个一个用户角度、场景的需求条目），并将需求条目采用用户故事地图工具，按照业务流程的方式进行组织，并且针对每个需求条目进行了分类和分解，使需求的颗粒度变得更小。

我们称之为用户故事，这样我们就可以将有用户价值的、小颗粒度的用户故事按照优先级排入到迭代中去。

同时团队决定迭代周期为2周，既考虑到了太短周期工作交付物太少、价值很难体现、团队将会手忙脚乱，又考虑到了太长周期导致的较晚的反馈循环、较晚反馈导致变更成本和时间的增加。并且也确定了发布到生产环境的日期，也就是上线里程碑。

在如上的故事地图中，横向代表业务流程，最上边一行是用户活动或者特性，纵向代表用户的用户故事。

经过了拆分大颗粒度的需求为小颗粒度的需求，排定之间的优先顺序后，以及考虑了用户的旅程（业务流程），团队在有限的时间约束内，就比较容易的进行发布计划（包含多个迭代的计划），将核心的必要的功能先做，非核心的放在后面的迭代再做。

例如题库管理，按照增、查、改、删（CRUD，Create,Read,Update, Delete）操作进行拆分，增加题库先做，查询题库后做，而修改题库，删除题库放在最后做，甚至如果时间来不及，管理员或者程序员在后台进行数据库操作。

同时团队考虑最小可行产品MVP（Minimum Viable Product），将整体功能规划成3个内部迭代版本，这样保证了每个MVP都会是一个最小、最核心的可以运转核心业务流程的版本，我们的业务代表和产品负责人就可以不断的进行内部验证，不断打磨。

同时在MVP过程中，通过基于客观的迭代增量的交付，按照2周的迭代周期，规划4个迭代，每两周更加透明和及时地交付经过测试、可以演示的功能增量，使团队迭代地逼近项目目标，降低风险。

团队在对每个用户故事进行估算的时候，采用的是计划扑克方式，对每个用户故事的规模大小进行相对估算，单位采用的是故事点，例如：0.5，1，2，3，5，8，13，20等，团队选取一个较小的用户故事将其规模大小设定为1个故事点，然后整个团队成员一起估算优先级最高的用户故事规模大小是这个1个故事点的几倍，例如3代表是其的3倍大小。每个故事都包含开发和测试。

有了全局的故事地图、MVP和多个迭代的规划之后，团队需要执行迭代，根据每个迭代的结果对多个迭代的计划进行更新，因为这个发布计划是粗略全局的计划，每个用户故事的细节和反馈需要在迭代中进一步细化和挖掘，所以整体计划是随着每个迭代的计划和执行，越来越精细和准确，这就是我们常说的持续规划。

因为美国艾森豪威尔将军说过：“Plan is nothing, Planning is everything”翻译成东北话六级就是”计划啥也不是，得持续的规划才行“，所以整个团队在赵老师的带领下，进行了第一次迭代的迭代计划会议。

我们是这样进行的，首先产品负责人将本次迭代优先级最高的用户故事讲解给整个团队，在整个团队不断澄清下进一步理解了需求和明确了验收标准，然后团队对这个用户故事进行设计，根据设计拆分成不同的任务。

例如：“作为评估对象，我想查看360度评估报告的概况”，团队拆分成了如下任务：数据库任务，计算一级部门80分位任务，二级分类分数计算汇总任务，计算题目明细分数任务，生成概况html报告任务。并对每个任务的工作量进行了评估，采用的单位是理想小时。

经过迭代计划会议之后，初始化/更新了Scrum任务板（Scrum Task Board），这里团队既使用了物理的便签条报事贴、大白纸和墙，也同时采用了京东自研的电子管理系统“行云”（京东研发协同一体化平台，包含：高效需求管理、敏捷项目管理、端到端交付流水线、研发效能度量等）。

这样物理Scrum任务板可以使团队的规划和进度更加透明，团队里的每个成员都可以一眼看到全局。

同时任何新的变化，可以直接用笔和报事贴直接在任务板上更新。而行云系统的使用，可以保留历史、防止信息丢失，同时也可以使所有的利益相关者透明的访问到所有信息，燃尽图也可以自动计算出来。

为了专注从而高效产出，我们不会在迭代中插入新的需求，所以迭代计划会议也是一个很好的处理需求变更的时机。

在第五个迭代的时候，两个巨大的需求变更出现了，一个是要做手机移动端支持答题，另一个是插入敬业度调查，所以团队根据业务方和产品负责人定的优先级将原来发布计划规划的内容延后，优先开发移动端和敬业度调查。

在有限的时间之内以及固定的业务上线日期的约束下，敏捷的优势凸显，很好的拥抱了变化，按照优先级、MVP重点交付最最核心、对用户最最有价值的需求，而一些价值较低的需求可以安排在下一个版本里程碑交付。

为了更及时、透明地同步沟通进展、计划和障碍，团队约定每天早上10：00进行为期15分钟的站立会议，在ScrumMaster的引导下，团队使用正确的姿势，每个人迅速的回答3个问题：昨天我完成了什么，今天计划完成什么，为了完成新的任务我有哪些障碍。

整个团队开完站立会议之后，每个人对整个团队的状况、进展和风险都做到了心中有数，一整天都可以做到腰也不酸了、背也不疼了，可以专心的进行编码了，同时如果遇到障碍，小伙伴们就可以“遇到障碍一声吼”，随时面对面沟通。

在迭代过程中，为了更好的为下一个迭代的计划会议做好准备，项目经理、业务代表、产品负责人和开发团队一起进行了产品待办列表梳理会议，详细讨论了需求的最新内容和变化，以及依赖等。

第一次迭代评审会议，业务代表第一次体会到了什么叫迭代的产品增量，因为在短短的2周之内，她们就看到了一个可以运行的软件，几个小颗粒度的功能也基本可以运转起来，这是以前很难想象到的，因为研发往往是在项目后期才给业务方进行UAT测试，业务方会“吐槽一大堆”研发在上线前改不过来的东东，只能忍痛含泪上线了，这一次业务方就可以在项目早期就进行评审，反馈接受哪些故事，要对哪些故事进行优化等等。

经过两次迭代评审会议之后，业务方特意从京东7Fresh生鲜超市为整个团队买来了新鲜的水果，表达对团队工作的感谢。
同时业务代表在上线前也高度赞扬了团队的战斗精神：JD360研发天团日月星辰C位出道，上线大日子，研发在继续。

为了更高效的工作，整个团队在迭代结束的时候，还要进行迭代回顾会议，对团队的工作方式进行省思。因为磨刀不误砍柴工，我们不应该用战术的勤奋掩盖战略的懒惰，只有持续改进，才能降低返工和浪费，减少障碍风险，提高效率，以最小的代价前进。

整个团队最有意思的是在一次回顾会议中采用了360度赞扬进行回顾，想一想360团队进行360反馈，很酷吧。小伙伴们在称赞ScrumMaster的时候都说：“谢谢你，在工作中你热心的帮助每一个人，并且对我们的成长也寄予厚望，不但技术过硬，对每一个需求及其对应的原型和任务都非常清楚！”

（来源于《趣味回顾会议》(Fun Retrospective) ）

系统上线之后，业务方的好评如潮，特别是也得到了京东首席人力资源官Rain总的赞扬。

HR小姐姐也特别发来消息：这次系统真的特好用，业务反馈都特别好，界面友好度棒，便捷、高效，大赞大赞。

本文来自微信公众号：咚咚小报（ID：jingdongyanfa），作者 赵卫 ，管理圈经授权转载。