|
对一个项目来说迭代增量模式的工作意味着什么？在这一系列文章中，我们通过讨论关联于项目的不同视角对这个问题进行探讨。在本系列文章中，定义了迭代式增量开发模式的意义，并且讨论了这种方式对从事软件生产的核心开发团队意味着什么。然后侧重于当一个项目选择采用迭代式增量开发工作时，对客户意味着什么，最后探讨对项目管理团队来说迭代式增量开发的影响。项目管理者联盟
本文为三篇连载之一，在本文中，讨论了迭代式增量开发对一个项目及其团队成员来说意味着什么。作者考虑到了团队成员的感觉。 club.mypm.net
对一个项目来说迭代式增量模式的工作意味着什么？在这一系列文章中，我们通过讨论关联于项目的不同视角对这个问题进行探讨。在上一篇文章中，我们定义了迭代式增量开发模式的意义，并且讨论了这种方式对从事软件生产的核心开发团队意味着什么。在本文中，我们侧重于当一个项目选择采用迭代式增量开发工作时，对客户意味着什么。这个系列在下个月将结束，那时我们将探讨对项目管理团队来说迭代式增量开发的影响。项目管理培训
为了达到迭代式增量开发的完整效果，我们必须确保它的采用将能够不仅仅对技术和开发团队产生影响。实际上，对迭代式增量开发的采用在理想情况下对所有关联于此项目的业务人员具有深远并持久的影响。它还从根本上改变了这些人员指定以及实现这些源自成功的软件解决方案开发的方法。项目管理者联盟
如果对迭代式增量开发的采用没有对业务以及由迭代式开发所提供的效益实现产生影响，那么对其的采用就变成了仅仅是一个技术上的保证，而不能对开发团队本身产生外部作用。为了能够释放它的全部潜能，解决方案必须改变项目方法及其与投资者的交互。club.mypm.net
大部分关于迭代式增量开发的文献着重于开发者以及开发团队领导。虽然对于开发团队的影响是极其重要的，但是迭代式增量开发的真正价值在于它能够极大提高业务效果。为了达成这些益处，业务 ―― 包括 1）用户视角，2）业务分析团队，3）系统终端用户，以及4）业务领导人（发起人） ―― 必须成为项目中的积极参与者并且将需要改变他们的工作方式以和开发团队进行交互。我们将在本文中探讨这四个用户视角中的要素，以及这种被迭代式增量开发采用所表现的改变是如何对业务整体产生正面的影响的。转自项目管理者联盟
用户代表
软件开发项目团队所采用的迭代式增量开发解决方案深深的改变了用户代表与项目开发团队之间的交互方法。正如图2－1中所示的那样，每次迭代都将给开发者呈现一次能够引起对适合的解决方案以及将要得到的业务效果目标反馈的机会。通过基于系统工作版本的反馈，并聚焦于反馈的沟通，允许开发者将注意力集中于能够满足系统实质最小限度特性的解决方案。项目管理者联盟
 项目管理者联盟
图2－1：各次迭代产生的演示版本允许客户代表提供迭代目标的反馈项目管理者联盟
各次迭代还为用户视角提供了一个机会以对进行中的工作进行评论，同时能够对未来的开发趋势产生影响。一旦他们回顾了一个能够表明他们的需求决定以及开发团队对这些需求理解的工作发行版本，客户将决定如何修改项目方向或是划分剩余需求的优先次序。再一次，通过演示少量的运行功能，团队可以着重于一个精确的业务解决方案的组成部分以及为了达到这个目标的最小功能需求数量。在每一次迭代的边界，客户代表具有接受或拒绝开发团队所生产发布的机会并且可以调整进行中项目的发展方向。这使得客户团队可以更好的关联于项目并且保证了解决方案可以得到期望的业务收益。 项目管理者联盟
快速的开发周期，演示以及评估为客户代表提供了很多机会以关联于项目。这种迭代式的解决方案允许他们：bbs.mypm.net
在指导项目的过程中，执行更活跃、更客观的职责，在项目进展中积极的对其进行指导以确保每一个关联于项目的人都能够集合在一个共享的对适宜业务解决组成部分的理解。
采用一个适合于风险数量的项目关系并信任其是处在一个互相合作的部分中。
遵照至今为止从他们的经验中所学到的教训进行工作。
维护一个客观的对项目风险以及进展的评估。
建立团队交付能力的信心。
正规的演示同样可以使开发团队获益，给他们提供了逐步增加的能力：项目管理者联盟
将项目作为一个整体进行理解
对他们能够会聚于一个可接受的业务解决方案的证据
对他们计划的可接受性保持自信
关于用户需求现实的期望
带来的结果是开发项目将不再是一个倾入金钱的黑洞，然后在未来的一个含糊不清的指定时间产生出软件产品。如果承诺的沟通以及理解并不能从初始迭代产生，那么将可以采取行动重新指定项目的方向，或是如果需要的话，取消它。这为业务提供了一个客观的方法以监控并调整它的投资。service.mypm.net
业务分析师
在业界存在着一些关于需求工作是否应该算作迭代过程一部分的不同意见。在我们的经验中，迭代式增量开发的真正收益只有在所有团队成员，包括那些关注业务的人，能够积极参与到项目中时才能够实现。这意味着需求过程需要被紧密的集成，按照与解决方案的迭代式开发同样的时间表运行。项目管理者联盟
考虑如下观察：项目经理博客
对不能够被交付的需求进行归档是没有意义的。当你仅仅关注于那些完成目标绝对需要的工作时，按时并在预算内交付解决方案是十分困难的。花费时间去开发那些将不会被交付的工作是一种分心的事物，并且导致项目风险。不要仅仅假设这些额外的工作“将对下一个项目产生帮助”，我们建议把这种工作留到可以获得收益的项目。请记住当一个项目没有达到它的目标时 ―― 被不必要劳动所提高的可能性 ―― 通常来说并不存在“下一个项目”。PgMp.mypm.net
对开发者来说在他们开始工作之前他们并不需要所有的需求可用。他们仅仅需要足够驱动他们当前工作的足够的需求（在本案例中，就是当前迭代）。
既然不是所有的需求都是内在关联的或是同等重要的，在所有的需求都被完成之前同样存在着极大量可以在系统上被完成的工作。一个开发团队可以很容易的在所有用户接口都被设计好以前进行并解决关于系统能够支持1000个并发用户的问题。实际上，典型的用户接口设计只有很少或根本没有影响到解决方案的可扩展性。pmp.mypm.net
需求工作趋向于进行扩展以填充可用的空间。对大多数项目来说，人们构思出新需求的能力很容易超过任何团队能够在时间以及预算配额内发布他们的能力。 www.mypm.net
Parkinson's 法则1“工作如此扩展以至于占据了所有完成它的可用时间”。没有什么比需求相关工作更真实的了。我们从来没有看到任何一个团队在被分配给他们的时间被用完之前声称他们已经找到了需求的全部集合。如果在时间运行完之前需求团队确实找到了足够充分的集合，在这种情况下，他们总是继续发明更多的需求而不是声明任务已经完成。 bbs.mypm.net
与完成需求的工作相比，定义需求基本上并不需要花费什么努力。定义需求的真正艺术并不是尽可能多的确定，而是找到能够满足业务问题的最小需求集合。更多的需求并不好，并且许多解决方案都由于具有太多的特性而被毁掉。
藏在所有迭代式增量软件开发过程之后的一个基本的断言是相关的仅仅是那些能够对发布的解决方案产生影响的事物；任何不能对解决方案发布产生贡献的都是多余的并且需要被去除的。一个迭代的目的是要产生一个解决方案的工作版本 ―― 虽然通常只是一个部分版本。为了这个目的，需要清楚的知道将要被此次迭代所实现的需求。这并不是意味着在开发迭代开始之前我们就需要知道所有最终要被满足的需求。而是我们需要努力充分的理解需求以建立对当前迭代来说有意义的目标。项目管理者联盟
对驱动一个迭代式开发项目的需求开发来说存在着数个模型。让我们探讨如下四个常用模型：瀑布式，前向－装载需求/后向－装载开发，需求管道，以及实时需求。 service.mypm.net
瀑布式需求，迭代式解决方案开发
在这种情况中，所有需求都在解决方案的迭代式开发开始之前预先进行定义。这种模式被示于图2－2中。PgMp.mypm.net
 training.mypm.net
图2－2：预先定义需求的开发迭代项目管理者联盟
|
