2010年软考系统分析师：敏捷的迭代频率研究

　　XP提倡迭代周期越短越好(XP建议为一到两周)，这是个不错的提议。在这么短的一个迭代周期内，我们花在架构设计上的时间可能就只有一两个小时到半天的时间。这时候，会有一个很有意思的现象，你很难去区分架构设计和设计的概念了。因为在这么短的一个周期之内，完成的需求数量是很少的，可能就只有一两个用例或用户素材。因此，这几项需求的设计是不是属于架构设计呢?如果是的话，由于开发过程是由多次的迭代组成的，那么开发过程中的设计不都属于架构设计了吗?我们说，架构是一个相对的概念，是针对范围而言的，在传统的瀑布模型中，我们可以很容易的区分出架构设计和普通设计，如果我们把一次迭代看作是一个单独的生命周期，那么，普通的设计在这样一个范围之内也就是架构设计，他们并没有什么两样。但是，迭代周期中的架构设计是要遵循一定的原则的，这我们在下面还会提到。

　　我们希望迭代频率越快越好，但是这还要根据现实的情况而定。比如数据仓库项目，在项目的初期阶段，我们不得不花费大量的时间来进行数据建模的工作，这其实也是一项专门针对数据的架构设计，建立元数据，制定维，整理数据，这样子的过程很难分为多次的迭代周期来实现。

　　可以说，如果一支开发团队没有相关迭代的概念，那么这支团队要立刻实现时隔两周迭代周期是非常困难的，，同时也是毫无意义的。就像我们在上面讨论的，影响迭代周期的因素很多，以至于我们那无法对迭代周期进行量化的定义。因此我们只能从定性的角度分析迭代周期的发展。

　　另一个了解迭代的方法是阅读XP的相关资料，我认为XP中关于迭代周期的使用是很不错的一种方法，只是他强调的如此短的迭代周期对于很多的软件团队而言都是难以实现的。

　　迭代周期的引入一定是一个从粗糙到精确的过程。迭代的本质其实是短周期的计划，因此这也是迭代周期越短对我们越有好处的一大原因，因为时间缩短了，计划的可预测性就增强了。我们知道，计划的制定是依赖于已往的经验，如果原先我们没有制定计划或细节计划的经验，那么我们的计划就一定是非常粗糙，最后的误差也一定很大。但是这没有关系，每一次的计划都会对下一次的计划产生正面的影响，等到经验足够的时候，计划将会非常的精确，最后的误差也会很小。

　　迭代周期的确定需要依赖于单位工作量。单位工作量指的是一定时间内你可以量化的最小的绩效。最简单的单位工作量是每位程序员一天的编码行数。可惜显示往往比较残酷，团队中不但有程序员的角色，还有设计师、测试人员、文档制作人员等角色的存在，单纯的编码行数是不能够作为唯一的统计依据的。同样，只强调编码行数，也会导致其它的问题，例如代码质量。为了保证统计的合理性，比较好的做法是一个团队实现某个功能所花费的天数作为单位工作量。这里讨论的内容实际是软件测量技术，如果有机会的话，再和大家探讨这个问题。

　　我们应用迭代方法的最大的目的就是为了稳步的改进软件架构。因此，我们需要了解架构是如何在软件开发的过程中不断演进的。在后面的文章中，我们会谈到用Refactoring的方法来改进软件架构，但是Refactoring的定义中强调，Refactoring必须在不修改代码的外部功能的情况下进行。对于架构来说，我们可以近乎等价的认为就是在外部接口不变的情况下对架构进行改进。而在实际的开发中，除非非常有经验，否则在软件开发全过程中保持所有的软件接口不变是一件非常困难的事情。因此，我们这里谈的架构的改进虽然和Refactoring有类似之处，但还是有区别的。

　　软件架构的改进在软件开发过程会经历一个振荡期，这个振荡期可能横跨了数个迭代周期，其间架构的设计将会经历剧烈的变化，但最后一定会取向于平稳。(如果项目后期没有出现设计平稳化的情况，那么很不幸，你的项目注定要失败了，要么是时间的问题，要么就是需求的问题)。关键的问题在于，我们有没有勇气，在架构需要改变的时候就毅然做出变化，而不是眼睁睁的看着问题变得越来越严重。最后的例子中，我们讨论三个迭代周期，假设我们在第二个周期的时候拒绝对架构进行改变，那么第三个周期一定是有如噩梦一般。变化，才有可能成功。

　　我们知道变化的重要性，但没有办法知道变化的确切时间。不过我们可以从开发过程中嗅到架构需要变化的气味：当程序中重复的代码逐渐变多的时候，当某些类变得格外的臃肿的时候，当编码人员的编码速度开始下降的时候，当需求出现大量的变动的时候。