介绍

知道所有利益相关人的需要、了解所有的风险、理解所有的项目技术，或者知道如何和同事共事，通常是不可能的。即使知道所有这些事情，在项目的生命周期中它们也会发生变化。 促进那些允许团队展示增量价值，以及尽早且持续的获得利益相关人反馈的实践。

这一原则背后的意图是不断的获得反馈，以及改进团队的产品和过程。当你提供或创建了持续反馈和改进的结构或心态时，将更容易接纳变更。此外，将尽早并经常的获得反馈，也将尽早的面对项目中高优先级的风险。通过不断的识别和攻击风险，将对项目的进展和质量更有信心。

不仅产品在演进，团队也将发现更好的共事方式，并获得利益相关人的参与。通过吸取经验教训，可以调整项目遵循的过程，以及项目的步伐和需要。

实践

以迭代的方式开发项目

使用单一、线性的方式开发系统是困难的，因为，这将使合入变更和新的知识变得昂贵。更糟糕的是，这可能导致延迟发现并减缓风险，因为在生命周期中计划的开发工作滞后于这些情况的发生。

将项目划分为一系列“时间盒”迭代，并以迭代的方式规划项目。这个迭代的策略可以使你增量的交付功能（例如可执行、可重用的已实现并测试过的需求子集），这些功能可以由利益相关人在迭代结束时进行评估。这提供了快速且及时的反馈循环，从而使问题得到解决，并使得改进的成本更低。同样，这些是在你仍旧拥有足够的预算和时间的情况下完成的，并且你没有在要求的主要返工前走的太远。

迭代开发使得团队能够在开发生命周期中持续的改进软件。

聚焦迭代于下一个管理里程碑

当风险和未解决的问题堆积如山时，项目可以获得进展。聚焦于关闭那些重要的项目问题（例如利益相关人确认范围，并证明建议的架构）。

将项目划分成不同的阶段（如初始阶段、细化阶段、构造阶段和交付阶段），每个阶段有一个清晰可见的管理里程碑。每个阶段中的每个迭代的焦点都是到达这些里程碑。

管理风险

延迟处理项目中困难和有风险的问题将明显的增加项目失败的风险。这种拖延可能导致在错误的技术上投资、糟糕的设计，或者一组不能解决利益相关人需要的需求。

尽早攻克风险，否则它们将攻击你。持续的识别风险并排序优先级，然后制定措施减缓这些风险。确定迭代的焦点基于风险。例如，架构上重要的风险应该尽早在项目中解决，最迟在细化阶段结束时，此时架构已被证明并基线化。

更多信息，参见指南：Managing Risks

拥抱并管理变更

变更是不可避免的，并且变更出现时也意味着增强利益相关人价值的机会。无约束的变更将导致臃肿的、有缺陷的系统，并且不满足利益相关人的需要。更多的，在开发周期后期发生的变更，往往意味着更多的成本。

拥抱并管理变更。拥抱变更有助于构建处理利益相关人需要的系统，而管理变更可以降低成本并提高对变更的预见性。在项目早期发生的变更通常只需花费有限的成本，随着项目的进展，变更将变得越来越昂贵。

为了满足客户需求，通常需要在项目中引入变更，但是必须让客户清楚的知道这些变更对项目成本和进度的影响。了解变更在当前阶段的影响，并防止项目成员在当前迭代中实施破坏性的变更。在当前迭代中，Review并排序变更请求，但不要处理这些请求，而是分派到未来的某个迭代。

如果需要，文档化变更。对于非正式的项目，与利益相关人进行讨论可能就足够了。

客观衡量进展

如果没有客观的了解项目进展，就不能真正的知道项目将会成功还是失败。不确定性和变化使软件项目进展很难被客观衡量，而人们却很容易以主观评判客观。

获取一份客观衡量项目进展的状态视图。衡量进展的最佳方式是交付可工作的软件，这是以一种渐进的方式进行的。你也可以定义一组在迭代中收集的度量目标（例如，被实现和验证的需求数量，发现的缺陷数和已修复的缺陷数比例），并在迭代评估中对它们进行Review。

持续的评估你所做的

定期的，提出问题并验证项目有关的假设。定期的进行团队会议跟踪状态并识别风险和问题。这可以在日常团队收集风险个人工作状态以及识别和解决问题时完成。在迭代结束时，评估所完成的工作的状态，并寻找可以在下一次迭代中改进的领域。在项目结束时进行一次回顾评审，捕获那些可使未来项目以更高效的方式运作的经验教训。

如果我们总是挑战我们的做法，并寻找新的、创新的方法开发软件，我们将改进我们的工作。这也将改进项目的结果。