软件开发中的每个人都应该对变化有着充分的准备。从事软件业的人大都充满了自信， 系统分析师会认为自己可以把所有的需求搞清楚，设计和开发人员会觉得他们做出来的东西完美地实现了需求。所以，如果我们对一个开发人员说：某某，你过去做的这个模块不能用了，我们现在需要重新做起，通常我们会得到积极或者消极地抵制。
应该让人们认识到：变化并不是对过去工作的否定，而是着眼于未来，使工作更加完善的必要手段。无论是需求，设计还是程序代码，你不可能一次性就把它们做到完美，而只能通过不断的修正，让它趋近于完美。这个过程就是所谓的“重构”。
有些 团队为了保持开发的稳定性，会 “冻结需求”。所谓的冻结，也就是说在一段时间内要客户方代表承诺不对已经开发中的需求进行变动。如果你打算做这件事情，首先必须意识到，需求本身就是需求，它是不会因为一个承诺就真正地“冻结”了。如果目前的需求定义并不能反映用户真正的愿景，在冻结的周期过去以后我们仍然需要对已经做完的工作进行修改。当然，如果需求变化太频繁，在某些时候有必要对需求进行冻结以便让开发更加平稳，同时也给软件开发者和客户一个反思的时间。但如果是需求分析工作方法有误，那就有必要作一些检讨了。
要适应变化，我们需要让客户和开发团队有心理上的准备，从而能够以认真的态度来对待它。还需要有正确的方法来应对变化，比如对变化的成本估算，效果的跟踪，如何快速有效的对各种变化进行反映等，这是我们必须注意的问题。
周期
很多人简单的把迭代理解为开发的分阶段进行。有些 项目经理会这样说：我们打算通过4次迭代完成软件的开发，第一次迭代，完成需求分析和软件设计，第二次迭代，完成多少多少模块的开发，第三次，完成其他多少模块的开发，第四次，配置，部署，上线，测试，修正软件bug。在这里，虽然他们言必称“迭代”，但是这样的迭代和过去传统的瀑布型开发有多少区别？
迭代开发是要分周期分阶段地进行，但是不能认为简单地把开发周期划分为几个不同的阶段就是迭代。
很多人对于迭代周期有一些误解，比如：
认为迭代只适用于开发阶段，而需求分析和设计工作则不在此范围内。
认为迭代周期可以拉得很长，比如两个月，三个月，甚至一个季度，半年。
将需求分析，设计，开发，测试，部署，用户反馈，修改当作完整的迭代周期，并要求在前一阶段工作完全（或者大部分）完成以后再进行下一步工作（迭代）。
在一个迭代周期内，我们可以做什么事情呢？可以说：所有的事情。如果你认为迭代需要在需求分析完成之后才能开始，或者系统集成必须在所有迭代完成之后才可以进行，你会获得一个真正的瀑布流程开发。
一个迭代周期意味着对一些特定功能（用例）的探索。“探索”一词可能随情况不同而有不同的含义。对于抽象级别较高，模糊程度比较高的用例，我们需要通过和用户的讨论将它逐渐分解为更加清楚和清晰的用例。对于目前我们认为已经得到了详细定义的需求，需要选取合适的部分进行设计和实现，通过这些部分的实现，对需求定义和技术可行性进行反馈。对那些在上次迭代中已经开发完的模块，应该尽可能快速地让用户提出他们的意见，以便了解是否真正解决了用户面临的问题，以及还有没有可以改进的方面，再根据这些意见安排下一阶段的工作。
我们是否可以在开发进行之前把需求或者设计全部弄清楚呢？我认为很难。因为通常来讲，用户对于自己的需求只有一个模糊的概念。让我们假设一个饮食业的例子，有一天餐厅经理把你叫入办公室说：马上设计一个新的菜谱，这个菜谱是为某某特定人群定制的，你要让这些人感觉色香味俱全。不过在你把配料和烹调方法都设计出来之前，我们不打算让大厨来具体做这道菜，我们不允许失败，所以你的设计一定要一次成功，你可以用调查问卷，用户面谈等方法获取最终用户的需求，但是记住：你不能去做这道菜。
这样的事情你可能会觉得很滑稽，但是在软件业，类似的事情人们却认为是天经地义的。
迭代允许我们将开发本身也作为需求探索的一部分，通过用户对已经实现功能的反馈我们和用户都会逐渐明白什么样的软件是我们最终想要开发的。所以，不要等到所有（或者大部分）的分析完了才开始开发，而是尽早对已经捕获到的需求进行细化，尽早开发，以获得反馈。
在安排迭代计划时，应该指明，这次迭代的目标是什么，在结束时应达到的里程碑是什么。如果有任务提前达到了这个里程碑，我们可以提前结束迭代，或者顺便在剩下的时间内安排其他的任务，但是要注意这种安排的合理性，不要因为这个而使得迭代周期被延长。
在一次迭代到达所设定的结束日期时，就必须审视各项任务是否达到了里程碑的要求，如果有任务没有达到，原因是什么，我们是否需要对需求和技术方案做出调整。对于没有达到里程碑要求的任务，我们可以采取的办法有两种：
文章来源于领测软件测试网 https://www.ltesting.net/
