从开发团队领导者的角度来看，迭代并不仅仅是一个包括分析，设计以及实现的核心开发活动的周期。迭代是一个有代表性的小型项目，以得到软件产品的有意义的新发布版本。项目管理者联盟
图1-3说明了如何利用一组独立的开发人员的工作来制造一个完整的发行产品，并使得所产生的改进请求以及需求定型的反馈对下一次迭代发生作用，并将其包含到下一次发行版本中。
图1-3：从开发团队领导者角度的迭代(引自Agile and Iterative Development, A Manager's Guide, by Craig Larman, Addison-Wesley, 2004.)
迭代的目的是将整个开发团队的工作集成到一个稳定的，完整的，可测试的系统发行版本中。对大多数迭代来说，这些发布版本为内部发布－主要为开发团队所建立的基线，并且为迭代以及对所做出的进展进行度量提供关闭条件。这些只是内部发布版本，而并不是为用户所开发的。 项目管理者联盟
典型地，在软件公共发布版本之前，存在着三次或更多次的迭代。在此序列中的每次迭代过程审查系统发布产品，从第一次迭代中的小型的，部分实现的系统，通过一次又一次地迭代，逐次增长地实现更多需求，直至产生出最终地客户发布版本。图1-3距离说明了代表产品发布的每次循环中的增长幅度。
将开发者及团队领导者视角相关联 service.mypm.net
项目管理者联盟
对于许多开发者来说，迭代的增量开发是一个通过无穷级数的迭代进展过程，每一次迭代都会是系统变得更庞大，直至客户对其满意，或是决定停止对后续开发的投资。从这个角度来说，只要工作在持续进行，并且能够对产品做出持续改正，项目就在继续发展中。 项目管理者联盟
从团队领导者角度来说，为了能够有所进展，数个开发者的工作必须被联合并集成在一起，或者可以成功的协同工作。图1-4表明了这种整体的，在多个迭代中对于项目进展的开发团队的观点。项目管理者联盟
图1-4：每次迭代与前一次迭代相比，均生成了更完整的发布版本。
在图1-4中，项目进展以开发团队对完整的，可运行的发布版本的完成情况所度量，而不是采用对规范说明或其他文档的完成情况。在每一迭代中，应用软件的完成情况通过对完整应用中可以被展示的已完成的需求条目来计算，着重于对一个可运行的产品发布版本，而并不是一组项目文档或是还未被集成的组件。 项目管理者联盟
项目管理者联盟
对团队的进展需要对完整的发布版本作为一个整体来考虑，这一点是极为重要的。我们见证了着数个这样的真实项目，其中大量的组件被开发者所建立并测试，然而却不能被集成进一个甚至仅仅是部分完成的产品。在这些案例中，显示于图1-4中的项目视图从未发生过，因为并不存在任何客观凭证以证实对这种已完成的的项目做出了任何进展。
计划制定的需要项目管理者联盟
项目管理者联盟
为了集成多个开发人员的工作，需要完成数个计划编制。首先，需要将工作以最小化开发人员间相互依赖的方式分配给开发者，采用这种方式，即使开发者确实需要依赖于另外一个开发人员，他们也可以在一定程度上独立地进行开发工作。 pmp.mypm.net
第二，他们必须采用一种方案以对他们的相互依赖关系达成一致；例如他们必须对组件，函数调用以及参数等的命名保持一致。随着依赖关系数目的增长，团队最终会达到这样一个点，在这个点上团队成员间非正式沟通也许需要使用开发人员间一致约定的记录。
当复杂性增加时，并且，随着为了使团队间成员有效协作而需要做出的努力变得越来越复杂，团队领导将需要一种能够确定什么工作需要完成以及以什么顺序完成的方法。这带动了对更规范的计划制定的需求，这也依次导致了对预算的需求。由于时间计划不能再简单的通过对非常复杂的组件（这种情况中，所有组件都是不互相依赖的）预估开发时间，或是对所有组件（这种情况中，所有组件相互依赖，他们仅可以依次的对其进行工作）的开发时间求和的方式所决定，在不同开发者的组件间存在着相互依赖，这也导致了对更规范计划制定的需求。必须要理解组件之间的依赖关系以建立一个有效的时间计划方案。
迭代化的开发有时被认为在很短的时间上执行，以至于不需要进行计划制定或预估。这种观点是不正确的；这有点像既然说我们在一个时刻仅仅进行一步活动，我们完全可以对下一步应该转向哪里做出连续的决定，因此我们没有必要计划我们的路线。如果你并不关心你将会在哪里结束，这种策略可以很好的运行，然而人们对项目有所付出时，他们当然对项目将要达成的目标有所期望。
计划以及预估基本上是这样一种机制，首先，决定项目值得去做，然后作为一种方案，保持项目始终处于轨道中。至少，在某种程度上，很少有人会在不知道花费或是不知道持续时间的情况下雇佣某人以修整他们的房屋。软件开发项目也没有区别，为项目投资的人需要知道这个项目的开销以及结束时间。这都需要计划与预估。在下两篇文章中，当我们从客户以及团队管理的角度进行探讨时，我们还将返回到这个主题。
结论项目经理博客
为了理解如何能够达到迭代化的，增量的开发过程所保证的优点，正确认识它是如何影响到项目相关的所有人是很重要的。在本篇文章中，我们可以看到迭代化开发是如何影响到软件生产人员，即核心开发团队成员的，但是这仅仅是项目所关联的一部分人员。如果你们想使迭代化项目真实地产生效果，你们还必须理解迭代化的，增量的开发过程是如何影响到其他成员的，同样重要的，还要包括项目的其它领域：客户以及管理者。 项目管理者联盟
我们还将在下两篇文章中探讨这两个观点，采用迭代化的，增量的工作方式是如何影响到客户以及管理者。
注释项目管理者联盟
1 更多的关于Dynamic Systems Development Methodology, 或者 DSDM, 请见 http://www.gamcom.com/dsdmoverview.htm转自项目管理者联盟
2 核心的规律是关于项目管理，需求，分析，设计，实施，测试，开发，配置管理和变更管理。 项目管理者联盟
3 通过本系列我们将会使用“实施”来指开发的规律。项目经理圈子
英文原文
作者简介项目管理者联盟
training.mypm.net
Lan Spence为Ivar Jacobson Consulting UK的首席科学家。他的主要职责是为建立并运行软件改造以提高他们软件开发能力的客户提供帮助。最后，他专门研究IBM Rational Unified Process的大规模应用，用例驱动，以及所推荐的架构中心解决方案。Lan有着超过18年的软件工业经验，涵盖完整的开发周期，包括需求捕获，架构，分析，设计，实现，以及项目管理。
Kurt Bittner为IBM软件组，Rational软件部门的产品策略进行工作。他已经为找出能够帮助团队软件开发的更好的方法工作了20多年。他是original RUP开发团队的成员，并且在不同的工业界中领导开发关对。当不需要进行软件开发工作时，他喜欢通过攀爬冰瀑的方法进行放松。
Ian和Kurt合作编写了Use Case Modeling (Kurt Bittner, Ian Spence -- Addison-Wesley 2003) 并且他们正在合作进行下一本书籍的编写，本系列文章便是摘自这本书。
pmp.mypm.net
项目管理者联盟
|
