闲谈——软件方法论

软件方法论在近期被屡屡提及，我不知道是国内的开发团队真的需要，还是如当初 ISO/CMM 那样作为一个标签被缝在脑门上做装饰。当然，只要是做事自然就有方法论，只不过在一堆理论和文案的背后找寻一个适合自己适合公司团队的却不难么容易。我所了解的一些公司，其管理方式已经彻底沦落为文牍主义，没完没了的管理文档变成了工作人员巨大的负担，最后那些装饰精美的文档在某个未知的角落里成为垃圾。

传统的瀑布(Waterfall)开发模式依然是现今最常用的方法论和开发方式。将开发过程划分为需求分析(Requirement Analysis)、系统分析(System Analysis)、系统设计(System Design)、开发实现(Implementation)、测试(Test)、发布(Deployment)、系统支持(Supporting)和变更管理(Change Management)等过程，或许还会在开发实现过程中引入迭代的单元测试。瀑布模型有些理想化，设计和开发人员理想地认为可以按照时间表逐步完成每个步骤，任何时候无需和不能回退到上一个步骤。当然，我个人也遵循需求和设计冻结这个规则，但现实开发中，无休止的需求变更或者设计缺陷让瀑布模型基本无法按章执行。开发的最后，时间表、计划进度等等都会变成一个个可笑的理想。于是项目经理会说我们在计划当初就已经预留了冗余时间，只是这冗余究竟是否管用，只有天知道。

瀑布模型用了多少年？10年？20年？我不知道，反正业内的精英们已经忍无可忍，开始了新的方法论设计。好了，世界上又出现了很多新的名词，诸如 RUP(Rational Unified Process)、XP(Extreme Programming)、TSP(Team Software Process)等等。XP 已经风靡了一段时间了，RUP 最近也走入寻常人家，屡屡在招聘广告上出现。

由 Rational Software 提出的 RUP，其核心内容是：迭代模型(Iterative Model)，用例驱动(Uses Case)，UML 架构设计(UML Architectural Design)。将系统划分为一个个相对独立的用例，然后围绕这些用例进行设计和开发。由于采取相对较小的模型迭代，那么其测试和除错成本也小得多。 RUP 强调将变化在设计阶段消灭掉，提倡事先设计好组件为核心的体系结构，不断的评估和测试组件质量，同时以用例控制软件的变化。在这些原则的基础上，把软件人员分成分析，开发，管理，测试，工具支持，配置等不同角色。

RUP提出了很多复杂的概念，基本上是围绕着 UML 进行的，包括不同的场景(View)和模型(Model)。客户和业务分析人员使用用例图讨论业务流程和逻辑，架构设计师使用UML软件进行系统设计，然后是程序开发人员依照架构设计师提供的类图(Class Diagram)、次序图(Sequence Diagram)以及活动图(Activity Diagram)图例进行编码。说实话，我有点晕~~~ 因为在我工作的公司就基本采取此类方法，只不过很多程序员对于以 UML 方式表达的业务逻辑和对象关系理解不怎么到位，加上国内公司不怎么重视培训，结果问题自然多多。也许你会说，我们可以使用 Rational Rose 导出程序框架，程序员去填空就可以了。也许是吧，一番痛苦之后，每个程序员基本完成了工作，程序也基本能运行。只是老天保佑，不要让我开发下一个版本或者进行维护。

我们可以看出 RUP 非常依赖于架构设计的合理性，也就是说架构设计师必须完成合理的规划，包括所有的组件和基础框架设计。设计的可扩展性(Extensibility)，可维护性(Maintainability)，可延拓性(Scalability)，可重用性(Reusability)，还有诸多的公用组件设计，这些对于架构设计师的能力不能不说是个挑战。

OK，或许你对 RUP 已经熟悉了，就是你日常接触的那个方法论。我们继续看看其他的。

TSP 中文翻译为 "团队软件过程"，由称之为 "软件质量之父" 的 Watts S. Humphrey 提出。TSP 在角色划分上包括项目经理、开发经理、计划经理、质量经理，以及技术支持经理等。TSP 要求所有团队成员严格记录软件开发过程，包括Bug、周期、进度等等。TSP 从某种角度来说是 CMM 的延续，它更多强调的是软件开发质量管理，强制成员的个人记录以及诸多的质量管理规范。使用记录数据进行质量跟踪和管理是个美好的设想，只不过某些时候会引起团队成员的变相抵制。TSP 给我的感觉更适合工业生产，流水线上的每个零件都会被详细记录下来，而对于不断变化的软件开发过程而言，死板并不能带来质量和合理的工期。

而 XP 相信很多人都很熟悉了。什么结对编程，简单设计，改进设计，持续集成，现场客户，测试驱动等等。XP 也把人员分成测试、交流人员、设计师、客户、程序员等。XP 提倡客户和开发人员在同一个场地共同组成开发团队，提倡交流。不需要太复杂的用例，以测试驱动(TDD)的方式进行开发，因此也省略了复杂的系统设计。另外，XP 的短周期交付和持续集成使得软件开发过程被分割成更小的迭代版本，每个版本都是可运行使用的，因此它也是最能适应需求变化的。

理论上的东西看上去总是很美好的，可在实际操作过程中，往往有太多不可预见的因素干扰我们的执行。对于不同的公司，不同规模的开发团队其适用的开发方法自然也有所不同。我们大可在公司整体管理上使用 TSP，在部门级别的开发中使用 RUP，而对于底层的小团队使用 XP 好了。当然综合多种不同的管理方法，最终找到最适合自己当前使用的开发方法需要不停地调整和积累。

无论如何，软件开发方法论再好，也需要合适的人员与之配合。在没有合适的团队和成员之前，还是老老实实去总结一下管理和文化的不足吧。

原文：http://www.rainsts.net/article.asp?id=298