1.10 风险与价值驱动
DAD过程框架采用的是所谓风险—价值驱动的生命周期，实际上是统一过程（UP）所倡导的策略的轻量级版本。DAD团队努力解决常见的项目风险，这些风险包括诸如利益相关者如何就愿景达成共识，在生命周期中如何提早验证架构的正确性等。DAD还明确地包括检查项目的持续生存能力（viability），团队是否已经生产出了充分的功能，团队是否已经做好解决方案的移交准备。DAD也是价值驱动的，其目的是为了降低交付的风险，通过这一策略，DAD团队可以有规律地生产出潜在可利用的解决方案。
有人说“攻击风险先于风险攻击你”。这种哲学与DAD的方法颇为一致。DAD采用所谓的风险—价值共同驱动的生命周期，扩展了常见的价值驱动的方法，例如，它扩展了Scrum和XP中所使用的方法。采用价值驱动的生命周期后，团队在每次迭代中都要生产出潜在可交付的软件，或者，从DAD的角度更准确地讲，团队在每次迭代中都要生产出潜在可利用的解决方案。对于利益相关者来说，团队应该交付需求Backlog中价值最高的功能。在风险—价值驱动的生命周期中，还应考虑把具有风险的功能作为高优先级的条目，而不仅仅只考虑价值高的功能。带着这种想法，只要有可能，我们就应积极而明确地处理常见的IT交付项目风险。价值驱动的生命周期解决了三个重要的风险：最终没有交付的风险、交付错误功能的风险以及由于团队生产进程缺乏可见性而导致的政治性风险。致力于这些风险无疑是良好的开端，但并不等于自己已经有了一个风险缓解的全面规划。
最为基本和重要的是，DAD包含并扩展了标准的敏捷开发方法策略，以降低常见的IT交付风险。
潜在可利用的解决方案。在每个构造迭代中，都要求DAD团队生产出潜在可利用的解决方案，它扩展了Scrum要求在每个迭代中生产潜在可交付的软件的策略，致力于解决可用性（可利用性）方面的问题，以及为了生产出解决方案而不只是软件而面临的更为广泛的问题。这样，交付风险就大大降低了，因为利益相关者可以选择时机，决定是不是要把解决方案发布到生产环境中。
迭代演示。在构造阶段中，当每次迭代结束时，团队应该向关键利益相关者演示他们所构建的功能。主要目的是要从利益相关者那里得到反馈，从而不断改进团队正在开发的解决方案，降低功能性风险。第二个目标是通过展示已完成的工作，表明项目的健康程度，从而减少政治性风险。
利益相关者的积极参与。其基本思想是，利益相关者或其代表（也就是产品负责人）不但要提供信息并及时做出决策，还要积极参与到开发活动本身中去。例如，利益相关者往往可以利用纸和白板等工具参与到建模活动中。利益相关者不只是在演示的时候，而是在整个迭代周期中都应积极参与，这有助于减少交付性风险和功能性风险，原因是他们能利用这些非常好的机会为团队提供有益的反馈。
为了解决IT项目的交付风险，DAD进而对现有的敏捷策略进行了扩展，但同时也引入了明确的轻量级里程碑，从而进一步地降低风险。在每一个里程碑上，由关键利益相关者对项目的可行性进行评估，决定项目是否应该继续进行。在前面的图1.3中，DAD生命周期中显示了以下这些里程碑。
利益相关者达成共识。该里程碑发生在先启阶段结束的时候，其目标是确保项目利益相关者对发布愿景达成合理的共识。即使到目前为止对解决方案只有很少的投资，但由于共识的达成，功能性风险和交付性风险就会大大降低。注意，在现实中经常出现的情况是，利益相关者未能就项目愿景达成一致。根据我们的经验，在这个里程碑上，有多达10%的项目会取消，并且有25%的项目可能在这时才意识到自己所处的环境是可伸缩环境（因此风险更高），而不是其他情形。
架构已验证。在早期的构造阶段迭代中，我们会关注如何降低大部分项目的风险和各种不确定性。项目风险包括许多方面，如需求的不确定性、团队的生产率、业务风险和进度风险。然而，在这里，IT交付项目的主要风险通常会涉及技术，特别是架构级别的技术。尽管在先启阶段中创建了高层次架构模型，这有利于综合而全面地思考系统架构，但要真正让系统架构正确地支持客户的需求，唯一的办法是通过可工作代码来验证。可工作代码可以垂直穿过软件层和硬件层，从端到端触及到体系结构的所有层面。在统一过程（UP）中，这种情形称为“架构覆盖”，在XP中则称为“steel thread”或“tracer bullet”。通过编写软件的方式验证架构的正确性，团队可以在项目的早期发现架构缺陷，并处理它们，这样，DAD团队就能大大减少技术风险和不确定性的源头。
可行性评审。Scrum的想法是，在每个Sprint（迭代）结束时，利益相关者需要考虑项目是否还要继续往前进行。在理论上这是一个好主意，但实际上似乎很少有团队这样做。问题的原因多种多样——例如，由于太多的政治因素，利益相关者不得不做项目终止的决定，但实际上此时的事态并没有真正变糟；再如，典型的敏捷迭代周期都很短，在这样短的时间内，人们在思想上很难注意到项目是否正在逐步陷入困境。言下之意就是，里程碑评审一定要有目的，并要以明确的方式来考虑项目的可行性。我们建议：对于一个既定的发布版本，可以至少做两次这样的评审，例如，对于6个月的项目，每两个月做一次，对于时间较长的项目，最少一季度做一次。
充分的功能。要实现构造阶段的里程碑，意味着团队首先已经完成了解决方案所需要的充分的功能，然后从财务角度来判断，是否合适向生产环境移交该解决方案。解决方案必须满足项目早期所同意的验收标准，或者必须足够接近，这样如果出现关键的质量问题，在移交阶段还有机会及时处理这些问题。
生产环境就绪。在移交阶段结束的时候，关键利益相关者需要决定该方案是否要发布到生产环境中。这个里程碑的目标是，企业利益相关者满意并接受解决方案，运维和支持人员满意相关的支持程式和文档。
利益相关者欣然接受。该解决方案在生产环境中运行，利益相关者表示高兴和满意。
