backlog的需求优先级划分怎么划分

来源：蜘蛛抓取(WebSpider) 时间：2017-01-18 04:12 标签： 工作优先级划分
项目经理资料：一个产品负责人，一个backlog
项目经理资料：一个产品负责人，一个backlog
　　是否拆分产品backlog?　　假设你有一个产品和两个Scrum团队，那应该有几个产品backlog呢？多少个产品负责人？我们曾经为此评估过三个模型。选择不同，sprint计划会议的形式就会有很大差异。　　策略1:一个产品负责人，一个backlog　　这就是&只能有一个&的模型，也是我们最推崇的模型。　　这种模型的优点是：你可以让团队根据产品负责人当前的优先级来自行管理。产品负责人关注他所需要的东西，团队决定怎么分割工作。　　说得更具体一些，我们来看看这个团队sprint计划会议的举行方式：　　Sprint计划会议在一个外部的会议中心举行。在会议开始之前，产品负责人指定一面墙壁用做&产品backlog墙&,把故事贴在上面（以索引卡的形式），按相对优先级的顺序排序。　　他不断往上面贴故事，直到贴满为止。通常他贴上去的东西都要比一个sprint中所能完成的条目多。　　每个Scrum团队各自选择墙上的一块空白区域，贴上自己团队的名字。那就是他们的&团队墙&.然后他们从最高优先级的故事开始，从产品backlog墙上把故事逐一挪到他们自己的团队墙上。　　这个过程可以用下面的图片来描述，图中的黄色箭头表示故事卡从产品backlog墙移动到团队墙的过程。　　在会议进行中，产品负责人与团队会针对索引卡进行讨论、把它们在团队之间移动、上下挪动以调整优先级、把它们拆分成更小的条目，等等。过上大概一小时左右，每个团队就会在自己的团队墙上形成一个sprintbacklog的初步候选版本。然后团队便会独立工作，进行时间估算，把故事拆分成任务。　　整个过程显得特别嘈杂混乱，令人筋疲力尽，但同样也效果很好，很有趣，也是个社会交往的过程。到结束时，所有团队通常都会得到足够的信息来启动他们的sprint.　　返回目录：　　编辑推荐：　　　　　　
&&&主编推荐
H3C认证Java认证Oracle认证
基础英语软考英语项目管理英语职场英语
.NETPowerBuilderWeb开发游戏开发Perl
二级模拟试题一级模拟试题一级考试经验四级考试资料
软件测试软件外包系统分析与建模敏捷开发
法律法规历年试题软考英语网络管理员系统架构设计师信息系统监理师
高级通信工程师考试大纲设备环境综合能力
路由技术网络存储无线网络网络设备
CPMP考试prince2认证项目范围管理项目配置管理项目管理案例项目经理项目干系人管理
职称考试题目
招生信息考研政治
网络安全安全设置工具使用手机安全
生物识别传感器物联网传输层物联网前沿技术物联网案例分析
Java核心技术J2ME教程
Linux系统管理Linux编程Linux安全AIX教程
Windows系统管理Windows教程Windows网络管理Windows故障
数据库开发Sybase数据库Informix数据库
&&&&&&&&&&&&&&&
希赛网 版权所有 & &&如何在sprint会议上讨论backlog的细节？
在大多数sprint 计划会议上，大家都会讨论 backlog中的细节。对故事进行估算、重定、进一步确认细节、拆分，等等都会在会议上完成。那么该如何实际操作呢？推荐使用索引卡，把它们贴在墙上或摆放在桌子上。示例如下：这种用户体验比和投影仪好得多。原因是： 大家站起来四处走动=& 他们可以更长时间地保持清醒，并留心会议进展。 他们有更多的个人参与感（而不是只有那个拿着的家伙才有）。 多个故事可以同时编辑。 重新划分优先级变得易如反掌——挪动索引卡就行。 会议结束后，索引卡可以拿出会议室，贴在墙上的任务板上（参见第“我们怎样编写sprint backlogs”）。重要事项：Sprint计划会议结束后，我们的Scrum master会更新中的产品 backlog，以反映故事索引卡中发生的变化。这确实给管理者带来了一点麻烦，但是考虑到用了物理索引卡以后，sprint 计划会议的效率得到了大幅度提高，这种做法还是完全可以接受的。注意这里的“重要性（Importance）”字段。它和打印时Excel中产品backlog所记录的“重要性”是一样的。把它放到卡片上，可以帮助我们根据重要性给卡片排序（我们一般把最重要的放到左边，依次向右排列）。不过，一旦卡片被放到墙上，那就可以暂时忽略它的重要性评分，根据它们摆放的相对位置，来对比彼此的重要性。如果产品负责人交换了两张卡片，先不要浪费时间在纸上更新数字，只要确保会议结束后在产品backlog做更新就可以。把故事拆分成任务后，时间估算就变得更容易（也更精确）了。那么该如何进行故事拆分呢？这个用索引卡来做就又方便又。你可以把团队分成不同的二人组，让他们每组同时各自拆分一个故事。我们用即时贴贴在每个故事的下方，每张即时贴表示这个故事中的一个任务。 我们不会让任务拆分出现在产品backlog中，原因有二： 任务拆分的随机性比较强，在sprint进行中，它们常常会发生变化，不断调整，所以保持产品backlog的同步很让人头大。 产品负责人不需要关心这种程度的细节。任务拆分的即时贴可以和故事索引卡一起，在sprint backlog中被直接重用　　传统上，有些产品负责人（product owner）通过对项目经济回报指标孤立地两两比较，进行 backlog 优先级排序。成功的团队通常采用一种整体的方法，综合考虑 backlog 条目的风险、依赖关系和复杂性的相互影响。
　　James O. Coplien 2011 年 8 月 3 日在 Scrum Alliance 网站上发表了一篇文章，仍在引发评论，文中称新版 Scrum 指南中的改变与产品 backlog 优先级相关，或者按照 James 解释的一样，排序。
　　对一个列表进行优先级排序意味着按照各个项目的相对重要性排序。优先级排序促使两两比较列表中的项目（根据字典中的定义）。考虑一下采用冒泡法来对产品 backlog 进行优先级排序：比较最上面的两个项目，如果顺序错了就交换，然后再移向下一组项目，就这样不断循环直到列表中的每个条目都排好顺序。优先级排序和排序就这样相似。所有的比较都是局部的。这个过程类似于局部优化。
　　更广义的说，Scrum 团队和产品负责人（Product Owner）在排列 PBI 时特别需要考虑整个 backlog，以便得到最优的价值或 ROI。大多数人通常将 ROI 当做优先级，然而要将 ROI 认为是全部 backlog 排序后的长期结果，而非仅仅是将每个条目的 ROI 加总。这种观点部分是正确的，因为每个单独条目的 ROI 依赖于它在 backlog 中的位置。
　　Arlen Bankston，一位敏捷教练和咨询师，进一步解释了需要长远的看待每个项目直接 ROI 贡献。
　　每个单独用户故事的价值&&特别是在新产品开发早期&&通常因为较早得到市场和客户对功能的反馈而获得更多价值，而不仅仅是直接的 ROI 贡献。这就让简单的两两比较每个单独的用户故事成为一种过于狭隘的方法，因为产品的整体模式和客户探索必须要考虑进产生的收益。
　　敏捷社区的其他人使用了很长一段时间与排序有关的变量。几年以前，在一次谈话中，Roland Cuellar 提出了一个更好的术语，叫投放市场顺序（sequence to market），这个顺序了业务、技术和其它因素，比如风险和依赖关系。采用&顺序&这个词很有帮助，因为它允许产品管理不再困扰于&所有都是高优先级&，可以这么说：不错，这可能是事实，但是让我们决定一下下次发布哪个高优先级的项目。
　　因此，无论它被称为排序，优先级排序或顺序，有效的产品负责人从整体的角度看待的 backlog，以保证每个项目按正确的次序交付以获得最高的直接和长期价值。
　　你在这方面有什么经验呢？
　　查看英文原文：Product Backlog Ordering& Sequence for Success

我要回帖

更多关于 工作优先级划分 的文章

 

随机推荐