经典重读：什么是迭代化开发(2)用户视角

对一个项目来说迭代增量模式的工作意味着什么？在这一系列文章中，我们通过讨论关联于项目的不同视角对这个问题进行探讨。在本系列文章中，定义了迭代式增量开发模式的意义，并且讨论了这种方式对从事软件生产的核心开发团队意味着什么。然后侧重于当一个项目选择采用迭代式增量开发工作时，对客户意味着什么，最后探讨对项目管理团队来说迭代式增量开发的影响。

本文为三篇连载之一，在本文中，讨论了迭代式增量开发对一个项目及其团队成员来说意味着什么。作者考虑到了团队成员的感觉。 

对一个项目来说迭代式增量模式的工作意味着什么？在这一系列文章中，我们通过讨论关联于项目的不同视角对这个问题进行探讨。在上一篇文章中，我们定义了迭代式增量开发模式的意义，并且讨论了这种方式对从事软件生产的核心开发团队意味着什么。在本文中，我们侧重于当一个项目选择采用迭代式增量开发工作时，对客户意味着什么。这个系列在下个月将结束，那时我们将探讨对项目管理团队来说迭代式增量开发的影响。

为了达到迭代式增量开发的完整效果，我们必须确保它的采用将能够不仅仅对技术和开发团队产生影响。实际上，对迭代式增量开发的采用在理想情况下对所有关联于此项目的业务人员具有深远并持久的影响。它还从根本上改变了这些人员指定以及实现这些源自成功的软件解决方案开发的方法。

如果对迭代式增量开发的采用没有对业务以及由迭代式开发所提供的效益实现产生影响，那么对其的采用就变成了仅仅是一个技术上的保证，而不能对开发团队本身产生外部作用。为了能够释放它的全部潜能，解决方案必须改变项目方法及其与投资者的交互。

大部分关于迭代式增量开发的文献着重于开发者以及开发团队领导。虽然对于开发团队的影响是极其重要的，但是迭代式增量开发的真正价值在于它能够极大提高业务效果。为了达成这些益处，业务 ―― 包括 1）用户视角，2）业务分析团队，3）系统终端用户，以及4）业务领导人（发起人） ―― 必须成为项目中的积极参与者并且将需要改变他们的工作方式以和开发团队进行交互。我们将在本文中探讨这四个用户视角中的要素，以及这种被迭代式增量开发采用所表现的改变是如何对业务整体产生正面的影响的。

用户代表
软件开发项目团队所采用的迭代式增量开发解决方案深深的改变了用户代表与项目开发团队之间的交互方法。正如图2－1中所示的那样，每次迭代都将给开发者呈现一次能够引起对适合的解决方案以及将要得到的业务效果目标反馈的机会。通过基于系统工作版本的反馈，并聚焦于反馈的沟通，允许开发者将注意力集中于能够满足系统实质最小限度特性的解决方案。

图2－1：各次迭代产生的演示版本允许客户代表提供迭代目标的反馈

各次迭代还为用户视角提供了一个机会以对进行中的工作进行评论，同时能够对未来的开发趋势产生影响。一旦他们回顾了一个能够表明他们的需求决定以及开发团队对这些需求理解的工作发行版本，客户将决定如何修改项目方向或是划分剩余需求的优先次序。再一次，通过演示少量的运行功能，团队可以着重于一个精确的业务解决方案的组成部分以及为了达到这个目标的最小功能需求数量。在每一次迭代的边界，客户代表具有接受或拒绝开发团队所生产发布的机会并且可以调整进行中项目的发展方向。这使得客户团队可以更好的关联于项目并且保证了解决方案可以得到期望的业务收益。

快速的开发周期，演示以及评估为客户代表提供了很多机会以关联于项目。这种迭代式的解决方案允许他们：

• 在指导项目的过程中，执行更活跃、更客观的职责，在项目进展中积极的对其进行指导以确保每一个关联于项目的人都能够集合在一个共享的对适宜业务解决组成部分的理解。
• 采用一个适合于风险数量的项目关系并信任其是处在一个互相合作的部分中。
• 遵照至今为止从他们的经验中所学到的教训进行工作。
• 维护一个客观的对项目风险以及进展的评估。
• 建立团队交付能力的信心。

正规的演示同样可以使开发团队获益，给他们提供了逐步增加的能力：

• 将项目作为一个整体进行理解
• 对他们能够会聚于一个可接受的业务解决方案的证据
• 对他们计划的可接受性保持自信
• 关于用户需求现实的期望

带来的结果是开发项目将不再是一个倾入金钱的黑洞，然后在未来的一个含糊不清的指定时间产生出软件产品。如果承诺的沟通以及理解并不能从初始迭代产生，那么将可以采取行动重新指定项目的方向，或是如果需要的话，取消它。这为业务提供了一个客观的方法以监控并调整它的投资。

业务分析师
在业界存在着一些关于需求工作是否应该算作迭代过程一部分的不同意见。在我们的经验中，迭代式增量开发的真正收益只有在所有团队成员，包括那些关注业务的人，能够积极参与到项目中时才能够实现。这意味着需求过程需要被紧密的集成，按照与解决方案的迭代式开发同样的时间表运行。

考虑如下观察：

1. 对不能够被交付的需求进行归档是没有意义的。当你仅仅关注于那些完成目标绝对需要的工作时，按时并在预算内交付解决方案是十分困难的。花费时间去开发那些将不会被交付的工作是一种分心的事物，并且导致项目风险。不要仅仅假设这些额外的工作“将对下一个项目产生帮助”，我们建议把这种工作留到可以获得收益的项目。请记住当一个项目没有达到它的目标时 ―― 被不必要劳动所提高的可能性 ―― 通常来说并不存在“下一个项目”。
   
   
2. 对开发者来说在他们开始工作之前他们并不需要所有的需求可用。他们仅仅需要足够驱动他们当前工作的足够的需求（在本案例中，就是当前迭代）。
   
   既然不是所有的需求都是内在关联的或是同等重要的，在所有的需求都被完成之前同样存在着极大量可以在系统上被完成的工作。一个开发团队可以很容易的在所有用户接口都被设计好以前进行并解决关于系统能够支持1000个并发用户的问题。实际上，典型的用户接口设计只有很少或根本没有影响到解决方案的可扩展性。
   
   
3. 需求工作趋向于进行扩展以填充可用的空间。对大多数项目来说，人们构思出新需求的能力很容易超过任何团队能够在时间以及预算配额内发布他们的能力。
   
   Parkinson's 法则¹“工作如此扩展以至于占据了所有完成它的可用时间”。没有什么比需求相关工作更真实的了。我们从来没有看到任何一个团队在被分配给他们的时间被用完之前声称他们已经找到了需求的全部集合。如果在时间运行完之前需求团队确实找到了足够充分的集合，在这种情况下，他们总是继续发明更多的需求而不是声明任务已经完成。
   
   与完成需求的工作相比，定义需求基本上并不需要花费什么努力。定义需求的真正艺术并不是尽可能多的确定，而是找到能够满足业务问题的最小需求集合。更多的需求并不好，并且许多解决方案都由于具有太多的特性而被毁掉。

藏在所有迭代式增量软件开发过程之后的一个基本的断言是相关的仅仅是那些能够对发布的解决方案产生影响的事物；任何不能对解决方案发布产生贡献的都是多余的并且需要被去除的。一个迭代的目的是要产生一个解决方案的工作版本 ―― 虽然通常只是一个部分版本。为了这个目的，需要清楚的知道将要被此次迭代所实现的需求。这并不是意味着在开发迭代开始之前我们就需要知道所有最终要被满足的需求。而是我们需要努力充分的理解需求以建立对当前迭代来说有意义的目标。

对驱动一个迭代式开发项目的需求开发来说存在着数个模型。让我们探讨如下四个常用模型：瀑布式，前向－装载需求/后向－装载开发，需求管道，以及实时需求。

瀑布式需求，迭代式解决方案开发
在这种情况中，所有需求都在解决方案的迭代式开发开始之前预先进行定义。这种模式被示于图2－2中。

图2－2：预先定义需求的开发迭代

正如你现在可能已经意识到的那样，由于它常常导致一些不能够被实现的需求定义或是过多的需求指定，这种解决方案比理想中稍差一些。

这起初引起产生了不切实际的期望，然后关于每一个需求都不能够被实现的意识开始逐渐被相关的部分所理解，这导致了抵触的失望的气氛。

这还导致了需求团队独立隔绝的工作，剥夺了他们从开发团队得到的反馈，接下来导致产生在需求团队及开发团队之间的冲突。它还阻止了从首个需求集合的实现中得到的经验能够被团队整体学习并用此来提高需求质量以及整个团队效率的机会。

这种模式通常可以在这些组织中看到：

• 开发团队想要进行迭代但是已经证明了当前解决方案对业务组织的适用性。
• 开发被公司外包，这公司并不熟悉迭代式增量技术，而外包公司本身采用了它们。
• 开发团队与业务具有敌对的关系，并且不信任他们作出的任何决定或是与他们协同的工作。
• 业务不能区分需求的优先次序并且坚持将他们作为一个完整的，不可分割的集合而对待。

由于这种需求方法导致一种将团队成员置于他们所进行的工作种类的功能性“筒仓”中的企业结构，因此必须小心的进行处理。这在团队成员之间建立起了屏障，在解决方案发布过程中降低了通信及团队效率。这个问题通常与奖励成员完成了必须而不充分的工作以发布解决方案的测量系统混合在一起。对职能上有组织的团队来说将“成功”理解为对一个良好需求文档的发布或是一个被签署的软件结构文档是很普遍的情况。

虽然这些事物对达到发布解决方案的目标来说是必须的，然而它们的价值并不在于它们自身。如果解决方案发布失败，已经被完成的需求文档没有产生任何价值。虽然也许需要组织于功能线的关系报告以促进技术发展及事业成长，但是对进展和结果的测量需要与解决方案的发布相符合。这通常导致一个“矩阵式的”报告结构，其中每人都需要向至少两个组织进行报告：一个从职能上与职业生涯相关联，另外一个则与项目及其目标相关联。

前向－负载需求，后向－负载开发
如果在需求中存在着任何稳定性，那么正如图2－3所示，开发迭代可以在需求工作完成之前很好的展开。

图2－3：需求规范与开发迭代的重叠

它显示了一个更为迭代性增长的解决方案，但是它仍旧使需求及开发团队工作于不同的管理筒仓中，这必然要承受所有的通信开销以及冲突。

需求管道
存在着向管道模式发展的诱惑，正如图2－4所示的那样，需求团队为下一次迭代周期进行需求工作，同时开发团队实现本次迭代所定义的需求。

图2－4：需求管道

这种模式立即提出了一些问题，包括：团队工作于哪次迭代？迭代是否重叠？团队是否会在某些时候对多于一次的迭代进行工作？从个人及项目管理视角，人们怎样知道他们正工作于哪次迭代，或者他们的优先级是什么？（从管理视角对迭代进行探讨将是本系列文章中第三部分的主题。）

当需求团队与开发团队不可能像一个单一团队一样协同工作时（由于法律，地理，或是组织上的原因），需求管道模式是真正唯一适合的。

实时需求
理想的，为了提供最敏捷的、灵活的、并且聚焦的开发团队，需求和开发工作被完全整合为一个单独的良好定义的迭代集合。这将扩展典型的迭代式开发模型以包括发行的需求规范及其系统测试。这将扩展上个月的文章 中的迭代模型如图2－5所示。

这种工作方式是最有效的，但是它取决于要有一个集成的、合作的、包括业务及用户视角表现的同时技术导向的开发团队，

图2-5：整合需求规范和系统测试的迭代

这个方案通过对业务解决整体建立一个着重于有效的、迭代的增量式开发将迭代式增量开发引入他们自然的结论。这允许团队调整、自纠正它们的过程以确保尽快的分发业务价值。

正如你可以看到的那样，当团队成员发现他们自身是一个项目团队整体的不可分割的部分，他们在整个项目周期内不仅仅工作在初始阶段时，对采用迭代式增量方案的业务分析团队来说作用是十分显著的。分析师也将发现迭代式的定义需求，通常采用实时的方式，常常在同一次迭代中实现这些需求是一样。

分析团队将为分发他们的解决方案而共享责任，分担与他们要求实现责任的项目的关联程度。需求文档，不仅仅作为对“最终”需求的必须被分发的不可变记录，而变成了一个活跃的在业务和关注何种需求能够被分发以达到一个满意的解决方案的开发团队之间的合同。当被作为一个合同来考虑时，需求文档指明了双方的责任，同时对谈判开放。它的规模及复杂度将意味者双方之间存在的信任。

系统用户
系统用户视角与客户视角非常相象，用户可以看到关于进展的周期性迹象以确保解决方案能够适应他们的实际需要。

对于项目整体，将用户包含入迭代所产生的发行版本的演示和评估一般来说这是非常有利的。但在每一个迭代中未必时必要的，因为允许对早期部分实现的广泛回顾可能会起到反作用。与系统用户的常规交互也可以帮助提醒开发团队的发布业务职责，而不仅仅是迷人的新技术。它还使得需求本身可以像它们的系统一样被验证。

对于早期用户反馈请求的益处，特别是在应用以及用户接口设计领域，已经由前面所提到的案例被证实。我们认为它提供了有价值的教训。

业务领导人（或发起人）
从业务领导人的角度，迭代式开发的价值在于它对被考虑过的项目增量资源委托的支持能力，同时能够对项目资金投入以及项目风险和成功机会进行平衡。投入项目的资金可以被限制于本次迭代。如果本次迭代所展现出来的进展以及风险缩减并不充分，项目可以被取消或是重新定义，而对组织来说损失并不是很大。一次迭代的资金可以被看作是在进一步投资一完成项目之前，对项目额外信息的购买。

Barry Boehm使用stud poker 的类比² 对一个迭代式增量开发项目从发起人视角进行阐述。在一个stud poker游戏中，你可以向壶中投入一对筹码并得到两张牌，一个被隐藏的一个暴露出的。你也可以看到另一个游戏者暴露出来的牌。如果你的牌不能保证可以获得胜利的输出，你可以退出游戏而不会损失太多。如果你的两张牌都是 Ace ，那么你会因为拥有一个可以获得胜利的输出而赢得很多。在任何情况下，你都可以在每一轮决定是否要更多的牌以购买更多的关于你获胜前景的信息，或是基于你已经知道的而放弃。

类似的，每一次迭代中关于成功的项目输出资源被投注并且关于项目获胜机会有更多的可用信息。如果项目成功的迭代并且产生出客观可测的、可证明的增量，那么发起人对于项目的信息也将随之增长，而投资将继续。如果，在初始迭代中，项目看起来像是失败的，并且面对着不可克服的风险等级，那么发起人可以退出而不会带来很大的损失。

通过这种使用迭代的方法来管理项目风险的概念是成功使用迭代式增量开发技术的基础。

结论
迭代式增量开发为业务提供了超越传统的瀑布式开发方案所提供的更多的优点。这包括增强的可预测性，减小了上市时间，更高的质量，增强了项目灵活性以及生产效率。这将从根本上改变项目业务工作，从需求捕获方法直至进展评估产生影响，更重要的可能是项目本身被投资的方法。

用户反馈请求 ―― 及早！
这里存在一个保险公司，指定一个想象中的新IT主管。这个新IT主管第一个行动是颁布：
所有公司所开发的新应用都将作为Windows应用程序而设计并开发
基于PC的Windows桌面被展开至所有公司IT用户
所有软件都将采用面向对象技术进行开发
在这个新体制下第一个被开发的重要应用软件是取代公司呼叫中心的旧有风格的“green screen”系统。开发进行的很顺利，并且对系统测试所用的应用程序按时在预算之内完成可用。想象中的IT主管对应用印象很深，特别是当新的用户接口被展示出来时。采用“指指点点”的窗口使用用户界面，一个复杂的帮助界面。并且3维肖像 ―― 是如此精致以至IT主管留下很深的印象。“太好了！通过这个指指点点的界面以及广泛的虚拟帮助，我甚至可以回答用户电话呼叫。”当团队庆祝项目的成功以及这个新IT策略时，香槟被砰的打开。
实际上，这个想象中的IT主管并不是工作于应答电话呼叫中的一员。这是不同组人的工作，他们工作于非常困难的情况下 ―― 在他们的桌面上没有鼠标或是鼠标垫的空间。他们需要的最后一件事情是一个能够接受许多鼠标点击以达到通过一个单一的热键可用的图形用户接口。并且，除了这个事实，没有人能够在不通过广泛训练开始接听电话的工作。这样，这个新系统建立了一个完整的在用户期望和工作场所物质及文化情况间的不匹配。
用户期望一个能够让他们的生活变得更容易的新系统，但是他们得到了一个仅仅能够让他们的生活变得更困难的东西。如此多的努力被投入到这个新用户接口工程中却没有开发出任何新功能。这个系统没有通过用户接受以及初始用户的测试而进行开发。
这个失败的故事告诉我们的道理是：如果早期版本能够与用户团体成员共享，或是如果开发团队能够着重于发布业务价值而不是被使用流行的新技术所诱惑的话，所有这些都可以很容易的避免。

备注
¹ C. Northcote Parkinson, 帕金森定律 (1958)
² "螺旋式开发: 经验，规则" ， Barry Boehm, 特别报道 CMU/SEI-2000-SR-008, July 2000

参考资料
您可以参阅本文在 developerWorks 全球站点上的 英文原文。

作者简介
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) 并且他们正在合作进行下一本书籍的编写，本系列文章便是摘自这本书。