优先级
由 Mitch Lacey。所有者，Mitch Lacey 和合伙人，Inc，一家专门从事于敏锐和讨论调整和改进。
2012 年 1 月
在此文章中，Mitch Lacey 讨论了证实是非常有用的对于许多敏捷团队的三种方法：客户满意度 Kano 模型，通过 Luke Hohmann 的一系列 Innovation Games 和 Karl Weigers’ 相关权重模型。每个可帮助您从您的积压工作的大致的优先级设置移到该令人满意地权衡风险、重要性和客户满意度的准确排序。
应用于
应用程序生命周期管理；Team Foundation Server
本文内容中：
介绍
客户满意度的 Kano 模型
创新 Games
修剪产品树
购买一项化功能
相对权重–karl Weigers
结束语
在项目进行期间，若要继续进行敏捷团队活动函数，则必须按优先级排序在您的产品积压工作项并更新这些优先级。所有产品积压工作必须根据业务价值和风险设置其优先顺序。通过识别此优先级顺序，您的团队可以更好地在最有可能包含在您的产品的成功的功能聚焦。秩序井然和优先级积压工作付清不仅在团队和客户满意度中还在业务末行中。有关积压工作的信息，请参见 生成和管理产品积压工作、创建或添加到产品积压工作 和 梳理和估计积压工作。
在排序和优先级您的产品积压工作时，必须考虑多种因素以及可以两端对齐的决策。当以初级产品积压工作开头事，进程看起来几乎过大。幸运的是，您不需要立即为您的各项积压工作进行完善的排序。在 估计 中，描述技术称为“用墙的方法，”为有效的方法可以快速估计初级产品积压工作和工作与利益干系人到达一个大致的优先级设置。
此粗略优先级是很好的起点，可能对您的情况足够有益。在某些情况下，但是，您可能希望优化这些优先级或达到优先级的积压工作有更科学的方式。还使用某些方法来完成此任务。在以下文章中，我讨论证实是非常有用的对于许多敏捷团队的三种方法：客户满意度 Kano 模型，通过 Luke Hohmann 的一系列 Innovation Games 和 Karl Weigers’ 相关权重模型。每个可帮助您从您的积压工作的大致的优先级设置移到该令人满意地权衡风险、重要性和客户满意度的准确排序。
客户满意度的 Kano 模型
客户满意度 的 Kano 模型于 20 世纪 80 年代由东京理科大学的狩野纪昭博士开发。他的设计提供区分必需属性和区别性属性的简单评级方案。基于问卷中的方法，该模型在设计团队内是可视化产品特征和激发辩论的一种强有力的方式。
.png "产品功能关系图示例")
在 kano 中，我们在以两种不同形式询问一系列问题：功能性的和不良的。例如，假设我们询问客户有关车用 GPS 导航系统的问题。首先我们询问问题的功能性形式：
- 如果这辆车装有 GPS 导航系统，您会怎么想？
我们限制以下答案的响应：
我喜欢它这样
我希望它是这样
我保持中立
我可以接受这种方式
我不喜欢它这样
在本示例中，假设我们虚构的客户的响应是“我喜欢它那样。"
下一步我们询问问题的不正常形式：
- 如果这辆车不具备 GPS 导航系统，您会怎么想？
我们的虚构客户可以选择所列出的任何答案。但是，答案常常可以不同，而且通常情况下确实不同。在本示例中，假设我们虚构的客户对本问题的不正常窗体的响应是“我预计它应该是那样的”。
当完成此实际项目时，我们可以询问此列表否决的多个客户组的问题，也就是说，表示客户组织的不同函数的各个集合不同。您可能需要一个市场营销组、会计组、生产组等等。但是，为理解模型起见，我们假设我们仅向一个客户群提出一个问题。在我们编译我们的答案对之后（给函数和不正常的窗体的答复），则将其映射在网格中，作为表 1 显示。
.png "Kano 映射示例")
表 1 - kano 映射
注意，在示例中我们的虚构客户对功能问题的回答是喜欢，对不正常问题的回答是期待。在我们映射到网格时，我们看见这些两个特性的交集为 E，作为黄色突出显示方指示。让我们来检查一下那对按优先级排序的积压工作意味着什么。
E = 刺激者。这些是客户不期望的功能，并从其竞争对手中正确区分产品。他们很难进行标识，尤其是最初标识，因为其可能很难提出引起激动人心的功能的问题。因此，随着项目进展和客户反馈开始，刺激因素可能出现并提高优先级。
客户从这些功能接收大的满意度也愿意支付高价格拥有它们。例如，Apple 的 iPod 通过直观的、可以旋转内容匹配屏幕方向的能力使客户高兴。因为该客户将不知道需要时，但缺少该功能无法减少满意度。
在本示例中，有 GPS 导航将为激动人心的功能。至少对于接收客户反馈的点来说，浏览此功能的优先级应相对较高。
B = 基线。这些功能必须在产品中。它们必须具有高优先级功能。
不管这些基本特性执行得多好，客户都会对产品保持中立态度。字处理程序，例如，必须具有“创建文档”和“保存文档”功能。它们是项的价格。
如果我们询问了客户组有关安全带，大多数人员会回答它们“期望”一辆新的汽车附带安全带，他们“不喜欢”那个车如果它不附带安全带。如果我们将那两个答案映射到网格上，我们会发现安全带是基线 (B)，必需的功能。
L = 线性。也称为性能要求，线性功能直接与客户满意度关联。它们在基线功能（按优先顺序）之下，但必须根据其成本进行权衡。
增强执行提高客户满意度的功能或质量。减少的功能减少满意度。
产品价格通常与这些特性有关。
I = 中性。这些功能对客户来说最不重要，因此，对产品也应最不重要。它们可能返回很少的业务价值。
表 1 还显示 Q 和 R。
Q：有问题–该问题可能不正确或答案可疑。
R：反向–答案的组合不进行计算。使用 GPS 导航系统，如果有人回答它们期望它只，但它们还想，如果不是，它是 R 答案。
如果答案对被评为 Q 或 R，则您应该更深入地调查您的问题或答案对。
创新 Games
Innovation Games 是可以帮助开发主要市场研究的工具。使用这些工具，客户使用“游戏”以生成反馈和输入有关产品或服务的目的。Luke Hohmann 在他编写的书（Innovation Games）中创建并描述了超过 12 个游戏，这对任何库来说都是一项大增补。为获取按优先级排序的积压工作，我最喜欢玩的两个游戏是修剪产品树和购买一项功能，Luke 在那本书的这一摘录中描述过这两个游戏（通过许可权使用）：
.gif "Hh765981.collapse_all(zh-cn,VS.110).gif")
修剪产品树
园丁通过修剪树木控制其生长。有时该删改一艺术性的，因此，我们最终获取灌木进行建模。将或有趣的抽象形状。大多数时候修剪旨在生成一种平衡的、生产高质量果子的树。该进程不是关于“剪切”，而是关于“形状。”使用此形式帮助创建您的客户希望的产品。
游戏
通过绘制在白板或肉店用卖页面主要内容的大型树或打印树的图形图像以一个大型格式海报。粗肢表示您的系统内的主要功能区。树的边缘—其最外层的分支—表示当前发布中可用的功能。在多个索引牌上编写潜在的新功能，最好同于离开。要求您的客户在树周围放置需功能，定义其增大的下一阶段。他们构造以平衡方式增大的树?产品的一个分支，或许一个核心功能获取增加的大部分?树中的一个利用率不足的方面变得更加严格?我们知道树的根（您支持和客户关注的基础结构）需要至少最多扩展您的机盖。您的?
.png "修剪产品树的布局示例")
产品树– Hohmann
为何工作机制
您和您的客户都知道重要性可变的功能。因此，我们往往需要在最重要后放置我们工作量提供了较大值为客户的功能这些功能。不幸的是，有时这意味着我们在需要其完成该产品的功能上投入太少的工作量。修剪产品树游戏通过查看以整体方式构成产品的功能集，为您的客户提供一种提供输入决策指定过程的方式。
购买一项化功能
哪个函数将吸引客户购买您的产品？哪个功能将导致客户升级？哪个函数将使客户满意以致于它们将忽略或容忍它们希望修复或移除的功能？
产品计划人员不断辩论这些及其他类型的问题。选择权限设置功能添加到版本通常指示在其中失败或长期成功之间的差异。遗憾的是，太多产品计划人员做出了此选择，而没有涉及受它影响最大的人—它们的客户。购买功能游戏通过要求您的客户帮助您改进此决策的质量提交事务。
.jpg "游戏布局示例")
购买一项化功能 - Sterne
游戏
创建潜在的功能列表并以价格提供每一个。与实际产品一样，该价格可以基于开发成本、客户值或其他内容。尽管该价格可以为要传递给函数收费的实际开销，通常不是必需的。客户购买要在您的产品的下一版本使用您给予它们的支付货币的功能。确保某些功能的定价足够高，以致没有哪一个客户可以单独购买。鼓励客户凑其货币购买尤为重要和/或贵的功能。这将帮助促进客户之间就最重要的功能进行协商。
此游戏最适合四到七个用户以组的形式进行，以便您可以为用户创造通过协商筹集资金的机会。不同于“产品包装盒”游戏，“购买一项功能”游戏是基于可能存在于您的开发路线图中的功能的列表。
为何工作机制
产品计划人员通常陷入这样的困境，认为客户具有明确定义的产品优先级。有些会实现。大多数“请勿”。在显示选项集时，许多客户将简单地说“我想他们全部。”并放置优先级请求的责任在您的肩上。或者，产品管理器通常通过与客户一对一工作收集功能优先级别，因此在处理中，可能甚至没有意识到它，再次对优先考虑功能负责任。通过加入作为组的客户并给予其有限的资源，则有机会设置其需要的优先级别作为一个组。但这不是魔术驻留的位置。神奇在于构建对话，以便您的客户针对特定功能进行相互之间的谈判。协商增强客户真正需要的了解。
相对权重–karl Weigers
优先级设置的另一个很好的方法是相对权重，karl Weigers 在 1999 年引入。此方法不仅根据用户输入和反馈提供优先级要求的机制，而且包括团队的专家评定。与 kano 和 Innovation Games 一样，相对权重可让产品所有者更好地测量要实现哪些功能以及按哪种优先级顺序。
第一步是将权重分配到功能的相对益处。好处是用户的优势，这些用户在最终产品有该功能。下一步是分配相对损失。补偿是用户的结果，这些用户在最终产品没有该功能。(估计好处和惩罚完成和问题相同的 kano 方案功能和不正常窗体。)权重是表示您公司值的功能的好处和风险的任意数量。它类似于一个老师如何确定权重给定家庭作业、考勤、小考和测试来确定整个年级；不同的老师会有所不同。如果您确定好处超过损失，则以任何您认为合适的比例使权重高于损失。如果您确定损失大于好处，则相应调整权重。在示例中的表 2，我们获取相对权重 2 的优势和损失相对权重 1，这意味着优点将大于确定最后优先级的因素。
通过相同方式，我们确定成本百分比和风险百分比的权重。在下面的示例中，风险不是为多数项目考虑到，因此给定 1 的权重成本百分比和 0.5 的权重风险百分比。(请注意，尽管好处和损失在计算计算值百分比之前都已加权，成本和风险加权为百分比。)如果您有高风险项目，您可能权重风险高于成本。
.png "功能表示例 - 启动")
既然设置了权重，那么我们邀请用户来评估各项功能的相对益处和相对损失。每个优点和损失在一个集合缩放评级，Weigers 建议 1-9，但是，您可以选择一个不同的缩放，只要您是一致的。相对益处是该函数将传递的值，相对惩罚是不执行该函数的潜在负面影响。
例如，假定一个可能的功能是“使这些小部件符合 Sarbanes-Oxley 法规”。事实上并没有给用户带来好处，但对业务的惩罚很严重 - 如果不这样做，公司可能破产。同样，我们可能为相对优势查看分数 1 或 2 和为相对补偿查看分数 8 或 9。
在下面的示例中，用户评级功能的相对优势“供应商顺序的查询状态”作为 5。他们将相对损失评为 3。若要派生该函数的总值，我们将相对权重的数字相乘和相加：
(Benefit * Weight) + (Penalty * Weight) = Total Value
(5 *2) + (3*1) = 13
在这种情况下，功能的总值为 13 点。
.png "功能表示例 - 正在进行中")
当我们获取总相对值和功能的值百分比时，我们将远离从用户中获得“团队”的渠道。我们询问团队可以估计相对成本使用相同缩放实现每个功能。karl Weigers 解释，“开发人员估计成本分级基于因素如要求复杂、用户界面需求的范围、潜在的能力来重用现有设计或代码和所需测试和文档的级别”。
在我们估计相对成本后，我们也估计相对风险。同样，Weigers 说：“开发人员估计相对级别技术或其他风险与从 1 到 9 小数位数上的每个函数相关联。当 9 指示对可行性的严重顾虑、具有所需的专业知识的人员的可用性或对未证明或不熟悉的工具和技术的使用，1 的估计表示可以在您的休眠期编程。电子表格将计算来自每个函数的总风险的百分比”。
在注意相对优势、性能影响、成本和风险的值后，我们总结每列。这些合计将用于计算百分比。
总值百分比：相对收益和损失的总值除以底部处的总合。在下面的示例中，这是 13 / 154 = 8%。
相对成本百分比：由最低相对成本总数除以相对成本值。在下面的示例中，这是 2 / 42 = 4.8%。
相对风险百分比：由最低相对风险总数除以相对风险值。在下面的示例中，这是 1 / 33 = 3%。
优先级：（成本百分比 * 成本权重）除以价值百分比，再加上（价值百分比 * 价值权重）。在下面的示例中，这应该为 8.4% / ((4.8% * 1) + (3% * 0.5)。这提供了优先级值 (1.345)。
在我们获取优先级值后，我们按降序分类优先级列以便最高优先级项位于顶部。在将项添加到产品积压工作或有关情景合并的更多信息时，我们需要重新评估优先级。
最后，该工作表类似于该表：
.png "功能表示例 - 完成")
通过采用此方法，可以更好地了解适用于团队以及利益干系人的范围。它还有助于更好的基本的讨论，因为它可能在元素中很难有客观地因素，如优势、性能影响、成本和每个功能的风险。
Weigers 解释如何生成进一步的模型匹配您的实际情况：
“校准此模型以为自己使用一组已完成要求或以前产品中的函数。调整权重元素，直到计算的优先级顺序与您在之后您的测试集中要求是多么重要的事实后评价一致。在评估建议的新要求时，此模型还可以助于进行权衡决定。使用此模型估计它们的优先级别告诉您它们如何进行现有要求，因此，您可以选择适当的实现序列。您可以采用的所有事件可用于从政界到目的移动要求优先级，并分析一个将提高项目的能力传递最合适的序列的最重要的功能。
Karl Weigers 编写过输入相对权重的更多详细信息的两本书：Software Requirements, Second Edition 和 More About Software Requirements: Thorny Issues and Practical Advice。
无论使用这些方法中的一个或某些其他技术，请确保产品积压工作为一个生物。一旦您确定其无优先性后，就将其排开—优先级设置是维持正常积压工作中一个预期的部分。若要继续跟踪项目，必须时常重新评估这些场景、项目的重要性以及新信息对积压工作的影响。您必须尽力使利益干系人和客户涉入到项目中。此外，必须记住确定其优先级对项的估计很重要。不要让您的积压工作变得过时并中断。在哺育和修改积压工作中投资时间和工作量—您将看到不但结果的最后产品而且在底部行中。
请参见
概念
使用 team Web access，请求并处理利益干系人反馈
敏捷软件要求，Dean Leffingwell，Addison Wesley
“有吸引力的质量以及必须的质量”顺彰 kano，质量 JSQC，卷。14，No.2，1984 年 10 月。来自 kano 的原始文章。