结合工具来实现敏捷开发 - 8

需求的管理大致知道了点吧，不过估计你会问，讲了这么多，怎么感觉跟敏捷没啥关系呀？呵呵，之前也讲过了，敏捷开发虽然“敏捷”，但是也不会绕过整个软件开发过程，就像孙悟空逃不脱紧箍咒一样。需求作为软件开发一项非常重要的环节，我们是绝对绕不开的，即使是超级敏捷开发也绕不开，所以我还是得仔细讲一下。

好了，有了需求管理知识的铺垫，我现在可以来真正讲与敏捷直接关联的点了。之前讲过，Scrum其实就是增量迭代，也就是每个迭代周期实现一些功能，并且会有一个可以用的Build，然后经过几个迭代周期后，功能完成了很多，产品也就差不多就完成了。刚才上面讲了需求的管理，也就是功能点的管理，所以功能点就算有了，现在来开始讲如何在每个迭代里实现功能点。

我们公司的产品经理，项目经理，设计人员和销售人员总是不断在跟客户交流，然后自己也不断做研究，最后设计出很多功能来，但是老实说功能是无限的，每天都可能有新的功能出现，但是一个产品是有限的，起码时间肯定是有限的，你要在这有限的时间实现无限的功能是不可能，而且你还要考虑到未来，真的把所有功能做完了，下一个版本做啥呢？所以对于每个版本的产品，我们总是需要选择一些需要做的功能点，在Scrum里，这个叫做Product Backlog，网上翻译成产品订单，但是我自己认为叫做产品功能池可能好一点，这个池子里放满了这个版本产品需要做的功能，你做了一个里面就少了一个，做完了里面就没了，产品也就可以发布了。当然，敏捷开发提倡变更，所以在开发过程中，你可以随时随地加入新的功能到这个池子里，也可以修改原来的，甚至可以拿掉一个功能点放到下一个版本里做。这些都是可以根据实际需要来更改，所以才称之为敏捷。如果放到瀑布模型里，什么功能都是一开始定义好，开发过程中就不能再更改了。

对于Product Backlog（产品功能池），DevSpec是这样实现的，通过在产品功能树上新建文件夹来存放各个产品所需要的功能点，然后把这个需要在当前版本中完成的功能点放到Product Backlog中，Product Backlog在DevSpec中称为【待开发列表】，呵呵也比较简明，不过我还是喜欢【产品功能池】。为了加深印象，特发一张截图来说一下这个Product Backlog。