3.7 IBM实践
IBM为软件开发实践集合的整理和编写做出了巨大的贡献（而且必将继续下去），这些实践包括关注敏捷交付的最佳实践。通过Rational Method Composer（RMC），敏捷团队可以很方便地根据自身所处的情形去裁剪这些IBM实践以帮助自己走出困境。IBM实践的目的在于提供可供敏捷团队创建流程的构建模块。而且事实上，IBM已经定义了一些流程和方法，如开放统一过程（OpenUP）、Eclipse Way和Harmony/ESW等。IBM的客户则可以对这些实践和方法进行适当的裁剪，然后开发出适合自己的一套流程。
下面列出的只是IBM实践集合中所包含的迭代和/或敏捷实践的一部分。
并行测试（全团队测试）。开发团队应该在进行其他开发活动的同时，尽自己最大能力做好相关的测试。
持续集成。请参考前面章节所介绍的XP实践的相关内容。
演进型架构。在生命周期的早期预想系统的架构，在项目的早期阶段通过系统代码来验证架构，并且允许具体细节随着时间的推移而不断改进。在DAD过程框架中，来自于敏捷建模的一些更细粒度的实践则共同组成了“演进型架构”这一实践。
演进型设计。设计会随着时间而发展，为此，敏捷团队需要进行迭代建模、即时（JIT）模型风暴、测试驱动开发（TDD）以及其他活动来相互沟通并做出设计决策。在DAD过程框架中，来自于敏捷建模的一些更细粒度的实践则共同组成了“演进型设计”这一实践。
迭代开发。以增量方式创建解决方案，其中完成每个增量所需的一段固定的时间被称为迭代。每次迭代都需要在最开始的时候做详细的规划，然后完成相应的工作，并在迭代结束的时候，也即工作成果比较成熟的时候，向利益相关者演示所交付的功能。在DAD过程框架中，来自于Scrum的一些更细粒度的实践共同组成了“迭代开发”这一实践。
发布计划。在项目的开始阶段，高层次计划列出关键的里程碑、对其他团队的依赖项以及每个迭代的周期和时间点。在整个项目的进行过程中，该计划需要根据团队实际的进度和活动需要不断更新。
风险—价值驱动的生命周期。在基于价值的生命周期内，我们定期开发出可利用的解决方案，并可能将其部署到生产环境中。使用这种方法的特点是，我们根据功能特性自身能给客户带来价值的高低来对其进行优先级排序。而基于风险—价值的生命周期则在此基础上进行了相应的延伸，致力于解决基于商业价值的生命周期所未能降低的风险。这些风险包括：在生命周期的开始阶段，针对要交付哪些功能，获得利益相关者的共识；在生命周期的开始阶段，通过系统代码来验证架构；直到在部署到生产环境上之前（但非更长时间之前）至少有一个可推向市场的发布版本；并且确保解决方案在部署到生产环境中之前已经真正就绪。言下之意，为了提高团队项目成功的概率，在给工作项设置优先级时需要将风险考虑进去。
共享愿景。在项目的开始阶段，应该定义好项目的整体愿景，在团队内部进行充分的沟通，并达成一致。
项目变更管理（工作项列表）。任何项目变更请求，包括报告的软件缺陷，应该经由团队评估，由利益相关者确定优先级，并根据优先级高低顺序逐一解决。
测试驱动开发（TDD）。请参考前面章节所介绍的XP实践的相关内容。
用例驱动开发。用例就是一系列行动，为利益相关者（一个人、组织甚至其他系统）提供可度量的价值。用例的编写原则就是将用户需求转化成那些描述用户和系统之间交互的工作流。用例驱动开发方式则将相应的使用场景分配到特定的迭代周期内去实现。
用户故事驱动开发。用户故事是用户需求的高层面描述，只需包含足够的信息，以便开发人员可以对实现它所需的工作量进行一个合理的估计。用户故事并不是实际需求本身，而是在真正实现之前，与产品负责人讨论时的一个占位符号而已。用户故事驱动开发方法则将相应的用户故事分配特定的迭代周期以实现。
完整团队。请参考前面章节所介绍的XP实践的相关内容。
为什么需要粗粒度的实践呢
IBM实践通常比我们目前为止所介绍的很多实践的粒度都要更粗一些。比如，Scrum所包含的Sprint演示、Sprint规划和Sprint回顾这几个实践，对于IBM实践，则合并成一个：迭代开发。IBM之所以这么做，是因为他们发现许多小的实践其实是一体化的，而且通常都部署在一起，所以将这样的多个细粒度实践合并成一个粗粒度实践合情合理。另外一个有趣的现象是，某些敏捷方法的忠实拥护者也确实坚持认为，要想真正从某个敏捷方法中受益，就必须采用该敏捷方法的一整套核心实践。
