【IT168 技术文章】

    这是一篇偏重于介绍方法学（特别是Agile方法）实践的文章。其读者对象是那些希望在自己的软件团体中引入某个过程方法，但又不知从何入手的开发人员、项目经理们。本文中所提到的内容更适合于应用在小型的软件团队中。对于较大规模的软件团队，本文中的部分内容也适用。 本系列包括：知识接力、代码是最终目、一致性的思考、活跃和混乱、严谨和死板、短期利益和长期利益的权衡。

    软件管理和软件开发是截然区分的吗？

    对于项目经理来说，其职责是软件项目的管理，而对于架构师、编码人员来说，其职责是软件设计和开发。虽然在一些小型的团队中，这两种职责有时候是同一个人担任的，但两种角色的区分是必要的。从事过软件开发的人都能或多或少的感受到软件管理和软件开发之间客观存在的沟壑。

    我常常听到来自两个方面的声音。一边抱怨说设计师、编程人员阳奉阴违，难以管束，导致已订立的软件过程形同虚设。另一边抱怨软件过程存在诸多不恰当的地方，变成了软件开发的绊脚石。

    现代的方法学理论以及相应的过程实践为我们奠定了软件开发科学管理的基础，个中的翘楚包括RUP和XP，纵观这些方法、过程，都非常强调过程的流畅、生命周期的延续。而在实际的应用中，我们却常常能够看见对它们的不恰当的理解，不正确的使用。尤其是那些希望在自己的软件团体中引入新型的方法过程新手们。对于他们来说，最容易犯的一个错误就是忽视了如何利用一个软件过程来创造一个成功的软件。

    关于如何建立一个软件过程的资料很多，但是这些资料并没有把为什么需要过程，过程的目的是什么之类的问题说清楚。而这些资料的读者们，往往需要花费大量的时间，亲自进行实践之后，才能获得这些问题的答案，而付出的代价是教训和挫折。同样的，我和我的伙伴们也经历了这样一个过程。因此，我希望把我在过程应用、过程改造中涉及到的问题例举出来（采用过程模式的方式）。如果大家能够利用到这些经验（哪怕是一些），那本文的目的也就达到了。因此，本文并不是一篇专门讨论如何建立过程的文章，也没有涉及建模、设计、编码等方面的内容。但是本文中所讨论的内容都可以对以上的活动起到部分的指导作用。

    敏捷？敏捷！

    从开始研究软件工程，我就对敏捷过程的概念情有独衷，但是随着学习的深入（所犯错误的增多），我发现敏捷是无处不在的，她是一种尺度，一种处于"混乱"和"死板"之间的平衡艺术。有句俏皮话说的是"一放就乱，一管就死"，这句话很好的点出了软件过程的一种无奈性。如果没有严格的规定，软件开发就陷入一种混乱、无序的状态，但是如果制定了过于严格的规定，软件人员的思路又受到极大的约束，管理成本也随之上升。敏捷正是一种处于两个极端之间微妙平衡的艺术。这种艺术难以完全表述，但是可以通过一些指导，来帮助大家达到这种境界。

    因此，我们可以推想的到，敏捷是见仁见智的。每一个软件团体都有自身的特性，其敏捷过程必然都不尽相同。如何设计出成功的敏捷过程，来保证软件团体的成功呢？本文通过一些过程模式的讨论，揭开了问题的一角。关于过程设计的完整的讨论，大家可以参考敏捷软件开发[Alistair Cockburn]一书（该书近来将有中文版面世），该书详细的描述了过程设计的来龙去脉，以及如何根据组织的特点来选择适当的过程。

    因此，虽然本文中并没有特别提到敏捷的字眼，但是所讨论的内容无不在敏捷思维的范围之内。

    MDA推动软件可重用框架的建立

    我有一个梦想，希望有一天能够不用在诸多的平台之间摇来摆去。虽说Java语言的口号就是跨平台。但事实上，我们还是无法完全摆脱平台的束缚。

    在UML2.0的规范中，提到了一个MDA（Model Driven Architecture）的概念。在众多的软件平台中不知该如何选择，已经演变为当今软件开发的主要难题。MDA的存在目的就是为了解决这个问题。通过MDA技术，一个UML的模型可以是平台无关的，称为PIM（Platform-Independent Model），也可以是和特定平台相关的，称为PSM（Platform-Specific Model）。利用平台技术的软件商，可以专注于自己的领域，集中描述业务功能，业务规则，而无须考虑特定的技术，构建出一个PIM，然后，通过支持MDA的工具，将PIM转换（通过不同Profile进行映射）为一个或多个PSM。这时候的模型仍然是UML的。但是，这个转换过程虽然有工具的辅助，但仍然需要外力的介入。接下来，开发工具将会从PSM中产生可执行代码。这就是MDA的思路，它把以往以程序为中心的开发模式转变为以设计为中心的开发模式。