分析人员和最终用户的交流应该贯穿于整个项目的生命周期中
传统开发模式的另外一个缺陷是缺乏在分析人员与最终用户之间的交流。 最终用户被期望预先的指出需求并且对需求进行检查，但是他们有限的参与了方案的开发。在许多情况下，和约的商定是以预先被描述的需求为基础的，并且后来的变更需要有一个和约上的协商。
在整个开发的生命周期中维护在用户与分析人员之间的交流是尤其有效的。双方都应该理解他们拥有相同的目标：建立满足质量要求的可以解决问题的方案，同时成本是可接受的。如果他们的关系是围绕着争论关于什么是以前达成的一致和谁应该为此付钱，而不是建立一个正确的方案的话，那么项目就陷入了麻烦之中。这并不意味着分析人员应该接受所有的需求或者最终用户不应该作出变更的请求。相反，这意味着所有的项目相关的人员应该在提出需求和最终进入到订单中的需求进行一个平衡以形成更好方案的开发。他们需要认可当他们过分的严格时，应该通过一些讨论以达到一个折中的方案，并且要作积极的改变以保持项目按照计划进行。当然，这一点做起来要比说的有难度。但是朝着有效的团队协作的第一步是在分析人员与最终用户之间建立起有建设性的对话。
过度的指出预想的需求是不明智的
传统的开发方法提倡详细的预先需求，并且在过去的多年里很多人觉得项目失败是因为他们的需求对启动项目是不够详细的。但是增加需求说明的详细程度将会减少的回报。在一些情况下，项目团队需要不断的构建方案，并假设需求在整个项目周期不断的改进。记住： 软件项目的主要目标是在尽可能低成本的条件下生成可执行的能够解决手工形式的业务问题的代码。一旦你的需求到达了一定的细化程度，将他们定案的最廉价的方法是对系统进行部分的实现以可以向最终用户进行演示。同时你可以一起确定你还需要提供什么样的其他能力。 定案需求通常要经过几次的迭代，在迭代期间你可以调整需求、设计和代码，然后对测试进行引导。
在项目周期的后期你可以不必正式的文档化很多的详细的需求；代码本身可以提供足够的文档，并且很少在团队中误解什么是需要实现方面存在风险。这依赖于正被开发的系统自然的改变了参与的人数、系统期望的生命跨度、和约的义务和附加的质量标准的需求。最后，也许是最重要的，你应该象驱赶技术风险一样在项目中尽早驱赶商业上的风险。 在细化预想的需求上花费过多的时间会使你的注意偏离出降低关键的风险。
开发人员的新思想
迭代开发，对开发人员来说使用与迭代开发相关联的最佳实践和现代的工具技术，同样需要在思想上的转变。首先，就像我们在上一部分讨论的，开发人员需要在指定需求中扮演更多积极的角色。
过去，开发人员以对辣手的问题提出聪明的解决方法为荣。他们创造唯一的方案以使系统性能最大化、内存使用最小化或者提供良好的图形用户界面。当然，开发人员仍然需要提出聪明的方法， 但是他们的精力需要从构建方法转向到发现聪明的方法以尽量的将可重用的资产、开发源码的软件、通用的商业现货 (COTS) 组件和 Web 服务集成成为一个可使用的方案。为了成为优秀的开发人员，你需要知道如何最好的利用交互式的开发环境（IDE）和建模环境。“这里没有发明”的态度是达不到预期的目标的；作为一个开发人员，你的精力应该放在通过利用各种可重用的资产来产生可使用的方案上。今天快速并廉价的生产出高质量的产品才是应该受到褒奖的。
质量是测试团队的职责。在传统的开发中，在项目的最后几周，整个系统才交付到可怜数量的测试人员手中，他们被要求尽可能多的找出软件系统的缺陷。他们负责质量，开发人员负责修改他们发现的缺陷。迭代开发正好与之相反，迭代开发认为 质量是项目中每一个人的职责。现在我们拥有支持这种共有职责概念的工具和过程，允许我们交付高质量的代码。新的工具技术允许我们同步代码和设计。他们也使我们可以在系统被完成前测试代码产生的内存泄漏问题和性能问题，这是在过去无法达到的。现代的配置管理和变更管理环境支持了每日构建，不仅允许我们测试我们分离的代码，还允许我们测试我们的代码如何与系统的其他部分代码的集成。
现代的最佳实践包括测试先行的设计：首先你要指出你应该进行什么测试，然后再构建能够通过这些测试的软件。这样创建高质量的代码是我们重点要考虑的事情。现代的工具技术也支持 设计的质量问题， 1 它使质量成为了设计过程中的主要部分。它允许你在设计过程的早期就进行质量的测量并且可以自动的从设计模型中产生测试。通过保证设计的质量增强了整个系统的质量并保证了测试代码的完成。
总而言之，使用迭代式的开发方法，开发人员角色需要进行扩展；除了简单的实现需求规格说明，开发人员必须在决定什么对整个系统是必要的方面承担更多的任务。这包括帮助确保需求是正确的和在可接受的成本下创建出高质量的系统。为了作出最好的决定，开发人员需要更好的理解项目的远景和驱动项目的业务问题。这样开发人员才有可能创建一个满足需求和能够解决业务问题的方案。
测试人员的新思想
过去，我们注意到按照传统的方法，当项目快要结束时，开发出来的软件才被交给测试人员，让测试人员通过找到软件的缺陷来为软件“注入质量”。每一个测试人员都可能会退缩，因为通过经验他们知道这种方法是多么没有效率和令人失望的。
使用迭代的开发方法，测试人员仍然要负责确定系统的质量是否足以发布，但是他们确保完成高质量系统的方法却从根本上发生了变化。首先，测试人员在项目非常早的时候就参与其中，因为每一个迭代（可能除了第一个迭代）都会产生可以被立即测试的可执行的结果。在项目早期，测试更关注找到“影响大的”问题，而不是验证代码是不是已经可以交付了。这就意味着你不能简单的将代码交给测试人员； 相反，测试人员需要与分析人员和开发人员密切的合作以便他们能够理解在每个迭代中什么是需要被测试的。
传统开发模式的另外一个缺陷是缺乏在分析人员与最终用户之间的交流。 最终用户被期望预先的指出需求并且对需求进行检查，但是他们有限的参与了方案的开发。在许多情况下，和约的商定是以预先被描述的需求为基础的，并且后来的变更需要有一个和约上的协商。
在整个开发的生命周期中维护在用户与分析人员之间的交流是尤其有效的。双方都应该理解他们拥有相同的目标：建立满足质量要求的可以解决问题的方案，同时成本是可接受的。如果他们的关系是围绕着争论关于什么是以前达成的一致和谁应该为此付钱，而不是建立一个正确的方案的话，那么项目就陷入了麻烦之中。这并不意味着分析人员应该接受所有的需求或者最终用户不应该作出变更的请求。相反，这意味着所有的项目相关的人员应该在提出需求和最终进入到订单中的需求进行一个平衡以形成更好方案的开发。他们需要认可当他们过分的严格时，应该通过一些讨论以达到一个折中的方案，并且要作积极的改变以保持项目按照计划进行。当然，这一点做起来要比说的有难度。但是朝着有效的团队协作的第一步是在分析人员与最终用户之间建立起有建设性的对话。
过度的指出预想的需求是不明智的
传统的开发方法提倡详细的预先需求，并且在过去的多年里很多人觉得项目失败是因为他们的需求对启动项目是不够详细的。但是增加需求说明的详细程度将会减少的回报。在一些情况下，项目团队需要不断的构建方案，并假设需求在整个项目周期不断的改进。记住： 软件项目的主要目标是在尽可能低成本的条件下生成可执行的能够解决手工形式的业务问题的代码。一旦你的需求到达了一定的细化程度，将他们定案的最廉价的方法是对系统进行部分的实现以可以向最终用户进行演示。同时你可以一起确定你还需要提供什么样的其他能力。 定案需求通常要经过几次的迭代，在迭代期间你可以调整需求、设计和代码，然后对测试进行引导。
在项目周期的后期你可以不必正式的文档化很多的详细的需求；代码本身可以提供足够的文档，并且很少在团队中误解什么是需要实现方面存在风险。这依赖于正被开发的系统自然的改变了参与的人数、系统期望的生命跨度、和约的义务和附加的质量标准的需求。最后，也许是最重要的，你应该象驱赶技术风险一样在项目中尽早驱赶商业上的风险。 在细化预想的需求上花费过多的时间会使你的注意偏离出降低关键的风险。
开发人员的新思想
迭代开发，对开发人员来说使用与迭代开发相关联的最佳实践和现代的工具技术，同样需要在思想上的转变。首先，就像我们在上一部分讨论的，开发人员需要在指定需求中扮演更多积极的角色。
过去，开发人员以对辣手的问题提出聪明的解决方法为荣。他们创造唯一的方案以使系统性能最大化、内存使用最小化或者提供良好的图形用户界面。当然，开发人员仍然需要提出聪明的方法， 但是他们的精力需要从构建方法转向到发现聪明的方法以尽量的将可重用的资产、开发源码的软件、通用的商业现货 (COTS) 组件和 Web 服务集成成为一个可使用的方案。为了成为优秀的开发人员，你需要知道如何最好的利用交互式的开发环境（IDE）和建模环境。“这里没有发明”的态度是达不到预期的目标的；作为一个开发人员，你的精力应该放在通过利用各种可重用的资产来产生可使用的方案上。今天快速并廉价的生产出高质量的产品才是应该受到褒奖的。
质量是测试团队的职责。在传统的开发中，在项目的最后几周，整个系统才交付到可怜数量的测试人员手中，他们被要求尽可能多的找出软件系统的缺陷。他们负责质量，开发人员负责修改他们发现的缺陷。迭代开发正好与之相反，迭代开发认为 质量是项目中每一个人的职责。现在我们拥有支持这种共有职责概念的工具和过程，允许我们交付高质量的代码。新的工具技术允许我们同步代码和设计。他们也使我们可以在系统被完成前测试代码产生的内存泄漏问题和性能问题，这是在过去无法达到的。现代的配置管理和变更管理环境支持了每日构建，不仅允许我们测试我们分离的代码，还允许我们测试我们的代码如何与系统的其他部分代码的集成。
现代的最佳实践包括测试先行的设计：首先你要指出你应该进行什么测试，然后再构建能够通过这些测试的软件。这样创建高质量的代码是我们重点要考虑的事情。现代的工具技术也支持 设计的质量问题， 1 它使质量成为了设计过程中的主要部分。它允许你在设计过程的早期就进行质量的测量并且可以自动的从设计模型中产生测试。通过保证设计的质量增强了整个系统的质量并保证了测试代码的完成。
总而言之，使用迭代式的开发方法，开发人员角色需要进行扩展；除了简单的实现需求规格说明，开发人员必须在决定什么对整个系统是必要的方面承担更多的任务。这包括帮助确保需求是正确的和在可接受的成本下创建出高质量的系统。为了作出最好的决定，开发人员需要更好的理解项目的远景和驱动项目的业务问题。这样开发人员才有可能创建一个满足需求和能够解决业务问题的方案。
测试人员的新思想
过去，我们注意到按照传统的方法，当项目快要结束时，开发出来的软件才被交给测试人员，让测试人员通过找到软件的缺陷来为软件“注入质量”。每一个测试人员都可能会退缩，因为通过经验他们知道这种方法是多么没有效率和令人失望的。
使用迭代的开发方法，测试人员仍然要负责确定系统的质量是否足以发布，但是他们确保完成高质量系统的方法却从根本上发生了变化。首先，测试人员在项目非常早的时候就参与其中，因为每一个迭代（可能除了第一个迭代）都会产生可以被立即测试的可执行的结果。在项目早期，测试更关注找到“影响大的”问题，而不是验证代码是不是已经可以交付了。这就意味着你不能简单的将代码交给测试人员； 相反，测试人员需要与分析人员和开发人员密切的合作以便他们能够理解在每个迭代中什么是需要被测试的。
