本文来自于 Rational Edge：迭代开发为客户在整个开发生命周期中的参与提供内在的机会，但是许多组织忽视客户在过程中的有效参与。直接将客户的参与融入到迭代计划中是十分重要的，本文中描述的另一个简单的技术可以很大程度地提高项目的成功率。

　　在 XP 2002 年会议上，由 Standish Group 的 James Johnson 提出的大型研究表明，大多数应用程序中所编写的 45％ 的特性从来都未使用过（参见图 1）。1花时间在没人用的东西上似乎很荒谬，那么所有的这些特性又出自哪里？

　特性列表来自于很多地方。一些特性来源于业务分析人员，这些人想要一个系统如何具备竞争性的可见的表示。这听起来即合理又重要。我们想要有竞争性的区别。但是我们所采用的方式可能不会给客户带来价值。例如，考虑所有的销售报告分析，乃至您自己的基于与技术来源比较的分析。这些报告包括列出了在某种工具的各种品牌中进行比较的超过 100 种特性的图表，如果某品牌提供某种特性，那么在某品牌的列的每一个项上都有选取的标记。乍一看，我们可能会设想有最多选取标记的品牌是最佳方案。

　不明显的是，那 100 个特性中，客户几乎或从不使用的特性总共 64％。但为了从表面上看比其他品牌有竞争力，我们将解决方案结合到不需要的 64 个特性上，这使我们的产品更复杂，常常更难于使用。

　在迭代和敏捷的开发组织中，客户驱动的计划是最重要的。客户驱动开发意思是下一个迭代或版本的特性选择来自于客户。焦点是客户是否感觉到自己获得了最高的业务价值。许多开发组织仍旧不咨询客户，相反，将特性的选择与业务分析员或产品销售团队隔离。产品经理通过他们对市场趋势和竞争的阐述完成特性的优先化。不清楚且含糊的需求传递到了很少与客户接触的开发团队那里。他们按照自己的理解（远远偏离了客户的观点）编写特性。客户常常直到编码固定或者在一个正式的测试迭代过程中时才能见到应用程序，这太晚了。

　在本文中，我将提供有关如何改变组织中的这种迭代并且尽早且不断地让客户参与进来的建议。我提供根据我个人在软件开发项目中的经验而来的普遍问题场景的实例。虽然这些实例举例说明了一个软件开发生命周期，但是我所描述的技术可以由任何负责验证及收集需求的人使用。

　成功的障碍：假想与现实

　了解如何发现实际的需求并达到软件项目更大的成功对许多开发组织来说也许不容易。一些限制是假想的，一些是现实的。在此部分中，我将介绍我认为最可能遇到的最普遍的限制类型。

　去掉假想的障碍

　考虑下面的实例，该实例说明了与客户隔绝的开发团队。

　性能测试工具是设计用来模仿数千个用户来对服务器和其他在测的应用程序施加压力的。工具所收集的诊断信息用于调整服务器，以满足那些应用程序所需的响应和性能目标。性能工具提供正确的诊断信息，覆盖具体的和整个的设计需求。但是客户花费四个小时放置、解包、插值，并操作该数据，放入一个表格，交给实际调整服务器的不同任务的团队。开发团队假设使用该数据的团队将是使用性能工具的同一团队。因为该工具不能自动地导出数据，因此客户不接受该产品。

　当我们满足原始需求时，这又是怎么发生的呢？首先，原始需求是模糊的。开发人员专注于需要收集的数据。他们以最便利的方法为项目进度收集数据并记录。他们创建实时的，显示在控制台上的图和表。在运行过程中和结束后，数据都显示在控制台上。在运行时过程中的实时绘图是明显的“新特性”。其次，开发团队没有认识到，从业务过程的角度看，运行测试的客户测试团队与利用数据调整后台服务器的客户 IT 团队是不同的。利用数据，分析需要在服务器上做些什么事情的团队不使用性能测试工具。因此，在运行过程中附加上的“实时”报告对需要该数据的团队是不可见的。

　事实上，实际上必要的特性是能够导出并共享全面的报告。如果根据客户的业务过程审阅原始的需求，那么这个重要的事实就会得到很清晰地强调。我们本该避免这种“错误”,我们应该在早期的需求审阅和走查阶段就咨询客户。

　在前面的实例中，问题归结为开发人员由于遇到了太多的障碍而不能与客户接触，从而利用自己的理解进行开发。实际上，许多障碍似乎会阻止客户参与开发团队的工作。有些是实际的，但以下都是假设的。

　作为开发人员，我没有权利访问客户联系信息。
　　我不可能花时间会见客户并与其讨论。
　　与客户联系是其他人的工作。我需要相信他们做了本职工作，并且我需要将重点放在自己的工作上。
　　这些真的只是借口，不是真正的障碍。让我们来分别揭露每一条。

“作为开发人员，我没有权利访问客户联系信息。”

　作为开发人员和测试人员，我们每天都在处理客户的缺陷（defect）。这些缺陷有客户联系信息。开始这种关系就像拿起电话那么简单。一旦您开始了这种关系，就会有其他技术来保证客户的参与。

　“我不可能花时间会见客户并与其讨论。”

　现在这一条可能是真的，但将来就不会了。开发人员应该公布自己的意图，并与经理合作安排下一个循环的时间，用来完成具体的客户交互目标。

　“这是其他人的工作。我需要相信他们做了本职工作，并且我需要将重点放在自己的工作上。”

　开发人员的2工作就是创建那些对客户有价值的质量代码、应用程序，和产品。在开发人员的工作中的一个重要部分就是找出有价值的东西，以及客户如何实际使用您的应用程序。

　与客户的交互是永不停息的活动。有数千种与客户交互的方法。某些角色和团队拥有一些活动。但是差不多存在数百个其他的没有所有者的机会。甚至拥有特定角色的人也可以使用辅助。

　适应的计划

　当我们去购物时，有时候心理会有“想要的”产品。有时候没有。而有时候我们在看到之后会改变主意。在我们确信要买之前，我们需要实际地观看、感觉，并使用一下产品。软件客户有同样的需要：他们不总是知道自己想要的，并且有时候改变主意。许多组织通过几乎完成的产品Beta版本获得第一手的客户反馈。3虽然这是一个被广泛接受并有用的实践，但是它提供了迟到的反馈。如果在此阶段测试客户鉴别出关键的可用性或丢失的功能，那么您就面临困难的决策：发布带有关键缺陷的版本，还是推迟发布重新设计。

　与客户详细地讨论产品设计的早期版本可以确保您处于正确的轨道上。在给出有用的反馈之前，客户还需要看到一些具体的东西。通过提供快速的原型、更早的设计审阅，以及短暂的交付迭代（除了常规的Beta版本），您可以减少客户在随后阶段发现关键的可用性问题的风险。

　最后，业务需要常常是动态的。早一些交付针对部分问题的局部解决方案比一年后交付整体的解决方案要好。如果针对客户需求的完整解决方案在一年后拿出来，那么与此同时客户将去寻求针对具体的关键需求的另一个解决方案。提供应用程序的迷你版，让客户对您下一次迭代不断地重新调整。这增加了客户的参与、投资和忠诚度。现场的访问及尽早地安排部署来帮助客户增加并结合了您的产品和客户的关系。通过不断地使您的工具适合具体的业务过程（对比让客户改变过程来适应您的产品），您将开发人员与消费者的关系转变成一个真正的有创造力的合作关系。

　由客户指导的每个迭代阶段的适应计划对敏捷的程序设计风格来说是基本的，并且在其他的开发环境中可以很容易地利用这些优势。

　了解限制

　假设，对于一些项目来说，只着关注于客户或客户集想要的东西是不可能的，因为经常有不同类型的用户和风险承担者。竞争因素、公司规定的安全遵守特性，以及其他经常的需求可能迫使我们生成最终用户从不使用的特性。在这些情况下，您应该为每个发布版本确定“release-defining”4特性，然后限定并指定一个代表针对具体目标的用户主体的客户（或客户集）。对于每个后继的版本，您可能突出不同的“release-defining”特性，并且您可能让不同的客户集代表给出反馈。

　这一选定的集合5对整个开发生命周期内的每次迭代的交付部分（需求、原型、演示）进行审阅。这样做，您的最终产品将有更多的特性得到实际应用，并且您将了解在哪个特性上花费时间。即使您的产品中有 100 个特性，但是通过与客户的不断沟通和协调，您就知道哪 36 个特性要真正地给予关注，哪 64 个特性应分配较低的优先级。因此，虽然您可能不会对业务团队如何列出他们所需的特性产生影响，但是您至少知道了到项目的终止阶段时，什么能令您的客户最满意。

　我们实际应该如何做到？

　应用实践

　有了恰当级别的委托，再加上与客户频繁的交互，以及在实现解决方案时保持灵活性的愿望，软件开发团队非常可能提供使得软件项目成功的特性。当然，满意的客户将来会给您的组织带来更多的项目。让我们看看成功的基本要素。

　做出承诺

　任何项目的第一个步骤是实际做到生成并增加您的客户列表。您可以通过许多方式了解您的客户。6这里有一些您可以做的更显而易见的事情：

　访问先前报告您产品中的缺陷的客户。如果他们报告了问题，您知道他们正在使用您的应用程序。
　　出席产品的培训课程，在那里您可以见到计划使用您的应用程序或产品的人。
　　出席您组织的用户组会议。这些事件是为您的客户而发起的。
　　出席与您的应用程序或产品有关的当地专业组织的会议。
　　为您的应用程序找出内部客户。让组织中其他的团队使用您的产品。他们将提供真实使用后的“友好批评”。
　　这里有一些您可以做的不那么明显的事：

　就特定的条件与领域专家进行讨论。了解该条件的实际客户用户流、业务流，或过程。在您的测试和设计中使用那些用户流。
　　关于概念原型验证的约定与领域专家组成一组。
　　提供一个应用程序或产品的培训课程。
　　邀请客户来到测试实验室。
　　提议去到客户的实验室帮助他们项目的工作或对他们进行您的应用程序方面的培训。
　　提议成为Beta版程序的联系人。
　　当面访问客户，这样您可以看到客户在自然的环境中如何工作。
　　然后承诺今年至少与三个客户联系。使之正式化，并将其放到编制的性能评估目标中，作为实现成功的强制方法。在产品审阅中的质量评　　估报告中报告结果。

　学习与客户接触

　你不得不假设，客户在其自身的任务角色中，希望在可能的最高层次上完成任务。他们想要能够有效且准确地帮助他们实现目标的工具和应用程序。您的目标很简单：使客户成功。

　当您的意图表述明确时，客户将退居背后帮助您建立他们需要的东西。这里有能够帮助开发团队成员实现他们改善客户联系的承诺的三种技术。

　提供选择

　　一旦您与客户取得联系，您需要提供要如何继续的选择。例如，我的团队有一些就位的客户程序，包括客户公关（customer roadshow）（在客户的地方进行访问，只是聊聊），移植测试（将客户应用程序、数据、测试用例、客户规程带入我们的测试实验室，以便我们可以像客户使用产品时一样更有效地测试产品），植入测试（在他们的实验室放入我们的效用和规程），以及常驻编程（residency program）。

　在常驻编程中，客户在我们的测试实验室工作五天，与测试人员一起使用产品。我们举行对他们的关注点和问题的实时讨论。我们与产品经理、文档编制团队，和技术支持成员一起开会，以便整个开发生命周期的风险承担者分享同样的认识。

　通过提供一些级别上的选择，客户可以选择在不感到压力的情况下如何交互，以及堆动意见交换。这些程序本质上也是进步的：伴随每次的成功，我们有机会发展到下一级的客户参与。

　例如，在用户组会议上演讲或出席客户培训课程可能导致客户的来访。一次客户的来访常常导致收集并移植客户的应用程序、数据、测试用例，和业务过程到您自己的实验室中。7常驻编程常常导致客户对下一个版本的Beta版和早期的第一版的委托。客户对Alpha版和Beta版的参与常常导致客户驱动的开发周期中的迭代开发会议（不限于Alpha版和Beta版）。

　不久动力就自生自存了，不需要您的很多工作，促使客户参与的每个层次自然地发展。

　为类模板的活动作准备

　　一旦您开始与客户交流，您将发现大部分形式的客户交互，但您需要做一些准备。例如，在所有的外部客户交互之前，我们需要签署的非公开协议、创意证明书，或者其他的文书工作。生成一些清单和模板可以减少您忽视重要考虑或步骤的风险。附录中有简单的清单示例。

　将与客户的交互并入日常的业务

　　当然，这花费时间。将其考虑为“可选的”活动就错了。当我们决定客户交互是在职责之上的时，我们就有了成功的机会。

　作为一个质量工程和测试经理，我为各种程序和产品制定测试计划。我将移植测试和常驻访问融入到日常生活中并将我的测试人员发派到客户测试实验室，明确作为它们的“测试活动”。这些活动成为我测试计划的一部分，它们的结果成为迭代退出标准的一部分。以此方式融合排除了“找时间”执行那些似乎特别的活动的需要。

　例如，我的测试计划包括为每次迭代定义良好的成功标准。一些实例是：

　客户 X 的评阅并同意需求
　　客户 X 的预定演示计划并执行了
　　客户 X 对迭代、交付内容，和质量标准的积极评价
　　客户 Y 成功的常驻访问，以积极的产品评价结束
　　客户问题和对缺陷数据库关注的已发布的优先化的列表
　　再说一次，这些活动中最好的成功方法是公开地说明您的意图和成功标准。将这些具有成功标准的活动融入团队的测试和开发计划中将改　　变整个产品的优先级、焦点，和品位。

　现今歉收的组织经常对在添加新特性、扩展到新平台、修正积压的缺陷，和提高可用性中摇摆不定并保持平衡而困惑。客户不断地参与提供了一个切实且非常简单的团队目标：让客户成功。 每个人都能够理解此目标。优先级和焦点自动跟随而生。最终，我们不寻求成功的故事，因为我们一直在创造。

　定义您的客户交互成功标准

　许多项目中有过一些级别的客户交互或Beta版程序。它们常常安置在产品开发循环的末期，在认为产品“特性完整”了之后。如上面所提到的，这对首次客户预览是太晚了。我实际上已经审阅了一个安排在 10 月 3 日到 11 月 7 日运行的Beta版测试计划，而要向大众推出的产品安排在 11 月 5 日出版（先于Beta版的推出）。显然，客户Beta版的结果与此特定的版本不相关。他们的输入将进入下一个版本T，但不在当前的版本进度中。然而这不一定糟糕，但我们需要了解并对任何已知的Beta版循环的原因和成功标准意见一致。

　例如，如果这是构建良好的产品的一个小型维护版本，那么我们可能有那样的信心，产品满足客户的需求。校正内容直接来自于客户，而真的不需要等待Beta版的反馈。实质上我们正向我们最好的客户和销售团队提供产品的早期版本。

　另一方面，如果我们在发布一个相对新的产品或技术，或者转移到新的平台，而且我们不确定客户会如何接受变更，那么在开发过程中就需要进行客户评估。需要恰当地安排对该反馈的响应时间。

　在名为 高效人士的七个习惯（Seven Habits of Highly Effective People）的书中，Steven Covey 经常强调，我们需要在开始做事情时，心里就想着结尾。在着手任何用户交互，如Beta版程序之前，我们需要定义并对目标和成功标准达成一致。设想您在与客户交换意见、Beta版，或常驻的结束时刻：您明确想要什么作为出口？

　对您产品的评估可以帮助确定什么构成了成功的客户访问、常驻，或Beta版程序。评估可能包含以下几类的客户评定（利用图 2 所提供的 1-5 的数值范围）：

可用性
　黑箱测试
　拥有对实现目标很重要的特性，并且有效
　用户帮助
　其他？

　

　　在您为产品评估开发这些种类时，您还应该开发针对客户观点的与种类保持一致的评定系统。换句话说，数字的评定表示：

　1 —— 忘记不久将要发布产品。

　2 —— 产品有许多主要的问题，并且要实际地尝试在组织中实现，对我（客户）来说风险很大。

　3 —— 只有一两个主要的问题，但存在许多小问题会使其使用不便。我仍旧可以进行工作并完成目标，但会觉得这样做很烦。

　4 —— 只有一些小瑕疵 —— 低风险。好。

　5 —— 我今天就买！

　然而您需要在评估产品的整个客户范围内衡量结果。例如，成功的标准可能定为“受调查的客户中 85％ 的人给出的评定是 3 或更好。”

　结束语

　迭代开发提供内在的机会来论证对正在实施的解决方案的不断的提高。这些早期的里程碑是重要的客户参与机会，不幸的是，许多开发组织着重于迭代计划和迭代技术的其他技术方面，而不是让客户参与的关键需要。本文中所说明的直接将客户参与融入到迭代计划中，以及其他简单的技术可以帮助您平衡团队的动机。许多团队将开始把客户交互作为开发生命周期中的组成部分。客户将不仅对正在实现的解决方案感到激动，而且还期待未来的合作。

　补充阅读

　Laura Rose，“现实进度安排的十二个提示。” The Rational Edge，2005 年 9 月。

　Craig Larman，Agile & Iterative Development: A Manager's Guide。 Addison-Wesley 2003 年。

　注释

　1 参看 Standish Group 的文章，What Are Your Requirements? Standish Group International，Inc. 2003 年（根据 2002 CHAOS Report）。

　2 术语“开发人员”是指程序设计人员、测试人员、技术编写者，和所有参与产品开发的人。

　3 就是说，实际上产品完成了。所有的特性都编制好并集成在一起，只有测试还未完成。

　4 “Release-defining”特性意思是，如果该特性没有完成，该产品不正式出品。对此版本可能还安排其他增加部分和特性，但如果不能准时完成，该产品仍将正式出品。成功的策略争取一个版本只有两三个“release-defining”特性。

　5 与处理您的解决方案或行业中各种类型客户的商业伙伴或顾问一起工作是获得对具有一个接触点的各种环境的有效的反馈。

　6 和您的队友及同伴集体讨论与客户联系交互的所有可能的方法。

　7 还可以将团队中的一个测试人员分派到客户实验室中临时工作并且带回在那里的认识，以便根据客户使用的情况来测试产品。

　附录

　一旦您开始让客户参与进来，您将希望创建各种清单和模板，这将减少您除去的重要考虑或步骤的风险。以下是一些示例清单。
　
　
　
　　IBM Rational Performance Tester 工具的客户调查问卷示例：

　下面是您可能询问客户的示例问题：

　您最大的性能测试问题或障碍（独立于您在使用的性能测试工具）是什么？
　　当您执行性能测试时，详细的难题是什么？
　　您所运行的典型场景和环境是什么？
　　在领域（Ex. Citrix、SAP、Web、Siebel、DB/2，等等）中使用最多的五个协议是什么？
　　您用过的性能测试工具是什么？?产品 X?
　　您喜欢?产品 X?的什么方面？
　　您不喜欢?产品 X?的什么方面？
　　您需要的功能或特性有那些是?产品 X?中没有的？特别的，如果我们实现了以下所有用例，您会不会更快地转用 RPT？
　　对 IBM Rational Performance Tester（RPT）的疑问：

　学习 RPT 会有多简单？
　　使用 RPT 有多容易？
　　您发现自己一遍遍重复做的是什么事，而您感觉这些事本可以更容易做？
　　您将主要时间花费在性能测试工具的哪个部分？（例如：记录（Recording）？编辑测试脚本？运行测试？监控代理？分析结果？）
　　令人满意的 RPT 是否实现了您的性能测试目标（也就是，强调您的系统）？如果没有，为什么？
　　您会对 RPT 的界面、可用性，报告，等做什么变更？
　　您最希望看到的 RPT 的新特性和改进是什么？（请按重要性列出。）
　　您最希望看到的用户辅助、用户手册和帮助方面的改进是什么？（请按重要性列出。）
　　您是否有兴趣进一步使用 RPT，用于交换信息及帮助？

　参考资料

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

　关于作者

　Laura Rose 是质量工程经理，在 IBM Rational 负责自动化的性能测试工具。除了领导软件程序设计和测试环境的项目，她还有十三年的程序设计经验和十年的测试管理经验。她已经成为 American Society for Quality、Triangle Quality Council 和 Triangle Information Systems Quality Association 的成员，并且在各种测试和质量会议上作过演讲。您可以通过 llrose@us.ibm.com 联系她。