改进软件经济学——达到规模化敏捷的头10条原则

从软件开发到软件交付

世界正在日益依赖于软件的交付效率――特别是改善经济产出的软件。软件生产更多涉及经济学而不是工程学。在过去的25年，IBM的Rational团队和数百家软件组织结成伙伴关系，参与了数千个软件项目。我们的使命是双重的：首先，为顾客带来软件最佳实践，其次，直接参与他们的项目，学习成功和失败的模式，这样就可以辨别哪一种实践是最佳的，以及为什么它是最佳的。Rational团队没有发明迭代式开发、面向对象设计、UML、敏捷方法，或者IBM®Rational®统一过程捕获的最佳实践，我们只是吸取了行业的成功经验。

大多数依赖于软件的组织正在努力把它们的生命期模型从开发聚焦转到交付聚焦。这个用词上的微妙差别表达了驱动管理哲学和治理模型的原则正在剧烈变化。也就是说，面向“软件开发”聚焦于开发过程中所需要的各个活动，而面向“软件交付”聚焦于过程的结果。传统工程治理和经济驱动治理的区别如下表。

软件开发：工程驱动	软件交付:经济学驱动
明确的开发阶段	持续演化系统
从开发团队到维护团队，有明确的交付物	共同的过程、平台和开发维护团队
从需求到设计到编码到测试到运作，有清楚的、顺序的活动	可用的能力序列，而且不断增值
阶段和角色特定的过程和工具	协作平台，集成了定制的工具和过程
共处一地的团队	地理上分布，基于Web的协作
有完整计划和需求，强调早期精确，	随着不确定性的解决，演化精确
通过度量工件生产和活动完成来治理	通过度量增量产出和进度/质量趋势来治理
精确完整地定义需求/计划，针对静态的计划和范围跟踪进度	减少不确定性，管理差异，度量趋势，通过持续协商目标来调整航向

比起使用象桥梁建造那样的传统工程项目技能，软件开发更类似于电影制作。大多数软件专业人员没有物理、材料性质上的限制来约束他们的问题或者解决方案，他们只受限于人类的想象力。软件产品的质量度量没有公认的原子单位。可能除了可靠性之外，大多数质量判断都是非常主观的，更象是选美，而不是精确的数学和物理计算。

当前各种软件生命期模型使用了许多不同的术语，例如:螺旋式开发、增量开发、演化式开发、迭代式开发和敏捷开发。这些模型在思想上有许多东西是共同的：反瀑布开发。

IBM是结对编程和极限编程等敏捷技能的先锋之一，我们现在有一个有活力的技术社群，成千上万的实践者加入其中。这些年，我们致力于把敏捷咨询和过程成熟度咨询统一起来。这两者都有管用的技能，内在精神是一致的，但带着不同的行话和偏见来解决同样的问题。这里没有绝对的对和错，关键是上下文和规模，每一个项目或组织都需要混合的技能、过程变体、常识和领域经验。

迭代式软件管理的头10条原则

在1990年代，Rational软件公司开始演化一个现代过程框架，更加形式地捕获迭代式开发的最佳实践。我们的首要目标是帮助行业从“计划和跟踪”管理风格(瀑布模型)迁移到承认需求、设计和计划不确定性的“掌舵”领导风格。

以下是从1990年代到2000年代早期，我的头10条迭代式开发原则:

1.基于架构先行方法的过程.

2.建立及早遭遇风险的迭代生命期过程.

3.把设计方法迁移到强调基于组件的开发.

4.建立一个变更管理环境.

5.通过支持双向工程的工具提升变更自由.

6.以严格、基于模型的表示法捕获设计工件.

7.调整过程以得到客观的质量控制和进度评估.

8.使用基于展示的方法来评价中间工件.

9.根据演化详细级别将使用场景分组，来计划中间的发布.

10.建立一个经济上可伸缩的可配置过程.架构先行的方法强迫让集成进入设计阶段，在那里，大多数重大的不确定性得以暴露和解决。早期的展示没有消除设计断裂，只是使它发生在可以高效解决的时候。下游的废料和返工大大减少，得到更加健壮和可维护的设计。中期的里程碑提供看得见摸得着的结果。设计现在是“有罪推定”的，直到展示目的达到之前，项目不会前移。而度量理念体系也从瀑布模型中对活动做度量，迁移到迭代模型中对可执行发布中的废料和返工趋势做度量。

达到“规模化敏捷”:敏捷软件交付的头10条原则

经历了十年的迭代式开发，我们用从几百个项目里积累的经验更新了管理原则，将其更新到更先进的敏捷软件交付经济学科。以下是为了使得敏捷软件交付成功，我建议的头10条原则。

1.先做出架构密切相关的决策，以减少不确定性.

2.建立自适应的生命期过程，进一步减少变异.

3.通过资产复用和中间件，减少定制开发的数量。

4.调节过程以度量变更成本、质量趋势和进度趋势.

5.和所有涉众诚实沟通进展和阻碍.

6.定期和涉众协作，重新协商优先级、范围、资源和计划.

7.在演化宽度和深度上持续集成发布和测试使用场景.

8.建立协作平台，提升潜在分布团队的团队协作

9.通过自动化提升变更计划、范围和代码发布的自由度.

10.建立保证参与人员创造自由的治理模型.

需要组合探索、生产、评估以及掌舵式的领导风格，才能做到以可预测、有利润的方式成功交付软件产品。“掌舵”一词意味着积极参与管理，并且频繁修正路线来产生更好的结果。所有涉众必须协作，会猎移动的猎物，以上的原则刻画了达到良好掌舵机制所必需的经济基础。从这些原则和实践经验可以得出三个重要的结论，如下图所示。

下图提供了这个重要度量模式的另一个例子。这个图所展示了质量度量有形的演化(在这个例子中，即嵌入大规模命令和控制系统中的软件展示的MTBF，即平均无故障时间)。然而，传统过程不得不在大多数生命期随机地处理这个关键的性能需求，使用了现代敏捷交付方法的项目在达到这个需求时，在项目进度的足够早期消除了不确定性，团队可以高效地折衷剩余的资源，投资来追求更好的运行时性能，添加功能，或者改进系统交付的利润。这样对所有涉众来说都有重大的经济影响力。

IBM，特别是Rational，将继续致力于研究和实践软件经济治理更先进的知识，以便我们的顾客可以利用成熟的敏捷软件交付业务过程。