关于软件管理过程,目前敏捷过程最为热门。主要的敏捷过程有以下几种:XP 极限编程, SCRUM, FDD 特征驱动开发, DDD 领域建模驱动开发, ICONIX, ASD 自适应, CRYSTAL 水晶, DSDM, TDD 测试驱动开发, AMDD 敏捷建模。再加上“传统”的RUP。
浏览这些过程会发现这些敏捷过程所涉及的领域还是有所区别的。简单来讲,可以粗略的划分为管理过程和设计过程。例如:
- SCRUM:很明显是管理过程。在实践框架中提供了一些可以明确执行的实践指南。而其中对于设计方法或者过程基本没有什么要求。
- FDD:应该属于管理过程。其中明确了对项目的进行如何规划。而对设计方法所述比较少。
- ASD, CRYSTAL:属于管理过程,其中重点讨论对人的管理理念。管理框架具有很大的灵活性。
- DDD:属于设计过程,重点描述如何从业务需求导出到系统设计编码的过程。
- AMDD:属于设计过程。
- XP:比较特殊,不是完整的管理体系。而对设计过程也很少描述,仅仅提供了一些最佳实践。由于其要求非常明确,所以我觉得更接近与设计过程。
- TDD:应该不算是过程,仅仅是一种辅助设计的方法。所以经常被其它敏捷过程所引用。
- ICONIX:对管理过程与设计过程都有所涉及。不过更加接近于设计过程。
- DSDM:不太了解,无法分类。
不过这也侧面说明,这些敏捷过程往往内容都不够完整,或者说是针对性比较强。
现 在看来,敏捷过程的宣传者针对的往往是一些传统的重型过程,如CMM, ISO等等。而由于RUP内容比较复杂,所以往往也被算进来。这其实是由于对RUP的误解造成的。RUP被设计为统一过程,所以必然包罗万象,以便适应于 更多类型的项目。这就造成了RUP的复杂性,其实也说明了RUP内容的丰富。但是,当具体到某一个项目的时候,必然会根据项目特点或者企业环境因素对 RUP过程进行裁剪,以形成特色的过程。所以针对小型项目,RUP完全可能变成为非常“敏捷”的过程。
不过这也属于一个矛盾:1. 对于小型项目的项目经理来讲基本没有精力或者经验对整个RUP体系进行完整的研究。2. 如果缺乏对RUP体系的研究,就不可能对RUP体系进行恰当的裁剪。
基于这个矛盾,出现了很多伪RUP过程实践。
这样的现象是因为RUP中缺乏对一些比较典型的项目类型的具体指导和模版,来使项目经理可以快速的对RUP开始实践。而在这方面敏捷过程往往做得更好。例如XP过程,提出了明确的原则和实践指南,使得人可以非常简单清晰的学习和实践练习。
基于此,例如XP这样的过程就在程序员中很受欢迎,因为程序员多数项目管理经验不够充足,所有如果有简单而明确的实践规则的话,当然更容易付诸实施。
但 反过来讲,这些敏捷过程对项目类型的要求往往非常严格,例如,XP过程就会要求:项目组规模、办公地点、用户现场、合同类型等等。所以当人们将它应用与不 同的领域时又不得不对它进行改良或者采用其它的软件过程。在这方面RUP就会好很多,深入研究RUP可以使你用一种软件过程应对更多类型的项目。
ICONIX是所以受欢迎,就是因为它延续了RUP的思路而有提供了可明确参考的工作步骤。
当然反过来,对敏捷过程的误解也是存在的,例如:RUP的支持者往往认为XP过程没有设计。实际情况是XP过程也是相当重视设计的,只不过方式不同。XP过程不建议进行预先设计,而是使用其它的一些辅助手段保证软件设计的优化,例如TDD、重构等等。
再看看思维方式。新兴的敏捷过程往往宣传自己基于小型迭代,并以此来对应变更,使项目满足客户业务需求。但所谓迭代一词应该更加细分成:“增量开发”与“迭代开发”,之间的区别如图所示。
由此看来,如XP, SCRUM, FDD等过程其实都属于增量开发。而RUP和ICONIX过程属于迭代开发。所以,对此概念模糊的人就会误解RUP更像瀑布模式。
其实增量与迭代无所谓优劣,仅仅是思维方式的不同。