小米快递精团队：我们的业务敏捷实践

前言

小米快递是一款面向C端用户的产品，需求来源于规划和用户反馈，团队成立之初就在探索如何摆脱瀑布式的项目管理，希望团队能够有序有节奏的完成项目迭代，从而保障项目的持续更新升级，所以小米快递团队成为信息技术部第一个尝试引入精益创业和Scrum敏捷管理的团队。由于前期没有专业老师指导，只是有样学样的执行敏捷的形式，并没有真正的帮助大家摆脱项目困境。8月份，部门组织引入敏捷导师进行精益与敏捷转型，在杜伟忠杜老师的指导下，小米快递团队从野路子走上了正规化精益与敏捷之路。

为什么要精益创业

作为小米创新项目，我们与其它敏捷项目最大的不同是要应对更加不确定的市场变化。单纯的敏捷方法是无法帮助我们在市场业务上取得重大突破，后来在杜老师的建议下，我们引入了一种科学创业的必备方法论——精益创业。精益创业是把假设验证和学习迭代作为其核心思想的方法论。

在人力有限的情况下，我们在项目迭代中运用了精简式反馈、客户访谈、MVP、数据原型、实地考察、假设验证待办列表等实践来加速我们对市场的学习。如今小米快递团队中的每个人都把用户体验和业务增长作为最重要的工作内容，无助于这两方面的工作都是一种浪费。

什么是敏捷，为什么要敏捷

敏捷研发是涉及整个软件工程的理念与实践，它的核心是迭代和增量式软件开发方法。开发者快速发布一个可运行但不完美的版本投入市场，在后续迭代中根据用户的反馈改进产品，新增一到多个用户可以感知的完整功能，从而逼近产品的最终形态。

迭代是整个理论的核心，通过逐步细化、迭代前进的方式，分阶段地将需求予以实现。我们先从整体功能规划中定位出一小部分核心功能，打造能基本运转、对用户有价值的最小可用产品（Minimum Viable Product，MVP），然后迅速迭代开发，听取用户反馈，及时调整功能规划。而Scrum正是这样一种组织形式的敏捷方法，如下图：

举个例子，唐僧师徒去西天取经可以被看作敏捷中的全功能团队，团队有共同的目标是取得真经。他们历经了九九八十一个迭代，每次打怪成功都是完成了一次交付。在不断迭代的过程中，团队不断地收集反馈、持续改进，一步步地完成了最后的目标。取到了真经完成了项目的交付，同时使得团队能力得到质的提升。这种组织形式非常适合小米快递团队小步快跑的思路，因此敏捷成为小米快递团队践行的真经。

自我认知 

开始杜老师帮我们团队做了一次敏捷团队成熟度评估，由团队的所有成员进行自我测评，最后得出团队能力的雷达图：

雷达图显示小米快递团队已具备敏捷团队的基本组织形式，但是与真正的敏捷还差距很大，特别是在需求管理、目标管理、持续集成、自动化测试等方面的欠缺，因此杜老师帮我们定制了指导方案帮助团队走上正轨。

制定规范-确定组织角色和职责 

Scrum Master（韩亚）

• 有仪式感，能够有效地、高效的组织迭代计划会、每日站立会、功能演示会、迭代回顾会等
• 帮助团队聚焦交付目标和质量目标，确保团队高效交付高质量的产品
• 推动团队建立高效的流程，指导团队了解敏捷价值观、原则和敏捷实践
• 负责培训团队其他成员，确保Scrum得到正确运用
• 促进团队有效的交流协作、问题管理、冲突解决，帮助团队消除一切障碍

Product Owner(PO)：尹美玲

• 把握产品的方向，担负起产品短期以及中长期的规划与管理
• 为投资回报率负责、为产品规划愿景
• 负责用户研究和产品功能规划，深度跟踪、分析、挖掘不断变化的需求，不断进行产品创新
• 在冲刺计划会之前PO与Scrum Master对需求作出一个粗略的story point评估
• 维护产品需求池、缺陷池，对产品待办事项列表实现的优先顺序进行调整
• 有权接受或拒绝成果

Team：李帅帅、侯雅文、何元勋、刘晶

• 参与各形式会议，评估需求（story）和story point
• 根据需求形成固定周期的迭代内容
• 负责制定好的迭代完成迭代开发和上线，交付产品功能
• 自组织、跨职能，无角色
• 负责达到自己的承诺，有权利决定如何达到承诺

商务：黄忠强

• 负责小米快递商务相关工作，不参与迭代会议，但是参与站会和回顾会

制定团队工作协议

团队在工作协议的约束规则里工作，会促使团队更加高效地协作并提升团队的自组织能力。Scrum是一种经验式的过程，我们的工作协议由团队根据需要共同商议制定，因为只有自己制定的规则才是团队自愿的，才是团队最好的动力支持。另外工作协议也不是一成不变的，在每个迭代的回顾会议上，团队定期回顾工作协议的遵守情况，以及工作协议是否有效。在回顾会议上，团队也会根据这个迭代暴露的问题重新审视、更新工作协议。

工作协议制定后会打印出来粘贴在看板上，以便大家方便遵守和查阅。如下是小米快递的工作协议：

确定迭代日历

小米快递根据自身情况，选择了2周的迭代周期。三个主要的会议贯穿每一个迭代：

• 每天早上9：30举行站立会
• 迭代的第一个周一10：00举行迭代计划会
• 迭代的最后一个周五17：00举行迭代演示&回顾会

其他规范

同时团队一起完成了对就绪的定义、完成的定义，并约定好发布计划和发布流程。达成共识，方便团队的协作。

执行

需求梳理-用户故事地图

用户故事地图并不是一个简单的传统列表，它是一个backlog的二维地图，使得我们在需求拆分的过程中，仍然能够清晰的看到产品的全貌，同时也能够让我们以用户的角度来审视自身的产品，帮助决策需求的重要程度和优先级。

在杜老师的指导下，与产品一起梳理出了小米快递的用户故事地图：

需求收集和管理

小米快递的需求来源于规划和用户反馈，统一由产品经理（PO）来收集，选用公司统一的TB看板管理需求，便与对需求的规划、拆分和管理。TB是产品经理（PO）的工作台，PO负责TB的更新和维护，需求都由产品提前评估产品方案和优先级，每次迭代的需求都从需求池中按照重要性和优先级来挑选已就绪的需求。

小米快递的需求分为两类：

• 新需求：是能够直接对用户输出价值的新功能，由PO能够直接安插进用户故事。
• 缺陷：上线后发现的bug和一些技术债（为了加速开发流程，工程师往往会在应采取最佳方案时做了妥协，采用了短期内可以加速开发流程的作法，但长远来看会成为迟早要填的坑）

每日站立会

每天的站立会帮助团队的所有人了解其他人都在做什么，当前项目计划的进展如何，同时也可暴露出大家在当前项目中遇到的阻碍，尽早暴露尽早解决保障迭代的顺利完成。因此每天的站立会每个人都会围绕三个内容展开：

• 你昨天完成了哪些工作？
• 你今天计划做哪些工作？
• 目前的困难及障碍？

迭代计划会

会议开始前PO会对本次迭代所有需要评估的backlog完成产品方案，并交由team评估方案和工时，如果有些backlog太大，需要一起评估拆分，将所有的backlog都拆分到能够以天或者半天评估工作量的粒度。开会的时候，大家就可以拿着自己的卡片进行参会，根据产品制定的优先级进行本次迭代的计划评估，避免迭代会时间太长的问题。

一次迭代的需求量多少依据120%的原则制定，比如团队的平均速度是50，本次迭代则安排大约60点的工作量，一是为了避免团队提早做完冲刺中的任务而无事可做，二是为了能够让团队有一些加速空间，鼓励团队在迭代里挑战自我完成更多的工作。

迭代计划会后产出本次迭代计划看板，如下图：

迭代演示&回顾会

考虑演示和回顾都在迭代的收尾阶段进行，所以小米快递团队决定把两个会议时间合并，但是还是会分别进行两个会议的内容。本次会议前小组会使用因违反工作协议产生的“捐款”购买一些零食，让会议氛围尽量轻松，鼓励大家畅所欲言，提出有价值的问题和建议。

迭代演示会是为了确保迭代至少是一项完整的、可以使用的功能，同时大家可以一起评审本次产品迭代的功能，思考有没有没想到的缺陷、优化空间，也可基于功能审视如何把功能发挥到最大价值。在让团队成员演示自己做的功能的同时，也能让大家对自己的产出认可，有一定的成就感。

迭代回顾会围绕以下内容展开：

• 为什么会发生那件事
• 为什么我们当时忽略了
• 本次迭代的燃尽图分析，怎样才能加快工作进度
• 有哪些有待改进的地方

迭代回顾遵循一个原则：无论我们发现了什么,考虑到当时的已知情况、个人的技术水平和能力、可用的资源，以及手上的状况我们理解并坚信每个人对自己的工作都已全力以赴。避免陷入指责和甩锅的误区。

结语

小米快递团队在杜伟忠杜老师指导下，已完整的进行了5次迭代，在这期间通过MVP的思想完成了小米快递小程序的开发和上线，并在上线后持续的接收来自用户的反馈，还在持续进行产品的改进和优化。Scrum使我们团队的开发方法很敏捷，能够迅速调整开发过程中遇到的问题，不会出现重大的方向错误，即使有小的错误也可即使的纠正，从而降低了项目开发中的风险。在MVP的实践中，能够使我们的产品快速上线并得到反馈验证，能够得到快速试错的结论，帮助决策下一步方向。团队在Scrum的指导下，每次的迭代也变得目标更清晰，开发计划更为明确，让每个参与其中的小伙伴都能够享受敏捷的过程。

相信在敏捷的帮助下，小米快递团队可以为米粉奉献更贴心的功能，提供更优质的快递服务。