Agile Alliance 玩转大项目-大项目如何做好敏捷拆分-京东云开发者社区

------------

敏捷开发已成为很多团队提升运转效率的共识和有效途径。在敏捷落地的实践过程中，每个团队都会或多或少遇到一些不同的问题。

传统意义上的大项目与敏捷开发似乎成了两个对立的概念，一个大而全，一个小而美，事实上后者可以是前者顺利推进的一种方法论和有力保障工具。而做好大项目的敏捷拆分是敏捷开发实施的关键。今天我们结合源动TC团队的一个较为典型的案例，来和大家分享一下如何做好大项目的敏捷拆分。

#### 案例背景
TC入库助手是为运营侧提升现场管理水平的智能化管理系统。主要用来解决目前TC收货现场存在的诸多运营管理弊端，如车辆排队信息不透明，预约车队车辆到站情况不掌握，车辆等待及收货作业时长无法统计，客户现场收货满意度无从获取等。研发该系统对TC研发团队来说，面临着如下几个困难：

- 微信小程序相关研发技术不熟悉
- 业务方初期要求的项目周期较为紧张
- 期间业务方微信小程序账号申请远不及预期，影响整体开发测试进度
- 研测比高，1个测试同学对5个研发同学，排查解决问题效率可能相对较低
- 整体项目跨迭代，研发周期相对较长，涉及对原有流程改造点较多，对平稳上线造成一定压力

#### 第一时间做好技术调研
首先，TC研发团队多为侧重于后端开发的同学，对微信小程序开发了解甚少。针对研发技术储备不足问题，团队有较为明确快速的反应，即第一时间安排人员做相关的技术调研。包括技术选型、用户登录、前后端交互、服务消息推送等一系列问题。尽量保证项目开工前完成主要的技术调研。
#### MVP拆分&排序
其次，对于业务方要求的工期紧张的问题。我们一方面与业务方沟通，陈述客观的实际困难，争取一些必要的时间。另一方面根据麦肯锡法则“**重要的事情，永远摆在第一位**”，我们对系统做了拨丝去冗，提炼精干 ，提取了一些满足业务方最核心诉求的需求，即：签到、排队、反馈等。相应的，我们对拆分的需求按优先级做了排序，分批次完成开发测试，分批次交付研发成果，优先保证核心功能的万无一失。这样业务方可以在最短的时间内得到最想要的功能。

这里，我们对项目按照不同的视角做了拆分，以求让每个拆分项做为一个独立的MVP，即最小化可行产品。第一，我们从用户视图对需求做了拆分，研发与产品同学一起对需求做了功能模块及功能点的分析、挖掘，评判其重要程度、优先级别、是否有前置依赖条件、是否可以独立上线等。第二，我们在用户视图需求的基础上，又做了技术层面的拆分。技术拆分主要是看需求点之间是否有技术实现层面可以抽象的公共部分，稳定性与扩展性如何，以达到职责单一、代码重用等技术目标，从而提升开发效率。例如，入库助手项目中有这么两个需求点：

1. 通知商家准备收货
2. 通知商家收货完成

![](//img1.jcloudcs.com/developer.jdcloud.com/e409eee7-26c6-404f-b150-79e1945f77ce20210120113027.png)

从用户视图来看，这是两个独立的需求点；从技术视图看，为了达到代码复用及业务解耦，我们抽取了用户消息推送公共服务，并拆分了排队状态变化MQ消息。最终形成了4个独立的颗粒度更小的需求。即：

- a 主流程收货结点检查并触发排队状态变化MQ
- b 主流程转运单确认结点检查并触发排队状态变化MQ
- c 消费排队状态变化MQ处理业务数据
- d 用户消息推送公共服务

其中a可以看作是用户视图任务1.1 的对照需求，b为任务2.1的对照需求，c为任务1.2和2.2的对照需求，d为1.3和2.3的对照需求

![](//img1.jcloudcs.com/developer.jdcloud.com/e202f0a2-64eb-4bef-8313-7a7c8cea13b920210120113127.png)

使用基于MVP拆分的迭代交付模式后，研发同学与业务方的交互更为频繁了，项目偏离需求的风险更小了，整体风险也更可控了。对业务方来说，能够在较短时间看到核心的项目成果；对研发同学来说，能够专心应对一个个MVP拆分需求，并争取到更多的研发时间来逐步完善整个项目。下图为传统项目管理模式下的一次性交付和敏捷模式的多次小版本交付的对比。

![](//img1.jcloudcs.com/developer.jdcloud.com/18855531-1011-4616-8507-ac435f709be320210120113727.png)

#### 需求酌情预留BUFFER
在对项目做项目拆分和排期前，我们对项目先做了较为完整的系统设计，然后产品、研发、测试等同学一起对设计做评审，通过对设计的评审、修改、再评审，确保了我们对需求理解不会出现大的偏差，为后面做需求拆分、排期提供了可靠依据。但即使前期做了调研和设计，也总是会有一些被忽略的技术点需要开发的时候去做调研确认，对于这种团队做新技术研发的场景来说，尤其如此。

我们的思路是在做开发时适当预留一些BUFFER，BUFFER的尺度由我们自己掌握，比如如果需调研的技术点是世面上比较常见的应用技术，我们的BUFFER会预留的少一些，对于世面上不常见的或基于京东某些业务场景去做的技术应用，我们预留的BUFFER时间会相对长一些。

#### 单个需求工作量控制及二次拆分
在一开始去做项目拆分时，我们应该尽量去控制单个需求的工作量，避免单个需求的工作量过大，同时也要避免需求之间的工作量差异过大，使的项目中的需求整体协调。然后我们会去制定开发迭代计划。

在项目研发阶段，我们希望项目能够按照预定的计划去推进。但经常事与愿违，由于某些主观或客户因素，会造成部分需求的实际耗时可能比预定的周期长，导致需求迟迟不能交付。比如下面列举的两种情况：
1. 由于一开始评估上的疏漏，需求A看似很简单，实际去做研发时发现工作量很大。智者千虑必有一失，这种情况在大项目里无法彻底规避，就像非常优秀的程序猿也无法规避bug一样
2. 需求B依赖了外部系统的接口，而外部系统的接口由于某种原因一时难以提供

对于第一种情况，我们要对需求A的工作量去做一个重新评估，然后做个二次拆分；对于第二种情况，我们要将需求B拆分为可控部分B1和不可控部分B2，对B2不可控部分我们可以适当做迭代计划调整。

在TC入库助手项目中，有一些功能是依赖微信小程序账号去开发测试的，但业务方侧小程序号的申请较为滞后，且后面要走法务、企业资质审批等流程，账号申请下来的时间可能比我们预期的更晚。这使的项目会拖着一条尾巴无法完成，可控性较差。针对这种情况，我们尝试做了**研发侧闭环**。

研发侧的闭环指的是研发侧将任务收口完结，把当前需求为可控部分和不可控部分。需求的不可控部分等条件俱备后，再次启动迭代，不依赖于特定的人员和关联需求。拿项目中依赖小程序账号的服务通知推送功能来说，没有账号情况下可以简单打一条日志或记录一条数据。等账号申请就续后，在后续的敏捷迭代里再去创建新的需求，可以由不同的人去开发完成。整个过程可以对业务侧无感知，也可以做好沟通来共同推进整体目标。

#### 面对面测试
大项目经过需求拆分后，拆分项由不同的研发同学去认领完成，对测试同学可能会造成较大压力。本项目测试研发比为1:5，在测试阶段测试同学测出问题要找相应的研发排查确认，却拿不准是谁的问题，应该找谁，遇到一些边界问题可能每个研发都不会去关注，造成测试难以推进，整体测试进度缓慢。相信很多团队也遇到了同样的情况。

TC研发团队遇到多人合作的类似较大项目，总会指定一名研发负责人，测试直接对研发负责人，由研发负责人去确认是谁的问题应该找谁。实际上，我们这边通常是研发测试挤一张桌子，面对面测试，遇到问题随时排查定位原因，再找相关的研发同学修复解决，颇有点极限测试的意思。
#### 需求分批上线
一个大项目经过拆解后可能会拆分几十个子需求来，而且大项目一般都跨周期较长。项目周期一旦拉长，代码的冲突量也会逐渐增加，与其它功能需求相互应影响，对后面项目的平稳上线也会造成很大风险。为了控制风险，我们需要将项目拆分的子需求分批上线。首先我们将子需求分类，分类标准有很多，我们是按照子需求与现有业务的耦合程度做的划分，分成了前置功能、核心业务流程改造、运营管理、小程序后台、小程序前端等类别，然后将子需求分批上线。如下图所示：

![](//img1.jcloudcs.com/developer.jdcloud.com/0abed14a-fadd-40d3-825e-bfb7a3390efd20210120113757.png)

#### 总结
在面对新入手的大项目时，做好项目拆分至关重要。首先要做好技术调研工作，项目的研发负责人要做全局掌控。其次，需求拆分从时间周期上要协调，有必要时对需求做二次拆分或对迭代目标做调整。最后，基于拆分需求，做好测试和上线环节风险管控。

------------
###### Being Agile 京东物流技术发展部效能提升部
###### 作者：供应链技术部 鞠炳焘