迭代开发-转载！

软件工程的“迭代式开发”已经逐渐取代“瀑布式开发”成为主流。所谓“迭代式开发”，根据我的理解说白了就是象爱因斯坦那样做小板 凳，终极的理想板凳就是不断修正前面板凳错误的后一个板凳，“最好的是下一个”。“迭代式开发”与“瀑布式开发”存在本质的不同，传统“瀑布式开发”的出 发点是务求各个开发阶段的成果都是最优成果，无需变更。而“迭代式开发”则是假设各个阶段的成果都有优化、变更的余地。我们采取了“迭代式开发”，当前工 作围绕的核心是如何使未来的变更、优化变得容易。

应用“迭代式开发”，公司的产品战略是可以通过N次迭代实现，问题是资本的耐心常常是有限的，产品经过趋向于无穷大的N次迭代肯定会日臻完美，但我们必须使资本在每次迭代中看到利润。换句话说，产品的开发必须结合商业成功的良性循环中。

 

在先启阶段的最初迭代中，由构思新项目开始项目管理工作流程，其间，将创建并复审最初的前景、商业理由和风险列表工件。目标是获得足够的资金，以便继续进行限定规模和计划等重要工作。

创建了软件开发计划初稿，并通过最初的迭代计划启动项目。使用这个最初的授权，可以继续针对评估项目规模和风险中的前景、风险列表和商业理由进行工作，以便为充实制定软件开发计划中的软件开发计划建立稳固的基础。

在完成软件开发计划的制定后，应当对项目的风险和可能的商业回报有足够的了解，以便作出明智的决定，为先启阶段的其余部分争取资金，或放弃该项目。在这里，项目管理工作流程将合并到所有后续迭代的公用流程。

在计划下一次迭代中，项目经理和构架设计师决定在下一次迭代中要改进或实现的需求。在早期的迭代中，重点是发现和改进需求；而在后期的迭代中，重点 是构建软件来实现这些需求。 迭代计划在管理迭代中执行，管理迭代最后以对迭代的评估和复审而结束，判断是否已经实现了迭代的目标。如果迭代明显无法达到目标，并且已断定在随后的迭代 中无法恢复项目，则可以通过迭代验收复审来判断是否应当终止项目。

另一种选择是，可以在迭代的中点附近进行迭代评估标准复审，对迭代测试计划进行复审，这时，测试计划应当是明确的。通常，这种可选的复审只用于长期（六个月或更长）迭代。它使项目管理人员和其他涉众有机会进行中期更正。

在进行管理迭代的同时，将在监控项目中执行每天、每周和每月的例行项目管理任务，其间，将监测项目的状态，并在出现问题和错误时进行处理。

当某个阶段的最后迭代完成时，作为阶段收尾的一部分，将进行主要里程碑复审，并假定项目将继续进行，对下一个阶段作出计划。在项目结束时，作为项目收尾的一部分，将进行项目验收复审并终止项目，除非复审确定所交付的产品不可接受，这种情况下，要计划进行下一次迭代。

在迭代评估和验收复审之后、计划下一次迭代之前，将在评估项目规模和风险中重新检查前景、风险列表和商业理由，同时要清楚，有可能需要根据上次迭代的经验重新确定预期目标。在计划下一次迭代中进行详细计划，然后开始下一次迭代。