一、评估价值
业务价值可以通过商业论证进行评估，通常会通过常用的财务术语进行评估。商业论证开发是敏捷项目管理中重要的起步点。商业论证是对项目的构想、目标、达到目的的策略、重大事件、所需投资和预期回收所做的简明概要文件。商业论证向客户阐明了该项目为什么以及怎样带来价值。
对于商业项目，价值通常使用如投资回报率(ROI)、内部回报率(IRR)、净现值(NPV)和回收期来评估。投资回报率、内部收益率和净现值是本领域的工具和技术，考试中会考察队这些概念的理解，比如用这些概念来衡量项目选择，进行项目的成本效益分析。
(一)、投资回报率
投资回报率(return of investment ,ROI) 是项目产品运行所产生的年度(或平均)利润与项目投资额之比，至少大于0，才值得投资
(二)、内部收益率
内部收益率(internal rate of return ,IRR) 是用来衡量和对比投资收益率的经济指标。内部收益率是项目现金流入量现值等于项目现金流出量现值时的折现率，即NPV=0的折现率，相当于项目存续期内项目内部收回投资每年的净收益率。内部收益率越高越好。
其判断准则为：
IRR>=0，项目可接受(0=市场利率)
IRR<0，项目不可接受
内部收益率通常不能直接计算出来，需要采用插值法或者试错法得到。
(三)、净现值
净现值(net present value，NPV) 考虑存在风险(如通货膨胀、政治安定等)的情况下把项目所有预期的未来现金流入与流出都折现成现值，以计算一个项目预期的净货币收益与损失。
NPV=收入现值-支出现值，包含对风险、时间、现金三者的衡量：
- NPV>=0，项目可接受
- NPV<0，项目不可接受
NPV越大越好
二、规划价值
当项目被选定后，我们需要思考如果在项目规划期间秉承价值驱动交付的理念。根据业务价值来排序项目工作的优先级，并将最高优先级的工作排在待办事项的顶部。执行项目工作时，优先选择顶端的工作项进行。在项目进行过重成，需求变更和缺陷修复也会依据业务价值或者重要性纳入到待办事项中一并排序。
(一) 项目章程
项目章程是重要的文件，需要相关干系人的参与，在敏捷项目中也是必需的文档，一般不可裁剪。
敏捷项目中的章程和<PMBOK指南>中的项目章程总体目标一样，只是详细程序和假设条件会有一些差别。敏捷项目章程的目的也是高层级的描述，用于获取项目的5W1H(什么、为什么、谁、什么时候、哪里和如何)属性的共识，并授权项目工作的开展。项目章程中应包含3个关键信息：
- 愿景：即项目发起的原因，是"为什么(why)"。
- 任务：即项目的内容，是"什么(what)，阐述团队为实现愿景需要做的内容"
- 成功标准：即管理的指标，定义项目"如何"(how)是成功，用于验收项目。
但是，由于敏捷方法本身就是为了应对需求和项目的不确定，因此对于敏捷项目的范围一般很少详细定义，它会随着项目的进行而变化，所以，敏捷项目章程通常比传统项目粗略，章程包含的内容相对较少。敏捷章程更多聚焦在项目如何运行，而不是具体将要做什么。对于静态的项目(需求在执行期间很少变更)适合先规划，并且规划的越多越好，然后执行。由于动态的项目(需求再项目执行期间会变更，更多可以理解为适应型生命周期模型，即敏捷)，没有静态目标，对于过度规划可能会徒劳无功，反而造成规划工作的浪费。
敏捷方法中的很多做法和传统瀑布中的做法可能不一样，比如变更的批准流程及批准后的变更如何加入到待办事项并设定优先级等都需要在项目章程中清晰定义。
(二) 价值流向图
价值流向图可以用于分析信息或者材料的流动，从初始到结束，用来识别浪费的环节。识别出的环节即成为流程改进的地方。
一张价值流程图通常由团队共同制作，这样团队可以一起定义和查看整个流程，之处流程内的浪费环节。增加价值的流程(特性的流程)通常称为"增值"，不增加价值的流程(等待)通常称为"非增值"。项目希望最大限度的减少非增值时间(即浪费环节)。
执行价值流程图大致包括以下五个步骤：
- 1、识别你要分析的产品和服务(即流程的起始点)
- 2、创建当前流程的价值流程图，识别步骤、序列、延迟和信息流
- 3、评审流程图，发现延迟、浪费和限制约束
- 4、为未来的流程创建新的价值流，通过移除或者降低延迟、减少浪费和闲置约束等方法优化此流程。
- 5、开发一张用来创建被优化后状态的地图
- 6、流程改进以达到目标
(三) 客户价值优先级
客户价值优先级关注 应该尽快开始才能给客户产生最高价值的工作。这项技术旨在让客户参与到优先级流程中来。在这个过程中，团队可以识别出高价值的特性并将其加入到待办事项中。对于团队来说，优先级非常重要，能够使团队在保证最小可销售功能的有用功能结合的前提下调整项目范围，以适应项目预算和时间要求。
客户价值优先级的理念贯穿敏捷方法的始终。在不同的敏捷实践中术语也不同。例如，它在Scrum中是"产品待办事项"，在FDD中是"特性列表"，在DSDM中是"设定优先级的需求列表"，但其核心理念是相同的。项目通过优先级列表中的工作来产生价值。
1、优先级常用的模式
团队应该依据项目需求和所在组织的特点来选择优先级模式，一些常用的优先级模式如下：
- 简单模式
- MoSCoW
- 虚拟价值
- 卡诺分析
- 需求优先级
(1)、简单模式
它是一种最简单的优先级模式，通常会在工作项上标上P1、P2、P3等。尽管这种模式很直接，但是如果人们趋向于把所有工作都标记为P1，这将会产生问题。如果大多工作项被标注为P1，该模式就会变得非常低效，好比都是重点就等于没有重点。业务代表很少会将一个特性标注为P2、P3，因为他们知道低的优先级的工作会存在被移除项目范围的风险。同理，高等、中等、低等的优先级模式都存在同样的问题。若不能对什么是高优先级达成共识，最终将会因为高优先级列表中有太多工作项而失去价值的排序的意义。
(2)、MoSCoW
MoSCoW技术通常使用在敏捷排序用户故事的优先排序中，起源于如下几种叫法的首字母。MoSCoW技术把用户故事以降序方式进行优先顺序排列：
- M-must have，即必须有的；“必须有的”需求和特性是系统的必要组成部分，是对开发很重要的产品特征，没有这些系统将不能正常工作或者不能增加价值。
- S-should have，即应该有的；“应该有的” 特定也非常重要，对开发不是很重要但有重要的商业价值的特征。如果缺少这些特性，解决方法会变得繁琐或昂贵。
- C-could hava，即可能有的；“可能有的” 特性增加一些商业价值的产品特征。
- W-won‘t have this time，即希望有的，这次不会有；“希望有的，这次不会有”的特性指的的是这个功能虽然不错，但不是必需的需求，带有一点商业价值的产品特性。
(3)、虚拟价值
通常这种方法在敏捷实践中比较常用，也比较有效。它通过给发起人等同于项目预算的虚拟货币，要求他们将这些虚拟货币分配给系统的特性集，这些特性可能是全部项目范围，也可能是部分的范围。
这种方法对于识别系统组件的一般优先级非常有用，但是如果当人们开始询问一些不太有价值的活动诸如文档等时，这种模式就容易发生偏离。虚拟货币技术在限制业务价值特性的优先级排序中最有效率。
(4)、100点法
分给每个干系人100点，他们可以使用这些点给最重要的需求投票。干系人可以将100点以任意方式分配：40点给A需求，20点给B需求；当然，如果干系人只需关注某个需求，并认为这个需求优先级最高，也可以把100点都投给这一需求。
(5)、卡诺分析
卡诺分析是由狩野纪召(Noriaki Kano) 在1980年发明的，也可以用作优先级模型。这种技术可以将客户的喜好分为4个类别：惊喜、满意、不满意、无关紧要。这些分类可以帮助团队更好地理解与客户满意度相关的需求。卡诺分析还有助于在关于特性的问题上设定上下文并建立发布计划，来推送客户满意度的提醒
接下来，我们详细解析每一个分类。
- 惊喜属性：
有时候称为魅力属性。这些特性的交付是客户未预料到的、与众不同的或者可以带来高价值的好处，可能给客户带来竞争力和高满意度。例如，客户端需要你做一个会议记录，传统方法是采用文字格式，而你采用了视觉记录的方式。- 满意属性：
作为满意的特性，越多越好。这些特性会给客户带来价值、创造竞争优势，大部分的竞争都聚焦在这个属性的领域。例如，一个有用的查找功能可能会让客户感到满意。- 不满意属性：
这些必须具备，如果这些特性不具备，客户就不会喜欢这个产品，但是即使这些特性存在，也不会提升客户的满意度。例如，系统中的修改密码就是一个必备特性- 无关紧要属性：
这些特性无论从哪方面来说对客户都没有影响。因为客户对对其根本就不关心，我们应该尝试这消除、最小化或者延迟交付这些特性，比如一个外部很漂亮的电脑硬盘。
(6)、需求优先级
需求优先级由 卡尔 魏格思(Karl Wiegers) 创建，相比以上模式，是一种在数学上更严谨的计算方法。使用这种方法，每个特性的益处、坏处、成本和风险多会被从1(最低)到9(最高)标注起来。客户根据益处和坏处来评估是否包含该特性，开发者根据开发的成本和实现的风险来评估该特性。所有特性都会带入到一个加权基准中计算其相对优先级。
2、相对优先级/排序
不管使用哪一种优先级模式，我们更应该关注最终目的是为理解产品特性的优先级。有时，花费过多的精力在判断使用哪一种优先级模式上反而会降低我们对于优先级本身的更有意义的讨论。因此，最好让业务人员按照优先级排序列出所有产品特性。必须要按照1、2、3进行分类，也不需要使用高、中、低优先级，不需要MoSCoW。简单的优先级排序可以移除固定下来的分类，聚焦在优先级上，如下图：
在上图中，产品特性根据优先级进行排序。在清单上面的条目，产品特性是A~E是最先可销售发布的一部分。如果为了满足预算和进度需要、剪切范围，很明显，应该调整条目F。
相对优先级排序亦提供了一个需求决策框架。当需求变更时，团队可以问业务代表："哪一个工作项比这次变更重要"。然后，新的变更项会被插入到已排好优先级的工作列表的合适位置上，如下所示：
尽管敏捷方法在后期的变更方面提供了极大的灵活性，但也需要遵循时间和空间的规律。因此，如果当前项目时间和预算被全面用完，新的变更将不可避免地迫使低优先级的产品特性下降到期望交付的临界值以下。因此，我们可以接收项目晚期的变更，但是这些变更可能会导致低优先级的工作条目被取消。
单一的排好优先级的工作清单对于简化所有未完成的工作非常有用；相对于细分的分别代表更变请求、缺陷修复和新的需求列表，单一优先级的列表结合所有这些工作项给所有人一个关于项目的待办事项的更清晰、更完整的视角。当开始采用敏捷方法时，许多团队不明白这一点，相反，他们更倾向于保留分裂的缺陷修复和新需求的清单，这种分类会降低我们团队的速率。一个简单的优先级清单列表会更加透明和容易控制，因为相对优先级会清晰地显示在优先级清单列表中。
尽管多数人支持使用简单优先级列表，但是没有一种绝对的最好方法去适用所有项目的产品特性优先级排序。不管你使用哪一种方法，诊断在优先级排序过程中遇到的所有问题，遇到"缺少参与"或者"太多P1 优先级的产品特性"等问题时，尝试使用不同的方法，如使用虚拟货币、MoSCow优先级模式或者简单优先级列表，通过配合新的方法去解决这些问题。我们的目标就是为了真正的理解如果排列产品特性优先级而不是简单地用标签将他们进行分类。此时，我们得到的需求优先级列表可以根据需要随时进行再讨论和重新排列优先级，具有一定的灵活性。这个灵活性可以帮助我们在可用的时间和预算下交付最高价值产品特性集合。
(四) 产品路线图
产品线路图是关于产品发布和产品主要组件的可视化概述，是一个可以提供给干系人快速查看主要发布点和该发布点计划功能的沟通工具。通常，我们选择使用杰夫 帕顿(Jeff Patton)推广的故事地图描述产品地图。
(五) 风险待办事项
风险是一个不确定的时间，一旦发生可能会影响到项目。大多数风险管理更专注与对项目产生消极影响或者威胁事件，但是<PMBOK指南>中明确说明，风险也包括好的方面，被称之为机会，消极的风险则被称为威胁。
在敏捷中，消极的风险也等同于反价值。如果风险发生了，就需要花费事件和资源去对应，同时也会威胁到项目的利益。因此，我们不仅要尽早规划交付高价值的特性，也应该尽早规划风险规避以及转移的举措。
项目管理的本质是风险管理。风险管理并非只适用于传统过程驱动的瀑布项目管理，当项目采用敏捷运作时，项目级的持续集成和短迭代交付本身已经成为项目风险应对的最佳实践，对于快速识别风险和减低风险非常有效。根据项目需求，可以采用<PMBOK指南>中常规敏捷风险管理方法论。
基于风险的小试验是风险管理的一个技能，通过被看作一项任务。一个以风险为基础的探测是一项用于在不确定领域获取知识以降低风险的任务。
敏捷项目不断进行迭代，在前期进行高风险处理，让高风险早曝光，这样风险应对成本相对最低，同时也降低了在之后阶段无效工作投入的可能性。敏捷项目是业务价值和风险驱动的组合。
所有的敏捷项目都是业务价值和风险共同组成的，依据产品特性和高风险条目来选择工作项。如果项目的用户故事存在残余风险，可以将这些风险的工作项转移到最高上面并在合适的时候开始。依据业务优先级和风险等级可以对需求进行主观排序。从客户的角度出发，项目可以聚焦于每个产品特性的投资回报率从而进行排序。业务代表将产品特性按照价值分类后，会得到一个包含投资回报率价值并按照优先级排序的产品特性列表。同时可以使用预期货币价值(EMV)的方法将所有风险进行货币化。
(五) 敏捷合同
时间、预算和成本估算是敏捷中重要的知识和技能。由于敏捷接受变动的范围，敏捷方法的本质意味着它为固定的预算和进度提供良好的支持，但变动的范围使总成本的估算更艰难。这些问题从敏捷方法创建以来就一直存在。业界也在投入很多努力用以解决这个问题。1994年，第一版的DSDM手册就介绍了转换三角模型。如下图
敏捷项目尝试固定资源和时间(成本的主要花费部分)。通过调整功能来达到在这些约束下产生更高优先级和更高质量的产品。敏捷方法和敏捷合同的的目标是让项目团队和客户合作更加紧密。这种合作可以改变项目团队的努力方向，从而给客户交付增加价值的产品特性。这个目标在敏捷的第三条宣言——"客户合作胜过合同谈判"中也有提现敏捷方法比传统方法更多的信任，但是该方法更专注于把资源用于正在开发的事项上，而不是让团队陷入关于变更如何协商或者标准如何定义分歧中。
敏捷也要求业务更加积极地参与迭代反馈，对待办事项重新设定优先级，并评估变更的需求和剩余工作项的价值。对于比较信任的客户，敏捷合同是一个非常好的工具，能创造更多的价值，并给客户带来竞争优势。对于不信任或者不参与的客户，敏捷合同可能很难执行或者根本不适合。
