流程改进：慢慢走比较好

A class should do one thing and do it well!  这是面向对象分析设计里的一个基本原则，因为只有小而精的类才易于被重用，大而全的类只适用于一个特定的系统，很难被重用。而在流程改进时，我建议的原则是每一次改动尽量只针对某一个过程领域，取得效果后再逐步进行后续的改变，一下子改变太多的话就较难达到预定的目标。因为我们平时所说的流程改进，目的都是要改变人们现有的工作习惯，以获得更高的工作效率和产品质量。正应为这是一种变化，通常会遭到受众的阻力，因为采用原来的工作方式，尽管有这样或那样的问题，软件最终也被开发出来了，为什么要改变呢？而且项目的正常开发任务也是非常繁重的，项目团队一方面既希望能够采用一些更好的工作方式来提高工作效率，但是另一方面又担心这方面的变动会占用他们太多的精力时间去学习和适应。正因为如此，如果每次变动的步伐小一些，学习掌握的难度就比较低，在尽量不影响开发团队正常工作的情况下来进行流程改进；当大家都能够感受到当前阶段的改进效果的时候，他们对于新的改进建议的抵触就会逐渐降低，而改革的信心却在逐渐增加，从而更加有利于开展下一阶段的改进工作。

实际工作中，我们可以从一个简单的工作环节入手来改进开发工作，如：做好单元测试、改用用例方式来描述需求、采用迭代化的方法来制定项目开发计划等等。以基于CMMI模型的流程改进为例，CMMI模型有两种表述形式：阶段式和连续式。实际上连续式表述更加附合流程改进的实际规律，开发团队可以选择自己最为薄弱的环节（过程域）来进行改进，而不是同时在多个开发环节（阶段式表述针对每一个阶段所推荐的一组过程域）中同时进行改进，这样效果可能更好一些。

而且在实际工作中，我们要避免流程文档化的倾向，很多软件企业制定了非常完善的流程规范，但是却从来没有考虑过这些规范在实际项目中的可操作性。我看到过好几个软件企业制定了很多的度量指标，但是这些指标在实际项目中却从来没有被认真执行过，项目经理被“要求”在项目过程中收集并监控这些指标，很多指标只是为了填写项目汇报而进行估计，项目经理并不了解这些指标对项目的实际指导意义。如果是这样的话，倒还不如仅统计一些项目经理能够理解，并且对项目计划有直接指导意义的指标更为有意义。因为流程不应该只是一个规范性的文档，流程应该是在每一个项目中被切实执行的工作方法。