项目经理的新思想
迭代开发方法的一个最重要的区别是他被设计成为在项目的早期将主要的风险去除掉。利用这个差别需要对项目所面临的风险公开而且诚实。同时你逃避风险的自然倾向会使人们推迟处理这些风险，风险不知何故的被忽略 — 就像他们从未发生过。风险就像是传染病：你忽略它越久，它的危害就越大。风险必须在整个项目中被持续的识别并划分优先级；每一个迭代都必须被降低风险的原则性的目标所驱动。 使用这种方法会需要一些文化上的变化。典型的管理形式规定你应该对广大听众避免承认风险，因为人们可能会断定你们在运作一个有问题的项目。这是一个危险的方法：假装风险不存在不会使风险离去。 传统的情况下，项目经理通过询问团队成员什么活动已经被完成来确定项目的状态。他们假设但所有活动都被完成时，项目也就被完成了。但是这种方法经常会导致项目的失败。检查被完成的活动是不好的测量项目进度的方法，因为它并没有对活动的结果的质量进行量化。如果项目经理能够精确的计划项目团队需要做的每一项工作，并且没有会背离项目计划的事情发生，这种方法可能会满足项目的需要。然而，就像很多项目经理知道的那样，事情很少是按照计划进行的。甚至是如果你创建了更为详细的计划，结果也是令人惊讶的。无论我们如何努力的预期未来，我们也不能预期每一件事情。 基于结果的管理
因为我们不能预测未来，软件项目的经理需要对他们的一些关键的策略进行风险的管理。这需要改变你的测量方法：代替基于完成活动的测量方法，你应该使用基于可演示的结果的方法进行测量。这是基于结果管理的基础。应用基于结果的管理策略意味着将重点放在风险上并正面的处理它。通过特意的结构化项目的活动以处理风险，你可以揭示隐藏的问题，解决问题并稳定的减少项目进程中的不确定因素。 此外，因为一个软件开发项目的主要结果是软件本身，所以你所交付的产物应该是成功的主要量度。你可以使用象一系列被通过的软件测试、代码中的缺陷的数量和他们的精确度等等的矩阵来评估你的软件。换句话说，移到迭代开发就意味着要通过根据指定目标和需求产生的的测量可演示的结果，而不是通过计算有多少活动、产物或者工作产品被完成来评估项目的状态。为了评估项目的稳定性（有效管理的另一个量度），你也应该跟踪需求、设计和代码中的冗余。 更少的也许是更多的
早期，我们注意到添加详细的信息到需求也许不总是对项目有益的。对其他类型的文档也是同样的。你的质量保证计划、软件开发计划或者需求管理计划都不是项目健康的良好量度。太详细不总是更好的：你应该调整你特定项目需要的文档详细级别。决定合适详细级别的方法是关注风险和结果：如果你添加详细信息到某一产物可以减少风险或者改进特定结果的质量，那么这个投入是值得的；否则，在更有生产力的活动上花费时间是更好的。 使用瀑布型的方法项目经理需要付出很多的注意以详细的计划和指定需求。而使用迭代开发的方法项目经理可以根据工作中的风险来权衡的将时间花费在细化需求、架构、设计和实现上。他们会问：“什么样类型的活动可以最有效的立即降低风险呢？” 也许原型化一个方案可以处理与项目客户买进相关的风险，或者也许他们需要实际的设计、实现和测试架构以完全的处理架构方面的风险。 使项目中的每一个成员都参与到质量保证中
对于项目经理来说移到迭代开发方法需要的其他思想的改变是开始将质量保证作为一个集体的职责考虑。我通常会惊讶的听到项目经理说“我需要测试小组对我的开发人员保持忠诚，”或者“如果分析人员没有写下单个的需求，他们将不会被实现。” 当然，你的确需要测试小组来建立高质量的应用，并且失败的文档化和跟踪需求将导致问题的出现。但是如果开发人员不把质量当作自己的责任，你也就会陷入到质量问题中。为了实现这一点，你需要从通过信任你的团队和清晰的交流你们的预期开始。假如你不能信任这些人，那么也许这些人不应该属于你的团队。 理想的情况下，项目经理应该能够宣称“我的开发人员负责交付高质量的代码；为了帮助开发人员，我们有一个测试团队，测试团队有专业的能力并可以验证被交付的代码是否是高质量的，”并且“我们的开发人员负责实现满足最终用户需要的应用。为了帮助开发人员，我们有一个分析的团队在适当的详细级别上文档化需求，并且分析人员是开发人员和最终客户之间的桥梁。” 创建交能够协同工作的团队 — 也就是说使团队中的分析人员、开发人员和测试人员能够一起工作来实现高质量的结果 — 是成功的迭代开发的关键之一。
 此主题相关图片如下：
|
项目型组织
项目管理
工程项目
科技项目
资格认证
职业休闲
