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

软件工程需要在科学和艺术之间求得权衡，科学的一面包括了软件开发规范、准则、实践、过程、方法；而艺术的一面则囊括了人员的激励、协调，组织的设计等因素。因此我们需要审视我们的规则、过程、方法，它们是否能够发挥出人的创新性？或是它是否足以约束人的行为？
意图
对开发人员的行为进行约束是必要的，但同时却限制了开发人员的创意。我们如何在这两的极端之间取得平衡呢？
示例
成达公司在以往的项目开发中，一般都不限制开发人员的行为――公司中开发人员都有各自的编码习惯，使用不同的开发工具，更不用说遵循什么开发过程了。因此一旦有人员离职，接手的人员往往都需要花费大力气来熟悉原先的系统，因为原先的人员几乎没有留下文档，或是仅有一些旧的、不能使用的文档。公司中也有软件人员向管理者提出过这方面的建议。但是由于软件开发并不是公司的主要盈利机构，公司不太注重这件事。因此这种情况就一直保持下去。由于公司中的软件人员大多数都有着多年的开发经验，所以日常的运作也算是基本正常。从今年开始，情况发生了改变，由于经营策略的改变，公司换了一位老总，新老总对软件部门非常重视，并投入资金，为软件部分引入了一套严格的规定，制定了统一的编码规则、开发环境，严格的作息制度、汇报机制。有位员工这样形容新过程，"就差没有制定上洗手间的时间了"。过程实施以来，员工怨声不断，由于个人原先熟悉的开发方式被打破，软件开发速度大大降低。客户的投诉也明显增加，甚至出现了项目中止的情况。过程实施6个月之后，发生了3位资深的开发人员离职的事件。最后，管理层不得不废除新过程，回到原先的开发方式上去。
上下文
开发过程有两种极端。我们可以看看下面的两种情况，你更愿意在哪一种环境中工作。
项目组的三个程序员分别开发项目的三个模块。需求仅仅持续了3天的时间。原定计划是1周，但是因为项目甲方人手紧缺，调走了需求调研的领域专家。三个程序员闷头开发，彼此隔绝。每位程序员都有自己的类库和开发包。没有文档，没有测试用例。突然，程序员甲喊道，"昨天我放在这里的需求说明书呢？就是那张上头有脚印的打印纸。"界面开发一半之后，用户发现似乎不同模块的界面相差极大，按钮的位置、菜单风格、窗口布局，没有一处相同的。更为糟糕的是，似乎程序员对用户需求的理解又错了。
程序员乙正在嘀嘀咕咕的修改他的代码，因为架构师在检查了他的代码之后，指出了100多处和标准规则不一致的地方。包括变量命名、注释规则等等。"烦死了！"程序员丙伸了个懒腰，他正在修饰他的设计类图。上次也是这样，模型已经画的尽善尽美了，结果又因为设计发生变化不得不重来一次。看来今天有没什么时间写代码了。项目经理正在审查昨天各个开发小组提交上来的文档，"这几份文档的格式都有问题！"他皱了皱眉头，看来在下午的例会上，他还要着重强调统一规格的问题。
问题
可以看到，上述的两种情形正是我们的模式名称的后半部分所描述的：混乱和死板。那么，我们如何达成模式名称的前半部分－活跃而且严谨呢？

原文转自：http://www.ltesting.net