迭代开发概念学习之Backlog

一，Scrum

https://www.cnblogs.com/qixuejia/p/5863216.html

二，Backlog

1、我们首先需要确定一个Product Backlog（按优先顺序排列的一个产品需求列表），这个是由Product Owner 负责的； 2、Scrum Team根据Product Backlog列表，做工作量的预估和安排； 3、有了Product Backlog列表，我们需要通过 Sprint Planning Meeting（Sprint计划会议） 来从中挑选出一个Story作为本次迭代完成的目标，这个目标的时间周期是1~4个星期，然后把这个Story进行细化，形成一个Sprint Backlog；

参考网址 http://blog.chinaunix.net/uid-26374858-id-4569955.html

对于这三类分法，下面来解释一下：

 

1. Product Backlog (产品待办事项)是条目化/量化的用户需求，它将需求文档中需要实际开发的需求条目化地表达出来。

 

在这个Backlog里，存放着所有已经设计完成需要完成的用户需求，当然只是需要完成，不需要指定时间与负责人，只要分门别类就行了，未来会通过产品地不同版本来一一去实现，就像微软的Windows系列那样，也许微软早就已经设计好Windows 2020的功能了，只是现在还不去开发，只是先放在Product Backlog里罢了。

 

另外，这个Backlog还可以保存之前准备做但是又被取消或者延迟的一些用户需求等等。

 

2. Release Backlog是本次发布需要完成的任务

 

这里所谓的Release，是指一次大的发布，比如说微软的Windows 8发布。每次发布，我们必然有大量任务需要去完成，而这些任务，即使在敏捷中，也是会事先选择好这次发布需要完成哪些的，当然中间有变更，敏捷还是很欢迎的，但是我相信大部分应该没啥变化。

 

所以Release Backlog就保存了所有这个发布需要完成的工作，所以这个就意义重大。而且跟分配任务相关的估值、优先级的设置也是在这个地方完成的。

 

3. Sprint Backlog是本次迭代需要完成的任务

 

Sprint Backlog是开发过程用得最多的Backlog，因为每次Release会建立大量的Sprint，而每个Sprint都有一个Sprint Backlog。

 

在Release Backlog中已经设置好了Story的优先级与故事点数，所以根据这两个的值，我们就会通过分解生成更多小的任务的方式去分配到当前Sprint中去完成，开发组长只需要在Sprint Backlog中将任务根据员工的技术水平与可用时间进行合理分配就行了。

 

当分配的小任务无法在当前Sprint中完成的时候，可以根据需要在下个Sprint分配任务时分配到该Sprint中继续完成，当然估值方面就需要下次注意调整了。