[转]OpenUP核心原则四：演化，持续演进并且不断获得反馈
演化，持续演进并且不断获得反馈
允许团队尽早从项目干系人获得反馈，并且向他们持续演示增量的价值。
简介
理解所有干系人的需求，关注所有项目的风险，理解所有项目的技术，甚至是了解如何和同事协同工作，完全做到这些通常不大可能。即使是完全熟知上述内容，这些内容也很可能在项目开发过程中发生变更。所以，我们需要提升团队增量演示价值并且尽早从干系人获得持续反馈的实践能力。
提升这种实践能力，这个原则的本质是持续获得反馈，并且同时提升产品质量和改进团队协作流程。只要我们提供一种框架和保持良好的心态持续获取反馈并且持续改进，那么变更将更容易被解决。另外，尽早获得反馈，而且是持续获得反馈，同时在项目早期处理高优先级的风险。
通过这种方式，不仅仅让产品得到不断地演化，这个团队也能探索出和干系人更好的协作方式。团队遵循的流程也能够根据实践的反馈不断得到调整，项目的节奏和需求也不断得到调整。
实践
以迭代的方式开发项目
采用单调线性开发系统的方式通常比较困难，因为在处理变更和项目过程中接触到的新知识时，需要付出的代价很大。更糟糕的是，这种方式导致延迟发现新的需求和风险，因为在项目开展一段时间后才会投入开发工作。
我们应该把项目划分为一系列固定时间限制的迭代，并且以迭代的方式制定项目计划。这种迭代的策略允许我们增量地交付各种能力（例如一组可执行的，部分实现，并且可测试的需求。），可以在每个迭代的最后提交给干系人评估。这种方式提供了快速及时的反馈循环，从而可以让我们以更低的成本处理问题改进质量。这种方式还可以让你在充足的预算和时间的前提下解决问题，而不需要重新开发所付出的工作量。
迭代开发允许团队在整个开发生命周期中持续改进软件。
关注迭代，达成下一个迭代管理里程碑的目标
当风险出现和存在未解决的问题时，项目依然需要持续推进。我们需要关注主要项目问题的闭环（例如与干系人达成一致项目范围，候选架构的验证）
把项目划分为阶段（例如：启始、精化、构建和移交阶段），每个阶段都应该有可视化的、明确的管理里程碑目标。每个阶段内的里程碑都应该集中关注实现里程碑目标。
管理风险
延迟到项目后期才发现困难和存在的风险，这些问题大大增加了项目失败的风险。诸如此类的延期可能导致错误的技术选择、失败的方案，以及一组无法解决干系人实际需要的需求。
我们应该尽早解决风险，否则风险将阻碍你前进。持续识别风险，并且设置优先级，同时想出缓解风险的策略。基于风险考虑每个迭代的关注目标。例如，架构上重要的风险应该在项目的早期给予解决，不要晚于精化阶段，这个阶段架构应该得到验证并且打上基线。
更多的信息，可以参考《指南：管理风险》 // todo
拥抱并且管理变更
变更无法避免，变更同时提供了一种可以增强干系人业务价值的机会，不受约束的变更将导致开发出臃肿不堪、存在缺陷并且无法满足干系人需要的产品。而且，越到项目开发生命周期后期发生的变更越可能导致更大的修改成本。
拥抱并且管理变更。拥抱变更帮助我们构建一个可以实现干系人需求的系统，管理变更允许我们减少成本并且提升变更的可预测性。在项目早期发生变更所需的成本毕竟有限。随着项目逐步开展，变更的成本也逐步增大。
为了满足顾客的需求，一般情况下，你需要在项目中引入变更，不过需要让顾客清楚认识到这些变更对于项目的进度和成本带来的影响。理解当前阶段变更带来的影响，并且规避在当前迭代过程中变更对团队成员的影响。在当前迭代我们需要对变更请求进行评估并且设置优先级，但是不会马上实施变更，而是把变更安排到后续迭代过程中。
如果有必要，把变更以文档形式记录下来。对于一般性的项目，只要和干系人进行讨论即可。
客观地度量进度
如果你无法客观地了解你的项目进度，你根本无法了解到项目正在走向成功还是失败。项目中的不确定因素和变更使得软件项目的难以客观的度量进度，人们往往倾向于采用主观的信息评估目标。
通过客观地度量进度可以清晰的了解项目状态。项目进度的最佳度量方式是可工作软件的交付，我们通过渐进的方式交付这种可工作的软件。我们也可以在迭代过程中定义一组目标度量项（例如，已实现和验证的需求，已经发现问题缺陷和已修复的比值），把这部分内容作为迭代评估的评估项目。
持续地评估我们的工作
定期地进行提问并且验证项目的预设目标是否实现。团队定期地组织会议跟进项目状态并且识别风险和问题。我们可以每天组织团队成员一起分享每个团队成员的工作状态，遇到的问题并且解决问题。在每个迭代的结束阶段，评估任务完成情况，并且找出在下一个迭代里可以处理和改进的领域。在项目结束时进行工作回顾，并且总结所学的经验，从而在未来的项目开展工程中采取更加高效的方式。
如果我们常常对我们所完成的工作提出是否能改进的疑问，并且寻求新的创新方法来开发软件，我们的工作方式将可以改进，从而改进我们的项目结果。
