Agile Alliance 敏捷实践初体验-京东云开发者社区

对于敏捷开发模式，以前只是通过文章和书籍了解过相关概念，并没有真正实践过。幸运的是，随着公司推行敏捷转型，我们团队也开始尝试敏捷开发，并取得阶段性成果。

其中，**B2B招采**是我们团队敏捷实践的里程碑项目，下面为大家分享下在该项目中我们的一些敏捷实践及感受，供大家参考。

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

#### 一、面临的挑战与成果
在B2B招采项目初期，我们面临的最大问题是开发人员不足。由于该项目的特殊性及团队资源问题，我们团队只能投入3个开发人员（2个后端+1个前端），其他资源全部是外包人员，并且还没到位。

**由于我们采用了更加灵活的敏捷开发方式，最终，B2B招采项目取得一批次UAT一次性通过，二批次提前上UAT的阶段性胜利。**

#### 二、敏捷实践初体验
如果采用传统的瀑布流方式，等资源到位，等所有的计划细节都出来再开始，我们势必会耽误很多时间。所以我们转换思路，采用敏捷开发方式。

- 首先我们的PO（产品经理）跟业务沟通，将该项目划分为两个版本，分别上UAT。我们内部讨论决定4周作为一迭代，总体分为两个大的迭代。
- 迭代周期确定好后，我们先进行一批次的需求评审，由SM（团队leader）将需求拆分为不同的行云卡片，我们认领自己的卡片并拆分为详细的任务。
- 每天下午5点开站会，汇报当天的整体进度，遗留问题等。
- 我们内部团队敏捷公约要求功能开发完成必须有单元测试，必须自测完成才能提测。
- 提测后，测试同学立即介入测试，测试过程中有问题直接反馈给对应研发或产品。开发人员解决问题后立即通知测试同学。需求调整或确认后，产品立即通知开发及测试人员。

**整个过程，产品，研发和测试处于统一战线，节奏十分紧凑。**

#### 三、特别需要提及的是对外包的管理
随着外包人员的不断加入，团队出现新同学对业务，技术上手慢的情况，于是我们重新为外包人员组织了业务需求，技术组件，行云，敏捷等相关培训，对跟不上的外包人员进行劝退，以保证团队的效率及质量。由于团队中外包人员较多，我们会每周抽4~8小时进行代码评审，以保证开发的功能符合需求及良好的代码质量。

#### 四、总结一下，取得成绩主要得益于以下敏捷实践：
- **每日站会：**站会上我们会检查进度（行云），根据行云任务情况叙说昨天做了什么，今天打算做什么，遇到问题及处理方案。每日站会由回顾学习会主持人主持，总时长控制在20分钟。站会可以让团队成员相互了解都做了什么，检查进度，尽早暴露风险与问题。

- **行云：**产品将需求全部录入到行云，录入时维护好标签、优先级、上线时间、PRD需求相关资料等。研发认领卡片后，拆分需求尽量为2周左右，拆分任务为2天左右。及时维护任务状态，更新任务进度，提测后将卡片拖到待测试区域。测试同学开始测试后，将待测试区域卡片拖到测试中，测试完毕拖到待上UAT。研发根据产品及业务时间安排上UAT，上完UAT将卡片拖到待产品和业务验证区域，产品和业务验证完后上线全国。行云是很好用的可视化工具，不仅能清晰的看到需求优先级，还能跟踪需求在产研测各环节的周期，以便改进。

- **代码评审：**每周抽4~8小时进行代码评审（包括单元测试、代码的评审），由于外包较多，评审至少有两名团队内部开发人员。评审完，及时跟踪后续修改结果。

- **单测：**功能开发完后写单元测试，单测跑通才能提测。

- **回顾学习会：**每周一晚上20点举行，主要是培养团队自管理的能力，推进不同敏捷话题及工程实践，包括单测，重构，行云等。

- **全功能团队：**产研测同学都在一块，封闭开发，遇到问题随时沟通。

#### 五、回顾反思
除了以上的敏捷实践，还少不了团队每个成员的努力。当然，我们还有很多需要改进的地方，比如迭代周期可以拆分为2周一迭代，代码评审邀请测试同学参与，重构技术债，关注单元测试质量等。

通过在B2B招采项目实践敏捷开发，我们真正体会到敏捷开发这种小步慢跑，循序渐进，快速反馈模式的美好，对将敏捷开发引入到其他项目充满了期待。随着敏捷实践的深入，我相信我们团队战斗力会越来越强，我们会向着更高的敏捷成熟度前进！在此附上我们团队的照片。

------------
###### Being Agile 京东物流技术发展部效能提升部
###### 作者：快递技术部 齐保光