灵活性是关键的

    一个关键的变化是软件过程和质量方法应该提供给项目经理调节项目风险的足够的灵活性；项目经理应该不断的监视项目的活动和状态，并且调整过程的执行以降低关键的风险。一个过程可以指明如何应对各种风险和产生被需要的结果，但是风险典型的是预先未知的，因此你不可能在早期就指明什么任务应该被执行来应对风险。你也不知道哪一个需求应该被指定什么时候用什么组件来设计和实现他们。这就意味着你所用的过程需要提供关于里程碑代表什么、如何实现它和如何降低风险的清晰的管理指南 — 通过注意项目执行的细节来保留过程的灵活性。

    你不能通过在项目过程中简单使用具体的指导来创建一个一个有效的项目计划。项目计划本身需要是一个迭代的过程，包括对当前风险、进度、测试结果等等进行评估以为下一阶段的迭代的详细计划收集输入。

    这也意味着项目的检查或者审计不应该主要的关注验证是否项目团队已经制造了一系列的产物或者执行了一系列的活动。相反，审计应该瞄准在识别和验证风险和确认 适当的产物和活动被完成以降低风险上。审计也应该检查以前的问题以识别出公共的失败模式，并且建议过程的修改以保护将来的最小失败的可能性。

    客户的新思想

    使用传统的软件开发方法的客户期望在开发工作中有最小的投资。他们想预先指出所有的需求，确定一个固定的价格，然后等待最终系统的交付。经常的，会产生在期望值和实际交付系统之间的非常大的差距 — 解决方案并没有满足客户真实的业务需要。

    通过转向迭代开发，改变客户和开发团队之间的交互模式，客户和开发团队都可以避免大量的痛苦。在一个迭代开发的项目中， 客户应该是构建应用团队中的不可缺少的一部分。客户与开发团队的其他成员协同工作以确保最终交付的应用系统满足被需要的业务价值。客户的组织应该尽可能的保持与开发团队之间交互的兴趣，以确保开发团队可以理解他们应该构建什么和项目中具有什么样的风险和问题。如果客户没有帮助指导开发的工作，开发团队可能会开发出错误的应用 — 每个人都会蒙受损失。

    在迭代开发的模式中，客户不能仅仅指出他们所预期的然后就等待系统交付。不论他们怎么清晰的定义，所有的需求都从属于众多的说明和可能的实现。对开发团队来说，与其生成更加详细的需求，还不如投入时间更加频繁和有效的与项目的关键投资人（包括客户）进行沟通。那么，当客户查看演进的应用时，他们将获得应用应该做什么的更好的理解，并可以提供有建设性的建议以改进系统。同时，如果在项目中业务要求发生快速的变化，需求也需要随之发生改变。

    客户也可以从公开协商迭代式的和约中受益，一个叫作 累进的获取得方法。使用这个方法，首先双方可以为整个项目协商一个大致的协议作为描述双方管理商业关系的合法的指导。然后项目被划分为两个或者更多的子和约。早期的和约基于时间和所需的资源指明了款额，因为任何一方都不能足以知道整个方案和可能的开发成本以作出合理的预先承诺。后来的和约式固定的价格，它最小化了双方对应该的交付产物的不一致。

    结论

    我们已经讨论了对软件开发采用迭代的方法不仅仅简单的需要遵循一系列的指南。迭代开发和支持迭代开发的现代技术改变了软件开发游戏中的规则，并使许多在过去战统治地位的公理失去了效力。成功的从瀑布型的方法向迭代的方法转变要求软件开发团队在个人的责任和如何与团队其他成员交互上发生了变化。换句话说，它要求在多中角色团队成员的行为和价值上作出明显的和持久改变。

    只有每一个团队成员都能够理解迭代开发需要做的必要的改变的基本原理，组织才能够实现这些变化。在每一个项目的开始，对于项目团队来说，公开的讨论我们在本文中的迭代开发训练部分已经讨论的必要的行为和有感知的变化是有益处的。本文可以作为这些讨论的出发点：项目团队应该赞同这些思想上的改变和上面针对他们特定项目讨论的实践。

    基本上，本文是关于如何通过使用迭代开发的方法和通过确保整个团队共享项目的远景建立“正确的”软件的，并讲述了你应该如何与团队紧密的合作来实现这个远景。项目经理能够在工作过程中鼓励这种变化，但是它最终建立在团队成员接受和有效的实施是些变化之上。