标签:backlog scrum 敏捷开发 user story 需求
产品待办事项列表列出了所有的特性、功能、需求、改进方法和修复等对未来发布产品进行的改变。产品待办事项列表条目包含描述、次序和估算的特征。
产品待办列表的另外一个翻译产品待办事项列表显示产品待办列表里应当包含待办事项。待办事项包括所有的特性、功能、需求、改进方法和修复等对未来发布产品进行的改变。常见的待办事项是以用户故事形式来表达的。
在Scrum Guide中,产品待办列表通常以价值、风险、优先级和必须性排序。排在顶部的产品待办列表条目需要立即进行开发。排序越高,产品待办列表条目越紧急,就越需要仔细斟酌,并且对其价值的意见越一致。排序越高的产品待办列表条目比排序低的更清晰、更具体。根据更清晰的内容和更详尽的信息就能做出更准确的估算。优先级越低,细节信息越少。开发团队在接下来的Sprint 中将要进行开发的产品待办事项列表条目是细粒度的,已经被分解过,因此,任何一个条目在 Sprint 的时间盒内都可以被“完成”。开发团队在一个 Sprint 中可以“完成”的产品待办列表条目被认为是“准备好的”或者“可执行的”,能在 Sprint 计划会议中被选择。随着产品的使用、价值的获取以及市场的反馈,产品待办列表变成了更大、更详尽的列表。因为需求永远不会停止改变,所以产品待办列表是个不断更新的工件。业务需求、市场形势和技术的变化都会引起产品待办列表的变化。
若干个 Scrum 团队常常会一起开发某个产品。但描述下一步产品开发工作的产品待办列表只能有一个。那么这就需要使用对产品待办列表条目进行分组的属性。“产品代表事项列表优化(英文原文是grooming)”是增添细节、估算和排序条目的举动。这是一个持续不断的过程,产品负责人和开发团队协作讨论产品代表事项列表条目的细节。在产品待办事项列表优化的时候,条目会被评审和修改。然而,产品负责人可以随时更新产品待办事项列表条目或酌情决定。
第一级列表(比如原始需求,史诗故事) | 第二级列表(比如用户故事,需求用例等) | 第三级列表(比如界面细节) |
---|---|---|
epic1 | userstory1 userstory2 userstory3 |
对应于userstory1的细节 对应于userstory2的细节 对应于userstory3的细节 |
epic2 | userstory4 userstory5 userstory6 |
... |
...... | ... |
标签:backlog scrum 敏捷开发 user story 需求
原文地址:http://blog.csdn.net/zhangmike/article/details/24666097