3.2 Scrum
Scrum作为一种核心敏捷方法，所表达的是非常出色的想法，在如今的敏捷团队中得到了广泛应用。但是，Scrum有意不提供方法指导如何将这些实践应用到框架中，而是由团队自身去发掘哪些实践对这个框架有价值有帮助，并决定是否采用它们。另外，它的重点主要在于敏捷交付的产品构造阶段的方方面面。从图3.2中我们也可以看出，Scrum生命周期重点关注敏捷交付的产品构造阶段。下面列出在DAD过程框架中用到的核心Scrum实践：
产品Backlog（工作项列表）。在Scrum中，产品Backlog是项目中所有预期用户需求和产品功能点的一个优先级排序表。尽管Scrum不要求任何特定的制定需求的方法，但是大多数Scrum从业者都推荐使用用户故事来鼓励团队专注于交付那些真正有价值的功能。Scrum团队通常将需要实现的功能点（或者用户故事）分解为一个个的任务项，而不会依照要实现的新技术、系统配置及测试自动工具的搭建等去单独识别相关的工作项。为了对用户需求进行排序，利益相关者就必须认真分析哪些功能点比其他的更有商业价值。在项目进行过程中，产品Backlog中的任务项可以随时变更或重新排序。
在传统的产品开发模式中，利益相关者会提前细化好所有具体的产品需求，并执行严格的变更管理（更像是“变更预防”）来限制变更的发生。而敏捷团队则不介意对还未开始的任务项进行变更，毕竟这些工作项还没启动，但是我们仍然需要谨慎地处理对产品Backlog中任务项的更改，尤其是大范围的变更。对于比较大的企业，往往会在产品发布规划阶段花大部分的精力去汇编产品Backlog。这些工作项可能和其他项目有依赖关系，而由他们的产品负责人提出来的。请注意，在基本的DAD生命周期中，工作项列表是一个经过排序的工作项目栈，包括产品需求、缺陷报告以及敏捷团队所进行的其他活动。这些活动有些可能是整体解决方案的一部分，但并不仅与软件开发有关，比如，资源安排活动或人员交流活动等。有一点是很明确的，DAD很清楚项目相关的其他工作，以及对其进行排序的重要性，这可以为项目交付提供更高一级的透明度。
价值—驱动的生命周期。在每个Sprint结束时实现潜在可交付的软件（Sprint是Scrum中代表“迭代”的术语，一般建议为一个月或更短的时间）。Scrum，如同其他敏捷方法，强调优先考虑和实施那些能给客户带来最高价值的功能。DAD则采用风险—价值驱动的生命周期，不仅考虑价值高低，还会兼顾所带来的风险后果，其被统一过程（Unified Process）广泛采用，我们会在稍后章节详细介绍相关内容。
每日Scrum（协调会议）。一天一次，通常是在早上，整个团队聚在一起协调当天的工作内容。会议期间，团队成员逐个回答以下三个问题：昨天做了什么？今天准备做什么？有什么事情阻碍进度吗？整个会议耗时不超过15分钟。DAD则稍微更加灵活一些，它建议团队成员首先要解决的主要难题是他们是否预见到任何即将到来的麻烦。前两个Scrum问题虽然可以帮助团队成员相互交流自己所承诺的工作，并公开表示会照着自己的承诺尽职完成相关工作，而当有阻碍出现时，第三个Scrum问题才会派上用场（而用前瞻性提问从最开始就避免阻碍的发生则要好得多）。
发布计划。项目开始阶段，敏捷团队会先拟定一个粗粒度的计划贯穿于整个生命周期中，并适时进行适当的维护。而在传统软件开发模式中，却常常创建过于详细的工作分解计划，并一直沿用到很久之后的将来。然而，这是一个有缺陷的实践，在如今的软件开发项目中根本就行不通。人们无法精确地预测到几个星期后要完成的任务以及所需的时间，这点也正印证了敏捷的团队自组织原则，管理层不应尝试微观管理团队，关心具体任务级别。相反，发布规划建议把项目计划书抽象为描述更高层面的里程碑，比如，以增量方式交付可演示的功能等。而这些高层面计划的项目可以分配到生命周期中的一组Sprint（迭代）之中。需要注意的是，至于Backlog中的哪些工作项真正能够在项目生命周期内实现，Scrum本身是不会做出任何承诺的。只有在项目进行过程中，根据一个个迭代的具体情况来定。当客户认为现有的功能已经足够，并决定不再资助下一个迭代周期时，那就是项目结项的时候到了。在现在的官方Scrum指南中，已经找不到发布规划的内容了，这也是我们所担心的。根据第6章的研究结论，绝对大数的敏捷团队在进行软件开发之前会先进行发布计划。
Sprint计划（迭代计划）。在一个Sprint/迭代的开始阶段，敏捷团队会详细地规划当前Sprint/迭代周期内需要交付的工作项以及要怎么完成这些工作。这就需要从产品Backlog中选出优先级最高的那些用户需求，并将它们分解为具体的任务项，然后团队会对工作量进行估算，并向产品负责人承诺会严格按照自己制定的规划内容按时交付相应的工作。
Sprint评审和演示。此时，团队会给利益相关者演示当前Sprint/迭代周期内所完成的工作，这样利益相关者也会评估一下项目进度是否正常。另外，这也可以是评定是否需要提供额外资金的合理的时间点。
Sprint回顾（回顾会议）。在每个Sprint/迭代周期结束时，敏捷团队都需要利用回顾会议去总结目前有哪些地方做得不足，以及后续哪些地方需要改进。在DAD过程框架中，建议那些对敏捷应用得不是很熟练的团队在每个Sprint/迭代周期结束时开一次回顾会议，而那些成熟的敏捷团队则随时都可以根据自己的需要举行回顾会议（也许在某个Sprint/迭代周期的中段发现了难题，又或者对于一个项目进行很顺利的团队，他们几个Sprint/迭代周期才需要举行一次回顾会议）。但至少，DAD团队需要时不时地考虑是否该举行回顾会议了。
用户故事驱动开发（用法驱动开发）。用户故事通过一到两句话表达客户希望实现哪些功能。一系列用户故事按照优先级高低列在产品Backlog中，为后续Sprint/迭代周期提供参考。值得注意的是，虽然官方的Scrum指南并不包括用户故事，但近几年内，它早已成为实质上的标准。DAD对此则没有过多的规定，而推荐一种叫用法驱动的方式，它更注重于产品的使用方法，比如，用户故事、使用场景或用例等。
