(三)实践迭代
在了解了分阶段开发软件的基本思路之后，紧接着就需要考虑实施的问题。分阶段开发最难的，并不是在过程的控制上，而是在软件设计能力上。
应用迭代的问题
有一则故事说的是一个人肚子疼，去看医生，医生给他开了眼药，理由是眼神不好，吃错了东西，所以才会肚子疼。软件开发中出现的问题往往不是单纯的问题，头疼医头，脚疼医脚的做法未必适合于软件开发。
应用迭代并不是一件简单的事情，懂得了迭代和增量的概念，并不等于你能够用好它们。为什么这么说呢？很多的软件组织尝试着运用迭代开发，但是结果却不尽人意，于是将问题怪罪在迭代的方法不切实际上。软件工程中有句著名的话?quot;没有银弹"。迭代和增量也不是什么银弹。要想做好迭代，缺乏优秀的软件设计思想和高明的软件设计师的支持是不行的。在XP中，非常强调各项实践的互为补充。在我看来，迭代能够顺利实行的思路需要重构、测试优先、持续集成等的直接支持。而这些实践，体现了软件设计和软件过程中的关系。
迭代实践出现问题往往是在项目的中期。这个时候，软件的主体已经形成，代码的增长速度也处于一个快速增长的情况。这种状态下的软件开发对变化的需求是最没有抵抗力的，尤其是那些设计本身存在问题的软件。软件开发到这个阶段，代码往往比较混乱，缺乏一条主线或是基础的架构。这时候，需求的变化，或是新增的需求导致的成本直线上升，项目进度立刻变得难以预期，开发人员的士气受到影响。
迭代之外的解决方法
在这个时候，软件组织要做的，并不是在迭代这个问题上深究下去，而是应当从软件设计入手，找到一种能够适应变化的软件设计思路或方法。例如，你是否应该考虑在面向对象领域做一些研究呢？面向对象的思路很注重将变化的内容和不变的内容相区分，以便支持未来的变化和应对不确定性。然后你再来考虑相应的成本。
做好迭代有几个值得注意的地方：
代码设计优化
软件开发的能力并不体现为代码量的多少，而是体现为代码实现的功能，代码的可扩展性、可理解性上。所以对代码进行不断的改进，对设计进行不断的改进（具体的次数根据需要而定），使软件的结构比较稳定，并能够支持变化。这是迭代的一个前提。否则，每一次的迭代都花费大量的精力来对原先的设计进行修改，对代码进行优化，这样的迭代效率是不高的，也可以视为一种浪费。坚持不断改进软件质量的做法其实是将软件的集中维护、改进的成本分摊到整个过程中，这种思路，和全面质量管理的思路是非常类似的。XP中的重构实践有一个修饰词，称为无情。这充分表现了XP的异类，但是应该承认，只有设计和代码的质量上去了，才能够为后续的迭代过程打下一个基础，更何况，XP所处的往往是一个不确定的、变化多端的环境。正是因为这种环境对软件开发有着很大的影响，因此代码质量也被高度的重视。不同的行业，不同的项目，需要根据自己的特征进行调整，但是，只有保证代码的优美性，才能够顺利地达成迭代的目标。
文章来源于领测软件测试网 https://www.ltesting.net/
