今天我阅读了《实例化需求》的4-6章。

   第4章主要讲的是如何着手改变过程和团队文化，以便你去实施实例化需求说明。

   如何开始改变过程？首先在新项目中，我们应该将实例化需求说明当作更广阔的过程变更的一部分。其次团队应该专注于提高产品质量，而不是专注于某个特定过程。然后把功能测试自动化作为采用实例化需求说明的第一阶段并应用到现有项目。然后在测试人员负责测试自动化时， 需要引入一个可执行实例化需求分析说明的工具。最后当开发人员对测试驱动开发具有较深的认识的时候。我们可以使用测试驱动开发作为软件开发的垫脚石。

  如何开始改变团队文化？首先在一个抵制变化的环境中工作时，应避免使用“敏捷”术语。实施过程变更无需技术术语，只需是问题变得显而可见，同时逐渐把大家推向解决问题的正确方向就可以了。其次要确保得到管理层的支持。没有管理层的支持和认可，过程变更的几率很小。然后我们应该把实例化需求说明当作比执行验收测试更好的方式来推销。如果可执行的需求说明足够广泛，而且验证足够频繁，那么开发团队与客户之间的信任会增加到这样的强度：在软件交付后，手上的验证软件的功能不再必要。然后不要将测试自动化成为最终的目标。这种方法会导致功能测试自动化过于技术化，使得测试只是一些脚本，而不是需求说明，这是常见的一种失败模式。如果把功能测试自动化当成实例化需求说明的一个步骤，那就要让团队所有人都清楚最终的目标是什么。当功能测试站住了脚，就该进行下一步行动。然后开发过程中，不要太关注工具实例化需求说明并不以程序员为中心，而程序员独自用一个工具不会取得很好的效果。然后在迁移过程中，分出一个人去维护遗留脚本。这样团队就可以更快地朝着迁移到新过程的目标前进。 最后通过监视测试是否执行，来让程序员执行自动检查程序。

  读完这一章，我知道了改变过程和改变团队文化对于实施实例化需求说明的重大意义。实例化需求说明是在短迭代或基于流程的开发过程里取得成功的重要因素吗。在软件开发中，需要整合跨功能的团队，测试人员、分析师以及开发人员为了给系统建立正确的需求说明而一起工作。

阅读《实例化需求》4-6章有感