【腾讯敏捷转型No.5】需求没做完可以发布嘛

为了顺利举行这些会议，还需要大量会前会后的沟通工作。可是仔细发现，大部分会议的共同目的都是：确保进度和交付。保证项目进度除了通过这些会议，还会通过电话、邮件和当面沟通交流的方式反复确认，而确认的内容无非就是：

产品经理下周一能够准时交付需求文档吗？

下下周一开发部门能够准时交付完毕吗？

··· ···

无论事前做了多少工作，其实团队成员之间仍然会充满不信任。多年的经验告诉大家——盲目的相信承诺付出的代价会更高。

团队采用敏捷之后，最大的好处就是：你可以相信团队中每个成员，不需要反复确认进度。到了交付的时间，事情就会自动完成。你可能会表示质疑，世界上有这么好的事情吗？不可能？！采用敏捷确实可以做到，这个被称为“刚性交付”。

如何做到刚性交付？请看下图。      

粉红色代表参与项目的各个角色，包含四种：产品人员、开发人员、测试人员和运维人员。横方向一至五代表周一到周五的时间。这个图就是代表着团队合作开发过程中整个迭代的全景。通过这张图，团队中每个角色每天的任务都非常清晰。在迭代周期内的第一周周二，就是产品人员内部进行需求讨论。在第一周的周五，开发人员需要安排好设计评审，并且与产品人员和测试人员共同参与设计。然后第二周的五天时间内，开发人员全力开发需求。第三周的头三天进行测试和修改Bug，到了第四、五天可以进行发布。

整个敏捷实施的关键是每个角色都要准时交付自己的任务。团队成员之间不需要花太多的成本来互相确认进度，一切都需要按照迭代运行模式图里的计划按部就班进行。

或许你心中会有疑问：如果某个角色不能按时完成交付任务，应该如何处理？

举个例子：

按照原计划，开发人员需要编写十个需求，但是到了第二周的周五，快要下班的时候，只交付了八个需求，那怎么办？

以敏捷的思想，这个问题的的答案非常清晰，就是按时进入测试和修改Bug阶段，并且只测试已经完成的八个需求，剩下两个没有完成的需求放在下一个迭代里进行。尽管此时此刻在很多产品人员看来，开发人员是没有完成他的工作，说好的十个需求，只完成了八个。

这个延误交付的现象可以从两个角度来解释：

一、说明团队的能力在每个迭代里最多只能完成八个需求。如果团队承认了只能完成八个需求的能力，那么下一个迭代只需要安排八个需求即可。

二、产品需求划分不合理。如果只完成了八个需求的的版本对于用户来说，是完全无法使用的，那么问题的实质在于产品需求划分不合理。

因为敏捷团队总是会把最大的价值需求先完成，那么最后剩下的两个需求价值是最小的，所以不会出现因为两个最小价值的需求反而影响整个版本总体价值的情况。解决这个问题的方法就是提升产品人员对产品需求分解和确定优先级的能力。

如果团队实行刚性交付，会有什么好处呢？

举个例子：

机场附近的一条地铁线最早的班车时间为5:30分，我想大部分人都是没有坐过的。假如你明天早上需要赶飞机，需要乘坐这趟最早的地铁到底机场。请问：你会打电话给地铁公司确认“明天5:30早班车是否会按时发车”吗？

答案是非常明显的：不会，因为你知道他们肯定会准时发车。是什么让你这么相信地铁公司会准时发车？在我们大家的共识里，不管地铁是否有人乘坐、是否挤满了人，地铁永远是按照时刻表运行的。

把每一躺地铁比喻成一次迭代，每一位乘客就是一个需求。需求要不要上车，都是需求决定的，并不是因为迭代决定的，迭代只确保上了车的需求准时发布。如果迭代的地铁里太拥挤，无法容纳更多的需求的时候，唯一的选择就是搭乘下一趟迭代地铁。迭代只会确保上了车的需求准时发布，正是因为这样的运行规定，迭代的地铁可以保证每天海量的需求可以准时交付。

通过要求每个角色实施刚性交付，那么团队内部就可以减少很多内耗，大家逐步建立信任机制，不需要花费时间在电话、邮件和当面沟通上，团队每个角色就可以腾出更多的精力完成自己的任务。就这样形成一个良性循环，整个团队慢慢向好的方向发展。

每个团队根据自身实际情况，制定专属的敏捷迭代运行模式图，敏捷迭代运行模式图需要加入团队中所有的角色。敏捷团队制定正确的敏捷迭代运行模式图后，要根据团队每个角色的执行情况不断进行调整和改进，就能慢慢领略到敏捷的魅力和好处。

所以在今后的敏捷实践中，要清楚，敏捷从迭代运行图开始。首先需要一张敏捷迭代运行模式图，才能保证团队每个角色能够理解迭代运行模式，并且保证刚性交付顺利完成。