Product Backlog排序，通向成功的顺序

传统上，有些产品负责人通过对项目经济回报指标孤立地两两比较，进行backlog优先级排序. 成功的敏捷团队通常采用一种整体的方法，综合考虑backlog条目的风险、依赖关系和复杂性的相互影响.

        在SCRUM方法中明确要求了3个文档：           1 product backlog.         Product backlog 中列举了本项目应该实现的需求，需求采用了用户故事的方式进行描述，用户故事是一句简短的采用用户熟悉的术语表达的需求，是用户讲给开发人员的故事，不是开发人员讲给用户的故事.

最重要的，story和task的tracker不能相同. 否则在taskboard中会将task和story并列显示，尽管它们是父子关系. 因此比较好的做法是，story使用redmine默认的tracker：Support, Bug 和Feature. 而另外创建一些tracker用来跟踪task.

 java socket参数详解:BackLog. 输入连接指示（对连接的请求）的最大队列长度被设置为 backlog 参数. 如果队列满时收到连接指示，则拒绝该连接. backlog参数必须是大于 0 的正值. 如果传递的值等于或小于 0，则假定为默认值. 经过测试这个队列是按照 FIFO（先进先出）的原则.

Product Snippets: 一個 Google 固定每週一自動寄給員工的 email，信中要求員工回信，並簡短寫下上週的工作進度和本週的工作計畫. 所有的這些 Product Snippets 回信會自動被整理進一個可搜尋的資料庫，因此讓每位 Googler 都可以看到所有人在做什麼. Product Snippets 的資料也會被整理進 Google 的 Project Database (PDB)，讓所有的人都更容易的看到這些動態，無論他們所在的的部門、使用的語言和所處的地點.

在Scrum中，针对PO提出的backlog进行估算与分解是Scrum master常见的工作，简单总结了下一些概念和方法：. 1.关注backlog的创建者和来源，优先级，以及发布时间. 2.对每个backlog进行成本，复杂度，风险，功能点. 3.针对backlog在计划会议上进行任务分解，把每个backlog分解为多个task,团队成员根据相应分工与特长估算工时和认领：.

本文所说的Backlog是Scrum中的一个专用名词，大约意思是待办的工作事项. Backlog里面放的是需要实现的所有任务，包括功能性的和非功能性的任务，换句话说，就是咱们已经把客户的需求提炼出来并且已经完成了设计的部分，现在这些已经完成设计的用户需求被放在一个地方，持续添加新的进来并且随时可以分配出去进行开发，这个地方就叫做Backlog.

Sprint Backlog就是任务列表，如果映射到传统的项目管理理论中就是WBS（work breakdown structure)，而且是典型的采用面向交付物的任务分解方法得到的WBS. 比如有一个Product backlog 条目为：.     作为系统的合法用户，可以通过录入账号和密码登录到系统中.

介绍了上面三个Backlog的重要性，大家应该能感觉到在敏捷中，Backlog的确是非常重要的一个概念. 下面就来具体介绍一下Backlog的几个分类：. 由于不同的公司、不同的专家对Backlog的分类总是有点区别，所以我们就以业界最知名的敏捷开发工具 TechExcel DevSuite中的Backlog来举例子吧，.

 除了优先级外，还有一个设置也是非常重要的，就是对于每个任务，你需要做工作量预估，预估什么呢，预估该任务开发完成所需的时间和人力等，敏捷里把这个预估叫做Story Point，故事点. 故事点这个概念现在争议很多，究竟以怎么样的方式来预估工作量呢. （1） 有人说用小时，但是我们知道能力强的人跟能力弱的人所用的小时数必然是两样的，所以通过小时来得到故事点并且进而得到Velocity数据是不正确的.