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

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

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

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

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

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

  第5章主要讲了在需求分析的时候，我们应该先推开需求，获取更多实际问题的信息，设计出方案。

  首先设计方案的时候，我们不应该直接讨论这个方案的解决方案是什么。我们应该将这个问题表述清楚，然后从目标中去得到解决方案。然后我们在设计解决方案的时候需要理解为什么需要某些东西，以及谁需要它。然后要理解各个功能的价值，我们可以更好的排列这些功能的优先级。我们在构造目标的时候，要了解用户的预期。按照用户的预期去构造。

   读完了这一章，我知道了在需求分析的时候，需要根据用户的表述，理解用户的真实需求所在。以此为目标去获取构造正确的范围。

   第6章主要讲的是协作制定需求说明，这种方式可以是我们的团队对完成的内容建立共识。介绍了协作式需求说明常见的几种模型。

   第一种模型是大型工作坊，这是团队全体参加的大型需求说明工作坊是建立共识并获取实例的最有效途径之一，那些实例对功能进行了详细的描述其次小型工作坊，它较大型需求说明工作坊，他不能确保整个团队达成一致的共识，但是它更容易组织，并不需要预先计划，这个方式的灵活性更好

  通过阅读这一章，我知道了实例化需求非常依赖用户和交互团队成员之间的协作。然后大型工坊和小型工坊的长处和不足。