15.敏捷转型案例

京东360评估系统MVP迭代交付

京东始终关注每一位员工的成长，自2011年以来，京东360评估已陪伴大家度过了8个春夏秋冬，帮助每一位京东人更好地认识与发展自己，背对背评价，面对面交流。京东360评估海报如图4-1所示。

京东360评估海报如图所示。

京东360评估从价值观、能力、专业力和潜力4个方面邀请员工本人、上级、下级、同事对自己给予全方位、客观的发展评价。京东360评估通过折射员工自己的不同“面”，帮助员工了解自身的优势与不足。在参与评估后，员工将会收获一份反馈报告，它为员工的个人职业发展提供参考与指导，帮助员工在职场进阶之路中迈向新的台阶。京东360评估对象如图所示。

2018年4月上旬，为了京东每一位人才的发展，360多棱镜项目开始计划启动。面对时间紧、任务重、方案复杂、技术复杂等挑战因素，京东企业信息化部360项目组是怎样做的呢？

通常研发团队会践行京东价值观：战斗战斗战斗，只争第一，践行拼搏精神。但是，研发团队在评估后发现，就算进行更精细化的项目管理并且不断加班也很难保证交付日期，团队在经历多次痛苦之后，开始寻求帮助。虽然敏捷开发不是“银弹”，但是它可以给团队带来巨大的帮助，如采用可视化方式透明展示需求全局、拆解大颗粒度需求、排列需求优先级等。下面，我们一起回顾360评估系统研发团队的敏捷之路。

组建围绕价值交付的敏捷战队

在赵卫老师的带领下，360项目组由传统的业务和研发相分隔的方式，转变成业务闭环的协作模式。敏捷方法采用了Scrum框架，如图所示。

参考Scrum框架，根据团队现状，组建了包含如下角色的敏捷团队。

（1）业务代表（Business Representatives）：负责产品方向，回答为什么及解决什么问题。

（2）产品负责人（Product Owner）：负责产品方案设计，解答产品是什么、对软件系统有何需求，管理产品待办列表，设计线框图原型等。

（3）开发团队（Development Team）：负责产品实施，进行软件系统设计和实现。成员包括前端开发人员、后台开发人员、视觉设计师、移动端交互设计师、功能/安全/压力测试人员等。

（4）Scrum Master：负责引导团队持续改进、敏捷前行。

（5）项目经理：负责项目从需求到上线运营的端到端的协调和管理，包括立项、跨部门协调、团队障碍消除及风险缓解等。

如图所示，敏捷团队的核心角色包含产品负责人、开发团队和Scrum Master，而业务代表与项目经理是敏捷团队的核心利益相关者。

为了更好地统一目标，形成团队合力，赵卫老师带领团队进行了项目的快速启动仪式，包括加深团队成员之间的认知和信任的相互画像环节，高绩效京东战队的精神、氛围、品质讨论环节，以及脑暴团队的名字和Logo的环节，形成了团队的文化墙。最终成员确定了团队名字——日月星辰战神队。敏捷团队画像和敏捷团队精神分别如图所示。

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

发布计划

在进行团队快速启动之后，针对产品负责人的设计方案，团队在产品负责人的引导下，将需求条目化（将一大堆的需求说明和页面，转化成一个个用户视角化、场景化的需求条目），并采用用户故事地图工具，按照业务流程的方式对需求条目进行组织，并且对每个需求条目进行分类和分解，使需求的颗粒度变得更小，称为用户故事，这样我们就可以将有用户价值的、小颗粒度的用户故事按照优先级排入迭代中。同时，团队决定将迭代周期定为2周，既考虑了周期太短导致的工作交付物太少、价值很难体现、团队将会手忙脚乱，又考虑了周期太长导致的较晚的反馈循环、成本的变更和时间的增加。另外，团队确定了发布到生产环境的日期，也就是上线里程碑。

如图所示为采用用户故事地图进行计划发布，横向代表业务流程，最上面一行是用户活动或者特性，纵向代表用户的用户故事。

在拆分大颗粒度的需求为小颗粒度的需求，排定优先级后，考虑了用户旅程（业务流程），再加上有限的时间约束，就可以比较容易地进行计划发布（包含多个迭代的计划），先做核心的必要功能，非核心的功能放在后面的迭代中，例如，针对题库管理，按照增、查、改、删操作进行拆分，先做增加题库，后做查询题库，而修改题库、删除题库放在最后做，甚至如果时间来不及，管理员或者程序员在后台进行数据库操作。同时，团队考虑到最小可行产品（MVP），将整体功能规划成3个内部迭代版本，这样保证了每个MVP都会是一个最小、最核心的可以运转核心业务流程的版本，业务代表和产品负责人就可以不断地进行内部验证，不断打磨。同时，通过基于客观的迭代增量的交付，按照2周的迭代周期，规划4个迭代，每2周更加透明和及时地交付经过测试、可以演示的功能增量，使团队迭代地逼近项目目标，降低风险。

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

迭代计划

有了全局的故事地图、MVP和多个迭代的规划之后，团队需要执行迭代，根据每个迭代的结果对迭代计划进行调整，毕竟发布的计划是粗略的计划，需要在迭代中对每个用户故事进一步细化和挖掘，整体计划才会越来越精细和准确，这就是我们常说的持续规划。美国艾森豪威尔将军说过：“Plan is nothing，Planning is everything。”翻译过来就是“计划什么也不是，得持续规划才行”。整个团队在赵卫老师的带领下，进行了第一个迭代的迭代计划会议，而其他几个迭代计划会议，则是在积极主动、爱学习的Scrum Master的主持引导下进行的。

首先，产品负责人将本次迭代优先级最高的用户故事向整个团队讲解，在整个团队的不断努力下，团队进一步理解了需求并明确了验收标准，然后再对这个用户故事进行设计，将其拆分成不同的任务。例如，“作为评估对象，我想查看360评估报告的概况”，团队将其拆分成了如下任务：数据库任务、计算一级部门80分位任务、二级分类分数计算汇总任务、计算题目明细分数任务、生成概况HTML报告任务。另外，对每个任务的工作量进行了评估，采用的单位是理想小时。

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

这样的物理Scrum任务板可以使团队的规划和进度更加透明，团队里的每个成员都可以一眼看到全局，同时，任何新的变化都可以直接在任务板上更新。而行云系统的使用，可以保留历史、防止信息丢失，同时也可以让所有的利益相关者随时访问所有信息，燃尽图也可以自动绘制出来。

为了专注于高效产出，我们不会在迭代中插入新的需求，所以迭代计划会议也是一个很好的处理需求变更的时机。在第5个迭代中，两个巨大的需求变更出现了，一个是要做手机移动端答题，另一个是插入敬业度调查，团队根据业务方和产品负责人定的优先级，优先开发移动端和敬业度调查，将原来规划的其他内容延后。在业务上线日期固定的约束下，敏捷的优势凸显，很好地拥抱了变化，重点交付最核心、对用户最有价值的需求，而一些价值较低的需求可以安排在下一个版本中交付。

每日站立会议

为了更及时、透明地同步沟通进展、计划和障碍，团队约定每天早上10：00进行15分钟的站立会议，在Scrum Master的引导下，每个人迅速回答3个问题：昨天我完成了什么、今天计划完成什么、为了完成新的任务我遇到哪些障碍。开完站立会议之后，每个人对整个团队的状况、进展和风险都做到了心中有数，一整天都可以对目标和任务更加明确，从而专心地进行编码，如果遇到障碍，小伙伴们会及时面对面沟通，迅速确定解决办法。团队每日站立会议场景如图所示。

产品待办事项列表梳理会议

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

迭代评审会议

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

团队迭代评审会议场景如图所示

业务代表在上线前也高度赞扬了团队的战斗精神：“JD360研发天团日月星辰C位出道，在上线的大日子，研发还在继续，放弃世界杯加班的研发是真研发！”

迭代回顾会议

为了以后能更高效地工作，整个团队在迭代结束时，还要进行迭代回顾会议，对团队的工作方式进行省思。只有持续改进，才能避免返工和浪费，减少障碍风险，提高效率，以最小的代价前进。团队常规回顾会议场景如图所示。

注：图中“做的好”应为“做得好”；“问题困[插图]”应为“问题困惑”。

整个团队最有意思的一次回顾会议是360度赞扬回顾，如图所示。

资料来源：《趣味回顾会议》（Fun Retrospective）。

自动化测试

敏捷快速迭代对测试人员来说是一个极大挑战，在测试新功能的同时，还要兼顾系统原有功能的回归。与传统的瀑布开发相比，敏捷开发的快速迭代，会让纯手工测试人员捉襟见肘、疲于应付。

测试自动化是敏捷项目成功的要素之一。在敏捷测试中，回归测试环节是必需的，而且是非常重要的。随着迭代的增加，系统的功能越来越多，回归测试花费的时间也越来越长，自动化的价值体现也就越来越明显。

在每个迭代中进行小规模的自动化，逐步把稳定的功能用自动化测试实现，缩短回归时间，降低人力成本。将测试人员从回归测试中解放出来，聚焦更为重要的探索性测试，从而既达到了敏捷测试的要求，又保障了产品的质量。

自动化测试的引入和发展，在初期需要花费一些精力和时间，但是从长期来看，自动化的回报还是可期的。

业务方反馈

2018年7月4日，京东360评估系统正式上线，当即获得了各层领导及用户的高度赞扬，特别是得到了时任京东首席人力资源官的Rain总的赞扬：“点赞，手动点，牛，就要打造这样的系统和产品。”

时任人力资源部负责人刘总：“研发的同学们辛苦了！我们开发的系统越来越好，大家的合作越来越顺畅开心，感谢各位！”

企业信息化部负责人Leo：“Great news！感谢兄弟们的努力！”

人才发展部负责人纪总：“感谢大家过去两个月来加班加点的努力！在测试阶段我们已经收到了良好的反馈！希望今年京东360带给大家不一样的体验！辛苦了！”纪总曾在5月16日的“京东产品经理文化节”上，在所有产品经理面前，高度赞扬了企业信息化部门360评估系统“日月星辰战神队”团队，称其披星戴月、小步快跑，和业务部门共同迭代打磨产品，既体现了产品负责人的产品能力及开发团队的战斗精神，又体现了京东互联网敏捷运作模式。

企业应用研发部屈总：“感谢刘总、纪总、Leo对我人资研发团队的肯定和鼓励，我部将进一步加强各类模式识别算法、数据分析算法在人资系统中的落地使用，及时高效地助力业务快速发展！”

企业信息化部项目管理部负责人：“棒棒哒，用过以前的才更能体会现在的好。”

业务产品经理：“赞！感谢研发兄弟们的辛苦付出和给力支持，期待用户良好的口碑和体验。”

HR：“这次系统真的特别好用，业务反馈都特别好，界面友好度高，便捷、高效，简单易操作，大赞！”

后记

对日月星辰战神队来说，第一个发布里程碑不是终点，而是新的起点，团队现在还在迭代战斗中，不断优化用户体验，修复缺陷，同时也在进行新功能的研发。相信团队通过迭代回顾会议，可以不断发现待提升的事项，从而不断落实，持续改进工作方式。敏捷为团队打开了一扇持续改进的大门，它永远没有终点，只有持续地探索—感知—响应，才能更好地应对VUCA时代。