由于我们是持续交付，上线也变得频繁，敏捷讲究快速发布获取反馈。但当交付的内容过多过细的时候，造成团队尤其测试、产品不知道究竟研发上了什么。还有时因为需求变更，敏捷讲究响应变化快速迭代，造成真实上线交付的内容和Sprint交付的内容不一致。

针对这种问题，特别添加了"上线准备项"的泳道。

具体说明

1. 我们讲究持续集成、持续交付，当每个Sprint结束的时候我们认为所有的Story都应该被完成，而交付 —— 上线 —— 在Sprint是持续交付的。

2. 虽然在"待上线"泳道的Story是随时可以交付的，但交付上线应该是谨慎且透明的，所以通过"上线准备项"直观的告诉团队今天上线的内容项。

如何工作

1. 提前一天与研发、测试和产品核实上线准备项，包括Story和Buffer

2. 需要测试线上验证的需要与测试沟通，重点的可以提测试单据

3. 上线当天3点准备上线包（5点上线），再次确认上线准备项（是否有变更）

4. 上线Story和Buffer与"上线准备项"需要保持一致

5. 上线之后进行线上验证，没有问题当日摘下便签（Story和Buffer）撕掉

工作实战

本文受原创保护，未经作者授权，禁止转载。 linkedkeeper.com (文／张松然)  ©著作权归作者所有