敏捷转型16个月，总结期间得与失(3)

因此，我们采用了版本火车的概念，以发布为主，功能为辅。也就是在固定的时间节点必须发布，如果对应功能没有达到发布要求，就推迟到下一个发布版本。这样做却带来了几个比较揪心的问题，我们版本没有明确的主题，仅仅是一堆已完成的需求而已，导致每个版本的亮点不够。

另外，由于没有规划版本，因此无法给到前端明确的心理预期，他们不知道他们的需求在什么时候能发布，他们也不知道我们的下一个版本将会携带哪些需求。而对于开发而言，也缺乏明确的目标感，给人一种来了需求我就做，做多少算多少的感觉。于是，我们最终还是放弃了版本火车，改为版本规划的方式进行整个产品的研发。

版本规划，最头痛的问题就是选哪些需求进入该版本进行开发的问题。要知道，需求永远都是源源不断的来，需求的总量总会远远大于你当前版本能开发完成的总量。因此就涉及到一个需求收集和筛选的问题。如果每次版本都要筛选那么多需求，需要耗费很大一拨人大量的时间来进行需求优先级讨论，以及该需求是否在该版本做的问题。另外，在这么短的时间内也得不到太有效的讨论结果。在《看板实战》中，有一个“优先级过滤器”的实践方案，如下：

在这个看板上，明确了一个团队的产能，以及接下来要做的需求。当一个需求被挪走后，就会触发后续需求的进入和讨论，这样每次只需要讨论少量的需求，更加聚焦。这固然是一个好的实践，可是我们现阶段的团队并不能适应它，因为我们并没有真真的做到精益里面提到的拉动式开发。于是我们在进行版本规划时，采用了如下方案：

在下一个版本开展前两周开始收集需求。一个版本一定要有一个明确的主题。版本有明确的时间节点。需求要明确必须、应该、可以三个优先级，比例要适中。必须的需求未按期完成时，版本发布时间后延。应该的需求要保障至少80%的交付率。可以的需求要保障至少50%的交付率。需求收集完后分为多次进行版本规划讨论会议。

分多次进行版本规划讨论会议很关键，由于需求收集的量比较大，另外参会的人比较多，大家很难一次性达成一致。当一次会议结束后，需要给到整个团队一些线下时间做更多的思考以及了解更多的附加信息来进一步评估。我们一般会开2到3次这样的会议，每次会议时间为1到2个小时，这是一个逐步收敛和达成一致的过程。

3.未来

我们的项目过程，还有很多值得优化的地方。到目前为止，我们的项目开展过程只能说做到了有序。而在接下来的日子里，我们还需要加强项目的度量。做到，不凭感觉规划版本内容的多少，不凭感觉说项目做得好还是差。通过度量数据，更客观和明确的暴露项目中的问题。

4.推荐书单

对于我自身，经历过公司组织的一次敏捷咨询后，就踏上了部门敏捷转型的道路，期间踩坑无数，幸得以下书籍把我从一个一个坑里面拉了出来。推荐的书单中，部分书籍还未读完，大部分书籍阅读完一两遍后还不得其道，还需要反复阅读和实战，这里就不好意思写自己的感悟和对这些书的评价了，以免误导大家。但是，这些书都是在我转型的道理上，给予我不少启发和帮助的书籍，我相信读过这些书的人都能有所收获。

《敏捷软件开发实战-估算与计划》《敏捷软件测试》《精益创业》《精益创业实战》《看板方法》《看板实战》《网易一千零一夜》《人月神话》《四步创业法》《目标》《卓有成效的管理者》《最后期限》《思考，快与慢》

文章作者系 @小蚂蚁 未经许可，禁止转载。

注：相关网站建设技巧阅读请移步到频道。

编辑：未知