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

    在引入软件过程的时候，不要花费大量的时间来编写描述过程的文档，尽量利用现成的。有编写文档的时间，倒不如用来对开发人员进行培训，并获取他们的支持。在实践中，我们发现，人们往往不会去真正阅读并理解大量的文档。文档过多也将使得工作失去重点。从一些比较简单的、容易见效的、最好是能够结合现有的一些流行技术的（程序员们都喜欢）。例如，使用用例技术来改进需求、使用UML来改进设计。这样做的好处还在于，这些技术往往都有较多的资料，利用这些资料可以节省编写指南的时间。

    开发人员应该要成为过程的主人，至少部分有能力和意愿的开发人员应该成为。单凭管理人员或是外部顾问的力量是很难完成过程的创建的。因此必须令开发人员主动投入到这项工作中来。我们认为软件过程必须要能够结合具体的技术，因为这样，才能够吸引开发人员。例如，版本控制工具的配置、集成测试环境的开发、单元测试技术、设计模型等等。从技术出发，扩展到整个的软件过程，是一种渐进的，但行之有效的方法。事实上，我们正是采用从定义面向对象软件框架出发，来开始和完善过程定义的。这其实就是我们在代码是最终目的模式和短期利益和长期利益的权衡模式中讨论的构架的形成过程。不同的软件组织会有自己的路，但目标是一致的，就是通过一些有效的活动，逐步引入软件过程，并令其在组织中开花结果。

    如何把握过程控制的尺度

    其实软件过程设计的思路和面向对象程序的设计思路是非常相似。例如，在进行设计和程序的控制的之后，我们比较注重类的公有方法部分和包的外观类部分，而对于类或包的内部实现并不很在意。因为我们认为对于面向对象设计来说，公有方法或接口是最重要的，它们设计的好坏直接关系到软件的好坏。因此，我们的思路是，把握关键的检查点（就像我们在上一篇中提到的KPI的思路）。软件过程也是类似。活动内部的信息交互并不是我们所关心的，只要活动能够产生最终需要的信息就可以了。例如，在需求阶段，我们最关心最后的工件――需求说明书。包括它的内容和外观。因为一方面它是后续活动的基础，另一方面它需要交付给客户。为保证其顺利开发，我们设置了需求审查会议。至于会议之前，开发人员喜欢用什么样的技术和方式进行需求调研，并不是我们所关心的，而且，我们也乐意看到开发人员尝试使用一些新的技术，这样才能够既保证了严谨，又保证了活跃。因此，在开发过程中，把精力放在那些检查点上，只有力气用在刀刃才才能达到最好的效果。在知识接力模式中我们就谈到了检查点的问题，此外，一些重要的活动，例如日创建和交付点，都是关键的检查点。

    如果你的过程比较严谨，开发人员并没有什么创新的机会或环境，想办法制造一个。软件开发人员喜欢研究新的技术，这是他们的优点，但是在项目中应用新技术是存在风险的（参见短期利益和长期利益的权衡模式）。鼓励并支持开发人员进行新技术的研究，并让其负责这方面的事务。对团队，对个人都是有益的。

    在一致性的思考模式中，我们分析了工件和过程不一致时的对策，并简单的谈到了推迟文档的实现的问题。这里我们继续这个话题。没有多少程序员喜欢文档（这里的文档是广义的文档，包括模型、图例、文字处理器文件、注释，它等同于我们在知识接力模式中提到的工件），而经理们则对文档又爱又恨，没有文档不行，这会造成知识的流失；文档太多也不行，因为它需要大量的投入，并招致开发人员的反感。因此，我们的建议是坚持以够用就好的思路对待文档，并使用三种指导原则：

    区分关键文档和普通文档。关键文档的信息收集工作应该不断进行，虽然文档并不需要额外的修饰（就像一致性的思考模式中所说的），但是你要保证它把必要的信息都记录下来了。典型的关键文档包括了需求模型、设计模型。普通文档的信息可以从关键文档中取得，因此可以尽可能的延迟它的创建。例如用户指南之类的文档。但是请注意，关键文档和普通文档只是相对的概念，例如，你开发的如果是一个设计类的软件，那么用户指南可能就成为关键文档，需要从一开始就考虑编写的工作。如果有必要，你应当在软件过程中加入文档制作的活动，以保证有充分的时间来处理它们。
   
    在关键的检查点上保证文档的完整性和一致性。上文中我们提到了检查点的概念。就像在需求复审这个检查点上，我们需要保证需求模型完整的再现了用户或领域专家的思路，而在设计复审这个检查点上，我们则需要保证设计模型和需求模型的一致性，并确保开发人员和设计人员都同意当前的设计模型。只在检查点上同步文档可以大大减少文档的负担，但文档需要进行同步的检查点则要好好的考虑。例如，帮助文件需要同步的检查点，界面原型需要同步的检查点。

    使用工具来减轻文档的工作量。我们在知识接力模式和一致性的思考模式中都提到了工具，这里我们再一次的强调它，但我们不再这个问题上多费口舌了，大家可以参看两个模式中相关部分的讨论。

    总之，小心的处理文档，不要让文档成为开发人员怒气的焦点，不要让编写文档变成一种应付了事的工作。这样的话，既花费了精力，又得不到应有的效果。

    最后一点，千万不要相信过程能够解决一切。"我们采用了非常先进的过程，我们一定能够成功的"这种话无异于痴人说梦。开发软件的是人，而不是过程。好的过程对于软件的成功来说，只是一个必要条件，而不是充分条件。永远依靠你的开发人员。当人的行为和过程冲突或不一致的时候，想想过程的目的，再做最后的定论。

    小结
       
    在创建软件过程时，从现有的软件过程中选择一个适合自己的。

    水无常形，软件过程也是一样，确保它随着时势而变。

    注意引入软件过程的开始阶段，让开发人员参与到软件过程中来。

    重点关注检查点。
   
    保持文档活动的敏捷性。

    过程不是仙丹，人才是。