项目经理的新思想
公开项目面临的 风险，持续的重新评估风险，并且使用风险来为项目工作进行优先级的划分。
通过衡量可演示的结果而不是一系列被完成的活动来评估项目状态。
在项目的早期，对整个项目开发高层次的计划，但仅仅对当前的和下一个迭代生成详细计划。
根据你如何有效的处理风险的经验，在任何给定的时间上评估你在需求、架构、设计、实现和测试上的投入。
信任你的 团队。给他们足够的知识和职责让他们全全负责产品的质量。帮助他们团结在一起工作。
项目经理的新思想
迭代开发方法的一个最重要的区别是他被设计成为在项目的早期将主要的风险去除掉。利用这个差别需要对项目所面临的风险公开而且诚实。同时你逃避风险的自然倾向会使人们推迟处理这些风险，风险不知何故的被忽略 — 就像他们从未发生过。风险就像是传染病：你忽略它越久，它的危害就越大。风险必须在整个项目中被持续的识别并划分优先级；每一个迭代都必须被降低风险的原则性的目标所驱动。
使用这种方法会需要一些文化上的变化。典型的管理形式规定你应该对广大听众避免承认风险，因为人们可能会断定你们在运作一个有问题的项目。这是一个危险的方法：假装风险不存在不会使风险离去。
传统的情况下，项目经理通过询问团队成员什么活动已经被完成来确定项目的状态。他们假设但所有活动都被完成时，项目也就被完成了。但是这种方法经常会导致项目的失败。检查被完成的活动是不好的测量项目进度的方法，因为它并没有对活动的结果的质量进行量化。如果项目经理能够精确的计划项目团队需要做的每一项工作，并且没有会背离项目计划的事情发生，这种方法可能会满足项目的需要。然而，就像很多项目经理知道的那样，事情很少是按照计划进行的。甚至是如果你创建了更为详细的计划，结果也是令人惊讶的。无论我们如何努力的预期未来，我们也不能预期每一件事情。
基于结果的管理
因为我们不能预测未来，软件项目的经理需要对他们的一些关键的策略进行风险的管理。这需要改变你的测量方法：代替基于完成活动的测量方法，你应该使用基于可演示的结果的方法进行测量。这是基于结果管理的基础。应用基于结果的管理策略意味着将重点放在风险上并正面的处理它。通过特意的结构化项目的活动以处理风险，你可以揭示隐藏的问题，解决问题并稳定的减少项目进程中的不确定因素。
此外，因为一个软件开发项目的主要结果是软件本身，所以你所交付的产物应该是成功的主要量度。你可以使用象一系列被通过的 软件测试、代码中的缺陷的数量和他们的精确度等等的矩阵来评估你的软件。换句话说，移到迭代开发就意味着要通过根据指定目标和需求产生的的测量可演示的结果，而不是通过计算有多少活动、产物或者工作产品被完成来评估项目的状态。为了评估项目的稳定性（有效管理的另一个量度），你也应该跟踪需求、设计和代码中的冗余。
文章来源于领测软件测试网 https://www.ltesting.net/
