使项目中的每一个成员都参与到质量保证中
对于项目经理来说移到迭代开发方法需要的其他思想的改变是开始将质量保证作为一个集体的职责考虑。我通常会惊讶的听到项目经理说“我需要测试小组对我的开发人员保持忠诚，”或者“如果分析人员没有写下单个的需求，他们将不会被实现。” 当然，你的确需要测试小组来建立高质量的应用，并且失败的文档化和跟踪需求将导致问题的出现。但是如果开发人员不把质量当作自己的责任，你也就会陷入到质量问题中。为了实现这一点，你需要从通过信任你的团队和清晰的交流你们的预期开始。假如你不能信任这些人，那么也许这些人不应该属于你的团队。
理想的情况下，项目经理应该能够宣称“我的开发人员负责交付高质量的代码；为了帮助开发人员，我们有一个测试团队，测试团队有专业的能力并可以验证被交付的代码是否是高质量的，”并且“我们的开发人员负责实现满足最终用户需要的应用。为了帮助开发人员，我们有一个分析的团队在适当的详细级别上文档化需求，并且分析人员是开发人员和最终客户之间的桥梁。” 创建交能够协同工作的团队 — 也就是说使团队中的分析人员、开发人员和测试人员能够一起工作来实现高质量的结果 — 是成功的迭代开发的关键之一。
质量保证和方法专家的新思想
许多组织都有质量专家 — 负责达到一定的标准的人，比如 SEI CMM / CMMI 中的标准，或者是组织内部的质量标准。许多组织也有方法专家，他们或者来自软件工程过程组（SEPG），或者是独立的负责软件开发中的方法。
通常，这些质量和方法专家在采用迭代的开发思想时存在最大的问题。他们中的许多人花费了他们职业生涯的大部分时间来驱使组织按照“文档越多越好”、“越多检查越好”、“对于过程工作，需要被彻底的文档化”，和“过程应该提供一个基于时间的你所需要执行的项目中的特定任务的描述”这样的传统的至理名言来指定过程。他们相信通过跟随这些提供了高度形式化的原则，就可以避免项目的失败。
然而，当这样做的太过火时，将产生相反的效果，因为 高度的形式化将增加迭代的成本，并鼓励使用瀑布型的周期。相反，你需要通过风险驱动，对每个迭代产生可演示的结果的迭代方法彻底的平衡文档的最佳实践。这种方法允许项目团队增强产品的质量，同时也可以降低形式化的程度和整个的成本。我们应该注意，使用迭代的方法并不排斥使用高度形式化的方法，高度形式化的方法可能对安全第一的应用或者其他严格要求质量的应用是有用的。
灵活性是关键的
一个关键的变化是软件过程和质量方法应该提供给项目经理调节项目风险的足够的灵活性；项目经理应该不断的监视项目的活动和状态，并且调整过程的执行以降低关键的风险。一个过程可以指明如何应对各种风险和产生被需要的结果，但是风险典型的是预先未知的，因此你不可能在早期就指明什么任务应该被执行来应对风险。你也不知道哪一个需求应该被指定什么时候用什么组件来设计和实现他们。这就意味着你所用的过程需要提供关于里程碑代表什么、如何实现它和如何降低风险的清晰的管理指南 — 通过注意项目执行的细节来保留过程的灵活性。
你不能通过在项目过程中简单使用具体的指导来创建一个一个有效的项目计划。项目计划本身需要是一个迭代的过程，包括对当前风险、进度、测试结果等等进行评估以为下一阶段的迭代的详细计划收集输入。
这也意味着项目的检查或者审计不应该主要的关注验证是否项目团队已经制造了一系列的产物或者执行了一系列的活动。相反，审计应该瞄准在识别和验证风险和确认 适当的产物和活动被完成以降低风险上。审计也应该检查以前的问题以识别出公共的失败模式，并且建议过程的修改以保护将来的最小失败的可能性。
客户的新思想
使用传统的软件开发方法的客户期望在开发工作中有最小的投资。他们想预先指出所有的需求，确定一个固定的价格，然后等待最终系统的交付。经常的，会产生在期望值和实际交付系统之间的非常大的差距 — 解决方案并没有满足客户真实的业务需要。
通过转向迭代开发，改变客户和开发团队之间的交互模式，客户和开发团队都可以避免大量的痛苦。在一个迭代开发的项目中， 客户应该是构建应用团队中的不可缺少的一部分。客户与开发团队的其他成员协同工作以确保最终交付的应用系统满足被需要的业务价值。客户的组织应该尽可能的保持与开发团队之间交互的兴趣，以确保开发团队可以理解他们应该构建什么和项目中具有什么样的风险和问题。如果客户没有帮助指导开发的工作，开发团队可能会开发出错误的应用 — 每个人都会蒙受损失。
在迭代开发的模式中，客户不能仅仅指出他们所预期的然后就等待系统交付。不论他们怎么清晰的定义，所有的需求都从属于众多的说明和可能的实现。对开发团队来说，与其生成更加详细的需求，还不如投入时间更加频繁和有效的与项目的关键投资人（包括客户）进行沟通。那么，当客户查看演进的应用时，他们将获得应用应该做什么的更好的理解，并可以提供有建设性的建议以改进系统。同时，如果在项目中业务要求发生快速的变化，需求也需要随之发生改变。
对于项目经理来说移到迭代开发方法需要的其他思想的改变是开始将质量保证作为一个集体的职责考虑。我通常会惊讶的听到项目经理说“我需要测试小组对我的开发人员保持忠诚，”或者“如果分析人员没有写下单个的需求，他们将不会被实现。” 当然，你的确需要测试小组来建立高质量的应用，并且失败的文档化和跟踪需求将导致问题的出现。但是如果开发人员不把质量当作自己的责任，你也就会陷入到质量问题中。为了实现这一点，你需要从通过信任你的团队和清晰的交流你们的预期开始。假如你不能信任这些人，那么也许这些人不应该属于你的团队。
理想的情况下，项目经理应该能够宣称“我的开发人员负责交付高质量的代码；为了帮助开发人员，我们有一个测试团队，测试团队有专业的能力并可以验证被交付的代码是否是高质量的，”并且“我们的开发人员负责实现满足最终用户需要的应用。为了帮助开发人员，我们有一个分析的团队在适当的详细级别上文档化需求，并且分析人员是开发人员和最终客户之间的桥梁。” 创建交能够协同工作的团队 — 也就是说使团队中的分析人员、开发人员和测试人员能够一起工作来实现高质量的结果 — 是成功的迭代开发的关键之一。
质量保证和方法专家的新思想
许多组织都有质量专家 — 负责达到一定的标准的人，比如 SEI CMM / CMMI 中的标准，或者是组织内部的质量标准。许多组织也有方法专家，他们或者来自软件工程过程组（SEPG），或者是独立的负责软件开发中的方法。
通常，这些质量和方法专家在采用迭代的开发思想时存在最大的问题。他们中的许多人花费了他们职业生涯的大部分时间来驱使组织按照“文档越多越好”、“越多检查越好”、“对于过程工作，需要被彻底的文档化”，和“过程应该提供一个基于时间的你所需要执行的项目中的特定任务的描述”这样的传统的至理名言来指定过程。他们相信通过跟随这些提供了高度形式化的原则，就可以避免项目的失败。
然而，当这样做的太过火时，将产生相反的效果，因为 高度的形式化将增加迭代的成本，并鼓励使用瀑布型的周期。相反，你需要通过风险驱动，对每个迭代产生可演示的结果的迭代方法彻底的平衡文档的最佳实践。这种方法允许项目团队增强产品的质量，同时也可以降低形式化的程度和整个的成本。我们应该注意，使用迭代的方法并不排斥使用高度形式化的方法，高度形式化的方法可能对安全第一的应用或者其他严格要求质量的应用是有用的。
灵活性是关键的
一个关键的变化是软件过程和质量方法应该提供给项目经理调节项目风险的足够的灵活性；项目经理应该不断的监视项目的活动和状态，并且调整过程的执行以降低关键的风险。一个过程可以指明如何应对各种风险和产生被需要的结果，但是风险典型的是预先未知的，因此你不可能在早期就指明什么任务应该被执行来应对风险。你也不知道哪一个需求应该被指定什么时候用什么组件来设计和实现他们。这就意味着你所用的过程需要提供关于里程碑代表什么、如何实现它和如何降低风险的清晰的管理指南 — 通过注意项目执行的细节来保留过程的灵活性。
你不能通过在项目过程中简单使用具体的指导来创建一个一个有效的项目计划。项目计划本身需要是一个迭代的过程，包括对当前风险、进度、测试结果等等进行评估以为下一阶段的迭代的详细计划收集输入。
这也意味着项目的检查或者审计不应该主要的关注验证是否项目团队已经制造了一系列的产物或者执行了一系列的活动。相反，审计应该瞄准在识别和验证风险和确认 适当的产物和活动被完成以降低风险上。审计也应该检查以前的问题以识别出公共的失败模式，并且建议过程的修改以保护将来的最小失败的可能性。
客户的新思想
使用传统的软件开发方法的客户期望在开发工作中有最小的投资。他们想预先指出所有的需求，确定一个固定的价格，然后等待最终系统的交付。经常的，会产生在期望值和实际交付系统之间的非常大的差距 — 解决方案并没有满足客户真实的业务需要。
通过转向迭代开发，改变客户和开发团队之间的交互模式，客户和开发团队都可以避免大量的痛苦。在一个迭代开发的项目中， 客户应该是构建应用团队中的不可缺少的一部分。客户与开发团队的其他成员协同工作以确保最终交付的应用系统满足被需要的业务价值。客户的组织应该尽可能的保持与开发团队之间交互的兴趣，以确保开发团队可以理解他们应该构建什么和项目中具有什么样的风险和问题。如果客户没有帮助指导开发的工作，开发团队可能会开发出错误的应用 — 每个人都会蒙受损失。
在迭代开发的模式中，客户不能仅仅指出他们所预期的然后就等待系统交付。不论他们怎么清晰的定义，所有的需求都从属于众多的说明和可能的实现。对开发团队来说，与其生成更加详细的需求，还不如投入时间更加频繁和有效的与项目的关键投资人（包括客户）进行沟通。那么，当客户查看演进的应用时，他们将获得应用应该做什么的更好的理解，并可以提供有建设性的建议以改进系统。同时，如果在项目中业务要求发生快速的变化，需求也需要随之发生改变。
