捷项目管理中两个处理产品优先级的常用方法（一）：MoSCow
MoSCow简介
在时间固定的DSDM项目中，至关重要的是要了解要取得进展并按时完成工作的相对重要性。优先级可以应用于需求/用户故事，任务，产品，用例，验收标准和测试，尽管它通常应用于需求/用户故事。（“用户故事”是一种以敏捷样式定义需求的非常有效的方法；有关更多信息，请参见后面的“需求和用户故事”一章。）MoSCoW是一种优先级排序技术，用于帮助理解和管理优先级。这些字母代表：
必须有 Must Have
应该有 Should Have
可能有 Could Have
本次不会有的 Won’t Have this time
MoSCoW在敏捷项目上的使用效果特别好。它还克服了与基于优先级的更简单的优先级排序方法相关的问题：
- 简单的高，中或低分类的使用较弱，因为缺少或需要定义这些优先级的定义。这种分类也不能为业务提供预期的明确承诺。具有单个中间选项（例如中号）的分类也允许犹豫不决
- 简单的顺序1,2,3,4…优先级的使用较弱，因为它对类似重要性的项目不太有效。关于某个项目应该位于更高还是更低的位置，可能会进行长时间的激烈讨论。
这次必须拥有，应该拥有，可能拥有或不拥有的特定用法清楚地表明了该项目及其完成的期望。
MoSCoW规则
必须具备
这些提供了项目保证交付的最低可用需求（MUST）。可以使用以下一些方法来定义它们：
- 没有这一点，就无法按时完成目标；如果未交付，那么在预定日期部署解决方案将毫无意义
- 没有它是不合法的
- 没有它就不安全
- 没有它就无法提供可行的解决方案
提出问题“如果不满足此要求会发生什么？
” 如果答案是“取消项目–实施不满足此要求的解决方案是没有意义的”，则这是必须具备的要求。
如果有某种解决方法，即使这是手动且痛苦的解决方法，那么它也应该是“应该具有”或“可能具有”的要求。将需求分类为“应有”或“应有”并不意味着不会将其交付。只是不能保证交货。
应该有
应有的要求定义为：
- 重要但不重要
- 遗漏可能会很痛苦，但是解决方案仍然可行
- 可能需要某种解决方法，例如期望管理，低效率，现有解决方案，文书工作等。解决方法可能只是临时的
将“应有要求”与“可以拥有”区分开来的一种方法是，通过审查未满足要求引起的痛苦程度，以业务价值或受影响人数来衡量。
可能有
可能有需求定义为：
- 想要或希望，但次要的
- 如果排除的影响较小（与“应有”相比）
这些要求提供了主要的应急储备，因为只有在最佳情况下才能完整交付这些要求。当问题发生且截止日期有风险时，一个或多个可能有（Could haves）将提供从该时间范围内删除哪些内容的首选。
不会有
这些是项目团队已同意不会交付的要求（在此时间范围内）。它们记录在优先需求列表中，可在其中帮助阐明项目的范围。这样可以避免以后再非正式地重新引入它们。这也有助于管理人们的期望，即某些要求不会（至少是这次不会）直接进入已部署的解决方案。Wo n’t Haves可以非常强大地将时间集中在更重要的Could Haves，Shoud Haves和特别是Must Haves上。
与特定时间段有关的MoSCoW
在传统项目中，所有需求都被视为必须满足，因为从一开始就设定了期望，即一旦遇到问题，一切都会交付，通常时间（结束日期）会减少。
DSDM项目有一个非常不同的方法。确定时间，成本和质量以及协商功能。在基金会结束前，确定项目和第一个项目增量的结束日期。为了在截止日期之前履行这一承诺，DSDM项目需要在优先要求范围内建立应变性。因此，最初的主要重点是为项目创建MoSCoW优先级。
但是，在决定作为项目增量的一部分交付的内容时，下一个重点将是同意MoSCoW对该增量的优先级。因此，在这一点上，需求可能具有两个优先级；MoSCoW用于项目，MoSCoW用于增量。最后，在计划一个特定的时间框时（在每个时间框的开头），解决方案开发团队将为该时间框的要求分配特定的优先级。在这一点上，大多数要求是“不具备”（针对此Timebox）。
只有解决方案开发团队计划在开发时间内进行工作的要求才被分配为必须具备，因此，需求可能具有三个优先级：
- MoSCoW项目
- MoSCoW的项目增量
- MoSCoW此时间框
例如：
即使必须具备IT解决方案的要求才能存档旧数据，但很可能在没有该设施的情况下该解决方案也可以有效使用几个月。在这种情况下，明智的做法是使归档工具对于第一个项目增量为“应该具有”或“可能具有”，即使在项目结束之前必须提供此工具也是如此。同样，对于项目增量的“必须具备”要求可以作为早期“时间盒”的“应具备”或“应具备（或不具备）”。
在“时间盒”级别上工作时，不要忘记更大的图片目标（项目增量的完成和项目的交付）。一种简单的处理方法是创建一个单独的Timebox PRL，它是项目PRL的子集，专门与单个Timebox关联，并且在项目的主PRL上保留优先级不变。
确保有效的优先级
平衡优先事项
在确定为“必须拥有”需求分配的工作量时，请记住，“必须拥有”以外的任何东西在某种程度上都是偶然性的，因为“必须拥有”定义了可以交付的最小可用子类别。
DSDM建议：
- 将项目/必须达到的项目增量百分比（按照交付的努力程度）提高到团队对交付它们的信心很高的水平–通常不超过60％的必须努力
- 同意项目/项目增量的可能储备池，以反映出合理的应急水平-通常约20％的可能需要努力。创建一个合理的Could Haves池从一开始就为业务设置了正确的期望-这些需求/用户案例可以在最佳情况下完整地交付，但是主要的项目/项目增量重点始终是保护必须拥有和应该拥有
优先事项的这种分散提供了足够的应变性，以确保对成功的项目成果充满信心。注意：在计算时间范围内的工作量时，“没有”（针对此时间范围）被排除在外。DSDM的建议反映了典型的项目方案。使MoSCoW工作的重要之处在于在必须交付的要求级别上具有一定的可见灵活性。为了确信项目成功，必须具备要求的安全百分比应不超过必须付出努力的60％。
a：MoSCoW –平衡优先级
必须付出的努力水平超过60％会带来失败的风险，除非团队正在一个符合所有以下条件的项目中工作：
- 估计是准确的
- 该方法非常好理解
- 团队“表现出色”（基于塔克曼模型）
- 就外部因素导致延误的可能性而言，了解环境并降低风险
在某些情况下，“必须努力”的百分比可能大大低于60％。但是，这可以通过提供最大的灵活性来优化应有的更大范围的Shoves Haves交付的价值，从而使业务受益。
尽管DSDM还建议创建一个合理的Could Haves池，通常大约占总工作量的20％，但必须由每个项目团队同意才能在Musts，Shoulds和Coulds之间进行精确的分配。
有效的MoSCoW优先级排序与平衡每个项目的风险和可预测性有关。
预先商定优先事项的工作方式
DSDM定义了不同优先级的含义-MoSCoW规则。但是，尽管“必须拥有”的定义是不可商议的，但是“应该拥有”和“可以拥有”之间的区别可能是相当主观的。如果团队在项目开始时同意如何应用这些较低级别的优先级，这将非常有帮助。预先了解将应有与应有分开的一些客观标准，并确保项目中的所有角色都同意已达成的协议，可以避免以后进行过多的讨论。寻找确定要求是应有还是应有的定义的边界？
例如：
在什么时候受影响的人数使本来可以达到？或者，收益的什么价值可以证明将该要求从“应有”降至“可以有”是合理的？
理想情况下，在捕获需求之前就达成此协议。
何时确定优先级
非常重要的一项工作。优先级是在工作开始之前确定的，并且此优先级划分活动的大部分发生在基金会期间。但是，随着工作的完成，应不断审查优先事项。随着新工作的出现，无论是通过引入新需求还是暴露与现有需求相关的意外工作，都必须使用MoSCoW规则来决定其对当前工作成功的重要性。
引入新需求时，应注意不要将“必须拥有”需求工作的百分比增加到超出商定的项目级别。应在整个项目中审查未完成需求的优先级，以确保它们仍然有效。
讨论和审查优先级
根据定义，任何定义为“必须具备”的要求都将对项目的成功产生重大影响。项目经理，业务分析师和解决方案开发团队的任何其他成员应公开讨论优先级为“必须具备”的需求，如果这些需求不是显而易见的必须具备（“如果没有这些，我们将取消项目/增量吗？”）；
由业务有远见者或其授权的业务大使来解释为什么要求是必须具备的。决策流程的升级应尽早达成共识，例如，业务大使，业务分析师，业务远景顾问到业务发起人，以及在每个级别围绕决策制定的授权水平。在项目增量结束时，将根据下一个增量的需求重新排列所有未满足的需求。
这意味着，例如，一个增量中未满足的可能拥有可能会随后被重新分类为下一个增量中的不具备，因为它对满足其纳入业务需求的贡献不足。
但是，如果它在第一个Increment中的低优先级是基于以下事实，则它就很容易成为下一个Increment的必备条件：在第一个Solution Increment中根本不需要它。
使用MoSCoW管理业务期望
MoSCoW规则的定义方式可以确保交付最低可用需求。解决方案开发团队和他们将交付给他们的人都充满了信心，因为“应有”的巨大努力提供了最佳的应变性，以确保“必须拥有”的交付。
当然，业务角色可以期望的不仅仅是交付必备产品。必备物品得到了保证，但对于企业而言，在最困难的情况下，期望在规定的时间内交付的商品超过最低可用补贴是完全合理的。为了保护更重要的需求，DSDM的建议是创建合理的“可能有突发事件”池（通常占项目/增量工作总量的20％），该建议确定了不太重要的需求或如果未交付则影响较小的需求。
这种方法意味着，除了所有必须具备的条件之外，企业还可以合理地预期应该满足应当具有的条件。这也意味着在最佳情况下，还会提供可能的需求。解决方案开发团队没有信心保证所有必须具备，应该具有和可能具有的需求都已交付，即使这些需求已经全部估算并已包含在计划中。这是因为该计划基于早期的估计和尚未进行低级详细分析的需求。
向团队施加压力以确保交付“必须”，“应该”和“可以”会适得其反。它通常导致填充的估计值，给人以错误的成功感。“我们始终实现100％（因为我们为数字增加了很大的偶然性”）。因此，将合理的优先级与时间限制相结合，可以实现投放的可预测性，从而提高信心。这也可以保护所交付解决方案的质量。
保持项目指标以显示每个项目增量或时间框上应有和已完成的百分比，如果事情进展顺利，则可以增强这种信心，或者可以对问题进行早期警告，强调一些重要的（但不是关键的） ）的要求可能无法在项目级别上得到满足。
MoSCoW与业务愿景有何关系
商业赞助商的观点
所有项目的起点都是业务远景。与业务远景相关的是一组优先要求，这些需求有助于实现远景。与业务远景相关的还有一个业务案例，该业务案例根据将为企业带来的价值来描述项目。根据组织的不同，此业务案例可能是非正式的理解，也可能是正式定义的，显示了为证明项目成本合理而预期的投资回报（ROI）。
MoSCoW优先级对于了解最低可用子级和各个要求的重要性是必不可少的。业务远见卓识者必须确保对需求进行优先排序，以业务术语进行评估并按照业务远见提出交付，以提供业务案例所需的ROI。
使MoSCoW工作
从高层战略观点（通常在可行性阶段）到更详细，可实施的层次（通常在渐进式开发阶段），以各种详细级别确定需求。通常可以分解高层次的需求，以产生混合的子需求，然后可以分别对它们进行优先排序。这样可以确保保持灵活性，以便在必要时从交付的解决方案中删除一些较不重要的详细功能，以保护项目截止日期。
正是这种分解可以帮助解决团队经常遇到的问题之一：所有需求似乎都是必须具备的。如果所有需求都是真正的必须具备，则MoSCoW优先级划分所带来的灵活性将不再起作用。
从交付物中删除优先级较低的要求，以确保项目按时和按预算进行。这违背了DSDM固定时间和成本以及灵活使用功能的理念（“哲学和基础知识”一章中的三角形图）。
相信一切都是必须具备的，通常是需求分解不足的征兆。请记住，团队成员可能会通过从事“有趣”的事情而不是重要的事情而引起范围的扩大。MoSCoW可以帮助避免这种情况。
分配优先级的技巧
1.确保业务角色，尤其是业务有远见者和业务分析师，能够充分了解DSDM为何以及如何优先考虑需求。
2.考虑从“没有”开始所有需求，然后说明为什么需要给予更高的优先级。
3.对于提出的每个必备条件，请问：“如果不满足此条件会发生什么？” 如果答案是“取消项目"；实施不满足此要求的解决方案是没有意义的，那确实是必须具备的。如果不是，则决定它是否应该拥有（或可能现在没有）
4.问：“如果我在部署前一天晚上来找您，并告诉您“必须具备”要求存在问题，而我们无法交付，您会停止部署吗？如果答案为“是”，则这是必须具备的要求。如果不是，请确定它应该是还是可以。
5.是否有解决方法，即使它是手动方法也是如此？如果存在解决方法，则它不是必须具备的要求。在确定这是“应有”或“可能有”需求时，请将变通方法的成本与交付该需求的成本进行比较，包括任何相关延迟的成本以及以后（而不是现在）实施该需求的任何额外成本。
6.询问为什么需要此项目和此项目增量的需求。
7.此要求是否取决于其他要求的实现？必需品不能依赖于必需品以外的任何其他物品的交付，因为存在应有或可能不能交付的风险。
8.为需求的接受标准设置不同的优先级。
例如：
“目前的备份程序需要确保可以尽快恢复服务。” 那有多快？只要有足够的时间和金钱，那可能在几秒钟内。一个更聪明的定义是说它应该在四个小时内发生，但是必须在24小时内发生。
9.这个要求可以分解吗？是否有必要交付这些要素中的每一项以满足要求？分解的元素是否具有相同的优先级？
10.将需求与项目目标联系起来。如果目标不是必须拥有的，那么与该目标有关的要求可能也不是。
11.优先级会随时间变化吗？例如，对于初始版本，需求是应有，但对于以后的版本，它将成为必需。
12.使用MoSCoW优先进行测试。
13.使用MoSCoW优先处理您的“待办事项”列表。它可以用于活动和需求。
总结
MoSCoW（这次必须拥有，应该拥有，可以拥有，不会拥有）主要用于对需求进行优先级排序，尽管这种做法在许多其他领域也很有用。在一个典型的项目中，DSDM建议您对项目的“必须具备”要求所做的努力不超过60％，而合理的“可能拥有的需求”通常不超过20％。
任何高于60％的“必须有努力”的工作都会对项目的成功和可预测性构成风险，除非对环境和任何技术有充分的了解，团队必须有良好的团队，并且将外部风险降至最低。