过程塑造: （五）活跃和混乱、严谨和死板

意图
对开发人员的行为进行约束是必要的，但同时却限制了开发人员的创意。我们如何在这两的极端之间取得平衡呢？

示例
成达公司在以往的项目开发中，一般都不限制开发人员的行为――公司中开发人员都有各自的编码习惯，使用不同的开发工具，更不用说遵循什么开发过程了。因此一旦有人员离职，接手的人员往往都需要花费大力气来熟悉原先的系统，因为原先的人员几乎没有留下文档，或是仅有一些旧的、不能使用的文档。公司中也有软件人员向管理者提出过这方面的建议。但是由于软件开发并不是公司的主要盈利机构，公司不太注重这件事。因此这种情况就一直保持下去。由于公司中的软件人员大多数都有着多年的开发经验，所以日常的运作也算是基本正常。从今年开始，情况发生了改变，由于经营策略的改变，公司换了一位老总，新老总对软件部门非常重视，并投入资金，为软件部分引入了一套严格的规定，制定了统一的编码规则、开发环境，严格的作息制度、汇报机制。有位员工这样形容新过程，"就差没有制定上洗手间的时间了"。过程实施以来，员工怨声不断，由于个人原先熟悉的开发方式被打破，软件开发速度大大降低。客户的投诉也明显增加，甚至出现了项目中止的情况。过程实施6个月之后，发生了3位资深的开发人员离职的事件。最后，管理层不得不废除新过程，回到原先的开发方式上去。

上下文
开发过程有两种极端。我们可以看看下面的两种情况，你更愿意在哪一种环境中工作。

项目组的三个程序员分别开发项目的三个模块。需求仅仅持续了3天的时间。原定计划是1周，但是因为项目甲方人手紧缺，调走了需求调研的领域专家。三个程序员闷头开发，彼此隔绝。每位程序员都有自己的类库和开发包。没有文档，没有测试用例。突然，程序员甲喊道，"昨天我放在这里的需求说明书呢？就是那张上头有脚印的打印纸。"界面开发一半之后，用户发现似乎不同模块的界面相差极大，按钮的位置、菜单风格、窗口布局，没有一处相同的。更为糟糕的是，似乎程序员对用户需求的理解又错了。

程序员乙正在嘀嘀咕咕的修改他的代码，因为架构师在检查了他的代码之后，指出了100多处和标准规则不一致的地方。包括变量命名、注释规则等等。"烦死了！"程序员丙伸了个懒腰，他正在修饰他的设计类图。上次也是这样，模型已经画的尽善尽美了，结果又因为设计发生变化不得不重来一次。看来今天有没什么时间写代码了。项目经理正在审查昨天各个开发小组提交上来的文档，"这几份文档的格式都有问题！"他皱了皱眉头，看来在下午的例会上，他还要着重强调统一规格的问题。

问题
可以看到，上述的两种情形正是我们的模式名称的后半部分所描述的：混乱和死板。那么，我们如何达成模式名称的前半部分－活跃而且严谨呢？

方法
这又是一个需要权衡的问题。正是这种问题让人头疼不已。造成软件过程无效或束缚开发人员的结果有两种不同来源的因素。一是在过程选择和创建的时候，我们忽略了一些问题，一种是过程实施后的控制上我们没有仔细的思考。

软件过程的迷思
很明显的，上面所讨论的两种极端都不是优秀的软件过程。然而，就像我们看寓言故事一样，再取笑寓言故事中的人物的时候，可曾想过自己也犯过类似的错误，只是轻重程度不同而已。虽然我们不会犯上例中所有的错误，但是确实会出现其中的一些情形。那么，我们在建立软件过程的时候，如何防止出现上述的一些情境呢？

以我们自己为例子。在建立过程的时候，我们选择是以RUP为基础。为什么不选择XP之类的敏捷方法呢？原因有二：i)敏捷方法的实践很优秀，但是作为完整的过程，它仍然有其不充分的地方。ii)XP中有很多优秀的实践，但另一些我们并不完全赞同。在选择了RUP之后，为了保证过程的灵活，我们删减了大量的活动和工件，仅保留了一些关键的。但是我们清楚，如果现有的团队规模发生变化，删除的这些活动和工件可能需要重新添加到过程中来。此外，我们引入了XP中的一些优秀的实践。例如测试优先、重构和结对编程。对于结对编程这项实践，我们没有完全采纳XP的建议，而是在一些关键的活动上，例如指导、模块设计、单元测试，采用了结对编程实践。

好的，首先，在阅读了这个例子之后，我希望大家不要都去选择RUP或是XP，这样的话说明你并没有领会这个例子的意思。根据自己的特色来选择软件过程是这个例子所要表达的第一个意思。有些团队原先就已经拥有运作的差强人意的过程，因此并没有必要一股脑转换到RUP或是XP上去。Alistair Cockburn在他的敏捷软件开发（该书已有中文译本，Alistair Cockburn的网站上有英文原版的草稿可供下载）一书中讨论了如何根据软件团队选择敏捷过程。事实正是如此，在开发性命攸关的系统时（例如急救系统），被认为是快餐式的实践活动，在开发业务系统时，可能就显得过于死板了。因此，在我们选用RUP的同时，删除了其中的很多活动，因为我们不需要它们。例子要表达的第二个意思是，请选用一个现成的软件过程，而不是自己开发一个。现成的软件过程往往都经过精心的设计和实践的验证，而且，如今的大部分软件过程都可以对其进行剪裁，不至于说找不到完全不合适的过程。其实，例子中还隐含了第三个意思，以往合适的过程未必就适合现在的情况。在 代码是最终目的模式中的例子吗？没有永远合用的过程，让你的过程随着你的组织的成长而成长，随着环境的变化而变化。

不要过于在乎你的过程过轻或过重，只需要关注它是否合适，开发人员能否接受。新的过程是否要求开发人员改变原先的习惯，而他们的反应如何？很多时候，正是对旧习惯的挑战导致了开发过程的失败或不顺利。这里需要非常小心的处理。