第十五章 通过原型来减少风险
软件原型以试探性方式逐步逼近解决方案。它使需求更加真实，用例更加鲜活，使我们能够进一步理解需求。原型通过对新系统建模或者给用户提供一个粗糙的新系统、激发用户思考并引导出需求。原型方法的早期反馈可以帮助项目干系人对系统需求达成共识，从而减少用户满意度降低的风险。
原型的定义及其动机
软件原型是对提议新产品的部分、可能的或是初步的实现。
>明确、完成以及验证需求
作为一种需求工具，原型能够辅助我们取得共识、查找错误和遗漏以及评估需求的准确性和质量。用户通过对原型进行评估，能够指出需求中存在的问题，还能够发现被忽略的需求，使我们在构建实际产品之前，能够以低成本方式加以改正。
对于系统中不容易理解的或是风险较大或是复杂的部分，原型特别有效。
>探究设计的选择方案
原型用作设计工具，能够使项目干系人探究不同的用户交互技术、设想最终产品、优化系统的易用性以及评估潜在的技术方法。借助于设计方案，原型能够表示需求的可行性。
>创建一个可以演变为成品的部分系统
作为结构化工具，原型是对是部分产品的功能实现，通过一系列小规模的开发周期，它演变为完整的产品。
不必为整个产品创建原型。把重点放在高风险的或已知不确定的功能上
在产品规范说明的编写和设计阶段，原型能够提供实物供他们思考。
对于创建的每个原型，请确保知道并能讲出创建它的原因。
由于有误解的风险，所以在“原型”这个词之前加上一些描述很重要，这可以使项目参与人员明白创建一类或者其他类别原型的原因和时机。本章描述三类原型属性，每一类别又有两个分支。
范围:
实物模型这一类原型重点关注用户体验；概念证明原型探究的是提议方式方法的技术合理性。
未来用途:
一次性（可抛弃型）原型在产生反馈信息以后会被抛弃,演进型原型则通过一系列的迭代发展成为最终产品。
形式:
纸上原型是画在纸上、白板上或者画图工具中的草图。电子原型。
实物模型和概念证明
实物模型经常也称为水平原型。此类原型重点关注 UI。
实物模型意味着它实际上没有实现行为。
实物模型可以展示用户可用的功能选项、用户界面的外观和感觉（颜色、布局、图形、控件）还有导航结构
如果创建演示型模型，请尝试在样例显示和输出中使用真实的数据。
使用抛弃型演示型模型时，用户应该重点关注概要性需求和工作流问题，不要被屏幕元素的确切外观所分散精力。
概念证明也称为“垂直模型”，它在所有技术服务层次上从用户界面实现一部分应用功能。
抛弃型原型和演化性原型
在做原型之前，对于原型是只用于研究实验还是将来要成为最终交付产品的一部分，需要做出一个明确的且经过充分沟通的决定。
在原型上花的精力越大，项目参与人员就越不情愿抛弃它。
千万不可以将可抛弃性原型中的低质量代码移植到产品系统中。
陷阱：不要把可抛弃型原型搞得过于详细、复杂，符合原型目标即可。
与可抛弃型原型相对的是演进型原型。
在构建演化型原型时，一开始就要考虑到健壮性，写产品级质量的代码。
可以把演化型模型的第一轮迭代当作一个实验性版本，实现的是最初的一部分需求。在下一迭代中需要修改的内容可以由用户接收测试以及初次使用反馈来决定。
在软件开发过程中使用原型的一些可能的方法
软件原型的典型应用
| 抛弃型 | 演化型 | |
| 演示型模型 | 澄清与提炼用户需求和功能需求识别被遗漏的功能研究UI方法 | 实现核心用户需求基于优先级实现额外的用户需求实现和优化网站使系统与快速变化的业务需要相适应 |
| 概念证明 | 演示技术的可行性评估性能获得更多知识以提升估算能力 | 实现和扩展核心多层级功能以及通信层实现和优化核心算法性能测试和调优 |
纸上原型和电子原型
纸上原型（有时候也称为低精度原型）能帮助我们探究一个要实现的系统的部分外观，并且它是一种低成本、迅速以及低技术难度的方法。
纸上原型能帮助检查对需求是否达成了一致的理解。
以试探性的低风险方式来逼近可能的解决方案。
使用低精度原型来探究功能和流程，而使用高精度原型来确定具体的样式和外观。
注意避免过早涉及详细的UI设计。
在确信已经充分理解必要功能需求之前，要将原型目标定位在提炼需求上，而不是视觉设计上。
原型的使用
对这些操作和响应进行建模，可以用对话图来描述一个可能的UI架构。
需求提炼以及屏幕草图画好以后，就可以对每个UI元素进行易用性方面的优化。
使用抛弃型原型从用例到用户交互设计过程中的活动顺序
原型的评估
原型评估与易用性测试相关。
>原型实现的功能符合您的预期吗？
>原型中有没有遗漏掉的功能？
>有没有您能想到但原型中没有处理到的可能错误的状态？
>有多余的功能吗？
>对您而言，这些导航的逻辑性和完整性如何？
>对于每个需要很多交互步骤的任务，有没有简化方法？
>是否有不确定下一步该做什么的时候？
原型评估中获得的信息要记录下来。
缺少思路的决策常常导致事后需要重复思考其产生的原因和过程。
对于概念证明，要记下评估过程及其结果，从探究过的所有技术方案中做出最佳选择。
将指定需求与原型之间不一致的冲突找出来并加以解决。
原型风险
原型发布的压力
最大的风险是项目干系人会看到一个可以运行的可抛弃原型，从而得出产品几近完成的结论。
对客户预期进行管理是原型成功的关键。每个关注原型的人都要理解原型的目的及其局限性。要清楚创建原型的原因。
让看到原型的所有人都明白它将来不会作为产品软件发布。
评估纸上原型的人不会产生产品几近成品的想法。
让原型看起来简陋一些,也可以降低这种风险。
受细节所累
用户把注意力放在与UI有关的外观和操作细节上。
不现实的性能预期
第三个风险是用户根据原型的性能来推断最终产品的预期性能。不要在预期产品环境中对原型进行评估。
对原型投入过多
对整个解决方案进行建模而不是只对最不确定的、高风险的或者复杂的部分进行建模。
如果原型能够测试假设，能够回答问题并且能够提炼需求，就足够了。
原型成功的因素
请遵循以下这些原则：
>在项目计划中包含与原型相关的任务。
>在创建原型之前，注明原型的目的并解释其最终产出。保证创建和评估原型的人都明白这些动机。
>做好开发多个原型的计划。
>创建可抛弃型原型，要尽可能快、成本低。
>不要在可抛弃型原型中包含输入数据验证、防护性编码技术处理错误代码或大量的代码文档。
>不要对已经理解的需求创建原型，除非需要探究其他设计方案。
>在原型的屏幕显示和报表中，使用合理的数据。
>不要指望原型来替代书面需求。
第十六章 设定需求优先级
每个资源有限的项目都需要对必要的产品功能定义相对优先级。进行优先级排序，也称为“需求甄选”，有利于发现有矛盾的目标、解决冲突、进行阶段性计划或者增量交付、控制范围蠕变以及经过必要的权衡来做决策。
为什么要排优先级
需要保证产品能够尽快交付最关键或着量有价值的功能。排优先级能够解决有限资源与大量需求之间的矛盾。
项目经理必须合理权衡预期项目范围和计划、预算、人员和质量目标等约束。
排优先级是一个动态的、持续进行的过程。
优先级排序实践
排优先级需要各类干系人参与。
想得到正确的优先级排序，需要理解下面六个问题：
>客户的需求
>需求对客户的相对重要程度
>功能需要交付的时间
>作为其他需求之前提的需求以及各需求之间的其他关系
>哪些需求必须放在一起实现
>满足每个需求所需要的成本
成功流程的同时，还必须实现相应的异常处理。
人与优先级之间的博弈
为了鼓励客户承认某些需求具有低优先级，分析师可以提出下面几个问题：
>是否可以通过其他途径来满足对此需求的需要？
>如果去掉或者延后此需求，会有怎样的结果？
>如果该需求在几个月内都不实现，会对项目的业务目标有怎样的影响？
>如果此需求被延到后续的版本，客户会不会不高兴？
>是否值得为了这个特性而延迟发布其他具有相同优先级的特性？
评估优先级时，要了解需求之间的连接和内在联系，及其是否与项目业务目标相匹配。
确定优先级的技术
优先级最高的需求提供最大比例的产品总价值以及最小比例的总成本。
三层分级法
MoSCoW
在MoSCoW优先级排序法中，四个大写字母代表在一个需求集合中四类可能的优先级类别。
Must（必做）：需求必须满足，只有这样，解决方案才会被认为是成功的。
Should（应做）：需求很重要，并且如果可能，应当包含到解决方案中，但对于成功不是强制性的。
Could（可做）：想要但是可以推迟或者清除。只有当时间和资源都允许的时候才实现。
Won’t（不做）：表示这次不实现，但可能包含到未来的版本中。
MoSCoW 方法将高、中、低三个级别变成四个级别。但对于如何通过比较其他需求来评级给定需求的优先级，MoSCoW 并没有给出相关的依据。MoSCoW 不关注时间，特别是需求被评定为“Won’t”时。
根据价值、成本和风险排优先级
想将客户价值与提议的产品特性关联起来，可以使用一种称为品质功能展开法（Quality Function Deployment,QFD，Cohen 1995）的方法，这是一种明确而严谨的方法。
排优先级的过程中，要包括以下几类典型的参与者：
>项目经理或者业务分析师，由他们来引导这个过程，裁决冲突，并且在必要的时候调整从其他参与者那里收到的优先级数据。
>客户代表，比如产品代言人、产品经理或者产品负责人，要他们对收益和损失进行打分。
>开发代表，要他们对成本和风险进行打分。
遵循下面的步骤：
1.在电子表格中列出所有想要进行优先级排序的特性、用例、用例流程和用户故事或者功能需求。所有需要分析的需求必须具有相同的抽象等级。
2.对于要提供给客户或业务的特性，让客户代表估算每个特性的相对收益。这些收益得分可以表明这些特性与产品业务目标的匹配程度。
3.估算相对损失，即特性未加入而对客户或者业务带来的伤害程度。
4.将收益和损失分数相加，计算出每个特性的总价值。
5.让开发人员估算实现每个特性的相对成本。
6.同样，开发人员要对每个特性的相对的技术风险（非业务风险）进行打分。技术风险是指在首次尝试中无法实现特性的可能性。
7.计算优先级：公式： 优先级=价值%/（成本%+风险%）。
8.根据优先级，进行降序排列。
这个优先级模型的有效性受限于团队对各项收益、损失、成本和风险的估算能力。
QFD例表：
