本文来自 Rational Edge ：RUP 的专家解释了被软件开发项目成员需要的职责和观点上的改变，并且介绍了成功的从传统的瀑布型方法向迭代方法转变的客户案例。
成功的采用迭代开发方法的实践不仅仅需要部署一系列的新技术，也需要改变团队协作的方式和团队成员的职责。在本文中，我们将会了解到被软件开发项目成员需要的职责和观点上的改变，并且介绍了成功的从传统的瀑布型方法向迭代方法转变的客户案例。
  广泛的引用这些变化作为一种&ldquo新的思想&rdquo，我们将关注软件开发项目中的不同个体角色： 
分析人员 主要负责与客户交互和需求。 
开发人员 主要负责设计、实现和单元测试。 
测试人员主要负责功能、性能和系统测试。 
项目经理 主要负责持续的项目团队的跟踪并关注关键的交付产物。 
质量保证和方法专家 负责质量标准和最佳实践。 
客户 负责澄清他们的业务需求关心什么样的能力。 

分析人员的新思想
在传统的瀑布型的方法中，分析人员与用户和项目团队之外的涉众打交道。目标是理解并开发一个代表了一系列需求的方案，文档化这些需求然后将这些需求文档交给开发团队。一些开发组织用一种&ldquo未来&rdquo状态的长列表来详细说明需求；另一些组织在高层次上表达需求，为解释需求保留了很大的空间。在这两种情况下，必须有这样的假设，分析人员既要了解业务又要了解用户，并且这个分析人员应该是指定系统应该具有什么功能的人。

一旦分析人员文档化了需求，他或者她就会要求用户来检查这些需求文档（甚至如果他们不能完全理解用来表达需求的技术语言，并且/或者他们不能通过可视化的方法来表示当系统被实现时许多需求是如何满足用户的需要的）。然后，实现需求规格说明就是开发人员的工作了。典型的，不论是开发人员还是测试人员都没有参与到阐述需求的工作中。并且一旦需求被规格化，很少会有在分析人员与设计人员之间的积极的交互。分析人员只是简单的阐明需求说明书中包含的内容。

这种传统的模型在某些方面的缺陷将在下面被解释。 

分析人员的新思想
建立与最终客户的持续的交互以确保开发人员可以创建正确的系统。 
鼓励尽早的开发和实现系统的关键能力部分，以加深你对什么需求将满足业务需要的理解。 
从一开始就与开发人员和测试人员一起优化序需求。 
为需求选择适当的详细程度，可以根据你的项目和当前的生命周期阶段而定。 

分析人员不应该孤立的指定需求
首先， 瀑布型的方法失败的认识到客户、开发人员和测试人员参与需求说明工作的价值。没有对业务和技术拥有优秀的理解将不可能创建出能够改进你的业务的软件系统。不幸的是，很少有人同时在业务和技术领域具有深厚的知识背景。这就意味着，分析人员、开发人员、测试人员和客户应该一起工作提供需要的所有的信息以确保开发人员可以创建&ldquo正确的&rdquo软件系统 &mdash 也就是说，一个充分满足客户业务需要并且提供从根本上有效的改进客户业务的能力的软件。

让我们来看一个简单的例子以说明这样的团队协作的好处。 

例子：基于 Web 的航班预约系统
我们假设一个分析人员负责对这个基于 Web 的自助服务的航班预约系统的需求工作。这个分析人员指定用户将提供一个航班的代码并指明行程的开始地和目的地。如果用户不知道航班代码，他们可以通过提供城市名字进行查询。然后，这个分析人员指定，在用户预定了一个指定的航班后，他们将会得到关于如何联系不同的代理以预约到达目的地时的地面交通工具。
当设计人员检查系统需求时，他回想起曾经看到过一个能够提供部分功能的并且经过证明的Web 服务的方案。这个低成本的服务允许用户导航机场的地图显示并快速的找到符合他们需要的机场，甚至假如用户不熟悉他们的目的地城市或者不熟悉目的地的地区的机场。
在与客户验证了策略后，分析人员和设计人员对需求作了改动以包含这个 Web 服务的实现。然后，在几天的开发工作后，设计人员发现了这个服务的另一特性：当用户选择了一个机场时，他们会自动的收到一个机场信息的列表，信息中包括可得到的地面交通工具的模式和对每种模式预定的容量。设计人员和分析人员与客户和项目经理讨论了这个发现，大家都同意合并这个额外的 Web 服务的特性到他们的新系统中，代替他们原来指定的创建一个地面交通引用的特性。

就像你从这个简单的例子中所看到的那样，在项目的早期阶段就让设计人员/开发人员参与到需求中能够带来巨大的好处。他们中的每一个人都可以建议分析人员或者最终用户考虑不到的能力和方案。当然，衡量预期的项目范围变化的价值仍然是项目经理和客户的责任，分析人员仍然必须理解业务需要并驱使系统应该在何处结束。但是他或她可以通过与设计人员/开发人员协作找到更好的方案。

分析人员和最终用户的交流应该贯穿于整个项目的生命周期中
传统开发模式的另外一个缺陷是缺乏在分析人员与最终用户之间的交流。 最终用户被期望预先的指出需求并且对需求进行检查，但是他们有限的参与了方案的开发。在许多情况下，和约的商定是以预先被描述的需求为基础的，并且后来的变更需要有一个和约上的协商。

在整个开发的生命周期中维护在用户与分析人员之间的交流是尤其有效的。双方都应该理解他们拥有相同的目标：建立满足质量要求的可以解决问题的方案，同时成本是可接受的。如果他们的关系是围绕着争论关于什么是以前达成的一致和谁应该为此付钱，而不是建立一个正确的方案的话，那么项目就陷入了麻烦之中。这并不意味着分析人员应该接受所有的需求或者最终用户不应该作出变更的请求。相反，这意味着所有的项目相关的人员应该在提出需求和最终进入到订单中的需求进行一个平衡以形成更好方案的开发。他们需要认可当他们过分的严格时，应该通过一些讨论以达到一个折中的方案，并且要作积极的改变以保持项目按照计划进行。当然，这一点做起来要比说的有难度。但是朝着有效的团队协作的第一步是在分析人员与最终用户之间建立起有建设性的对话。

过度的指出预想的需求是不明智的
传统的开发方法提倡详细的预先需求，并且在过去的多年里很多人觉得项目失败是因为他们的需求对启动项目是不够详细的。但是增加需求说明的详细程度将会减少的回报。在一些情况下，项目团队需要不断的构建方案，并假设需求在整个项目周期不断的改进。记住：软件项目的主要目标是在尽可能低成本的条件下生成可执行的能够解决手工形式的业务问题的代码。一旦你的需求到达了一定的细化程度，将他们定案的最廉价的方法是对系统进行部分的实现以可以向最终用户进行演示。同时你可以一起确定你还需要提供什么样的其他能力。定案需求通常要经过几次的迭代，在迭代期间你可以调整需求、设计和代码，然后对测试进行引导。
原文：www.chinaopi.com.cn/bbs/read.asp?vid=927