假定 Agilistas 提出将频繁的演示 —— 确定会在每次迭代或者加速技术的时候—— 作为最关键的方法，确保开发小组能够持续跟踪客户的需求。但令人担忧的是，Agile 的许多指导对于很多问题都没有详细的说明，比如如何 交付演示，将演示聚集在一起并经日程安排需要有多大的工作量，或者谁将观看这些演示。更糟糕的是，这个假定情况是您正在为一个客户或者一个组织构建软件。但如果您实际正为一个有着广泛竞争利益的规模更大更复杂的组织进行商业上的软件开发，或者应用软件开发，又该如何呢？

无论我们在敏捷宣言中的假设，即认为‘顾客合作要优于合同谈判’是否合理，事实是，许多敏捷团队与他们客户接触的机会远远不够。

对于敏捷项目上的与演示相关的指导方针有哪些呢？并不多。例如，Scrum 社区中对于太多问题的答案是，‘让他们自己决定’。但如果您的团队非常庞大，或者比较分散，或者既庞大有分散时又会产生什么样影响呢？像这样的团队如何决定怎样才能有效地运行演示；或者也许有更重要的问题，如何能够保持持续的反馈？XP 社区主张‘现场客户’的观念。在现实中让用户实时地肩并肩地与开发团队持续合作几个月，这样会是什么样的结果？ 假设您能够找到这样勇敢的灵魂，那么一个线程客户能适当地代表所有不同的购买商业软件的客户吗，或者能代表一个大型复杂组织的多项竞争性利益？

如果对于敏捷团队确实非常急于得到反馈，为了实现敏捷宣言工作中的目标，要特别留意以下这些问题：

• 谁是我的客户？
• 我如何利用演示来获取反馈？
• 除了演示还有其它获取反馈的方法？

在这篇文章中我将一一详细地处理这些问题。

谁是我的客户？

这看起来可能是一个非常无聊的问题。然而这里显著地标出了它们的特征，因为不是所有的客户都相同的——有不同 类型 的客户需要考虑。更重要的是，由于您不再从唯一的 客户 角度来看问题 （正如敏捷宣言会引导您相信的那样），我将扩宽范围，一直延伸到 涉众。 这里有四种类型的涉众，我将在很多地方利用到：

负责人 就是那些为了达到特定的商业目的我们的软件投资的决定者，或者那些对决定有着关键性影响的人。

终端用户 当然就是那些在工作中部分地或者全部地使用我们软件产品的人。

合伙人 就是那些利用我们的软件帮助其他人实现他们商业目的的人；例如，业务合伙人需要为客户安装，维护，或者部署我们的软件产品。另一个例子就是特定的客户 IT 商店：他们可能不购买或者不使用我们的产品，但是他们要运行产品，这样终端用户才会使用。

内部人员 就是在我们自己的公司与我们一起工作的人，他们可以对我们的产品提出一些建议。可能包括销售，市场，主管，法人，其他开发人员——我们工作同事中的任何可以对我们产品的性能或者功能提出建议的人。

在开发一个商业软件产品或者应用软件的过程中，这些不同的涉众类型经常会相互支持或者发生冲突。我还要补充的一点是，在这四个类型中，我们通常更关注内部人员和终端用户——经常会漏掉考虑我们的业务发起人（负责人）或者合伙人。

我怎样在演示中获取反馈？

在浏览一个具有挑战性例子过程中，我们假设您想要为一个商业软件产品获取反馈，这个产品正利用敏捷方法被开发。 如果您在这样的环境下进行操作，您会首先意识到一个演示的 想法 与内在的风险是同时发生——它被称作 知识产权。 根据您计划执行演示的国家，如果您还没有与律师合作来保护您的 IP，那么只要您在组织外部将它演示给其他人，就可能会丢失您的 IP。

思考一下这个动态所暗示的含义。我们假定您的团队利用的时间较短的迭代（它应该这样）：或许是两个星期。让我们进一步假设您想每两个星期都进行演示。那么您与您法律同行的相互配合会调整到这样的节奏吗？问题的关键点就是，不是它仅局限于知识产权，而是演示可以足够复杂——如果您不小心，那么您的演示就可能在开始之前就完全关闭。

各种不同的涉众的反馈

此时，让我们假设您已经处理了法律和其它的问题。您如何通过演示从各种涉众那获取反馈？参考图 1中的插图。

图 1：一个项目中的反馈间隔

如果您认为演示不再仅仅是以前那个演示，而是一个发生比较频繁的演示，它清晰地显示了那些涉众类型有怎样的用处。这里有一种方法，您可以作为从涉众那获取反馈的‘构思模型’：

在迭代 1结束时，您可能会给内部涉众，比如一个高级执行官，做一个演示。用这种方法使用首个迭代会有很多好处。开始，它会向这个团队澄清并激励他们理解，在每个首次迭代末尾，他们的软件要非常稳定从而能够进行演示，因为‘有些重要人物’将会对演示过程非常关注。其次，如果首次演示面向的是内部涉众，就没必要处理与知识产权相关的法律问题。第三，让我们假设这个演示在某些方面是失败的——那您实际上会丢失什么？的确，您可能会出丑，但是您不会再客户面前出丑，因此这是一件非常有意义的事。

在迭代 2的末尾，我们可能会演示 利益各方的交叉组织。您的许多不同类型的同事会对您的软件做出武断的判断，他们不能理解并认为这是欺骗人的行为。更有甚者，有些人会在新软件发布的早期利用利益各方的交叉功能，因此它有助于期望的设定。重要的是，它还能 重新设定组织的期望值，演示就是一个产品中 将要 显示的内容回顾，即 此时 产品中所看到的内容。在为我们的知识产权获取法律许可之前，提供给内部涉众的第二次迭代演示之前还有一次额外的演示，即在为我们的知识产权获取法律许可之前。

对于迭代 3，我们可能会给业务合伙人进行一次演示。现在正逐渐出现这样的情况，尤其是对于商业软件的开发人员，业务合伙人将可能帮助销售，部署，充当故障检修员，配置，自定义，以及培训其他人使用这个软件。因此，通常会出现这样的情况，这样的合伙人认为他们拥有丰富的关于您的软件的客户经验。这种观点是非常宝贵的。更重要的是，他们通常会忽略考虑这类合伙人的观点，从而会偏向于使这些人与其他可能会与他们有更多合作机会的人进行合作。考虑到满足业务合作伙伴需求对于未出您自己财政收入的重要性，可以参考这些做法，比如演示是非强制性的，但是是必须的。遗憾的是，这样的演示很难找到。

对于迭代 4，向您的终端用户演示您的产品是非常必要的，而且也是很恰当的。许多敏捷团队错误地认为这意味着将软件传送给一个或者更多的客户，让他们安装，然后给开发人员提供反馈（比如 beta 程序）。而对于有些团队，应该认为频繁的测试第二版是非常有好处的，一个在线管理人员可以通过电话会议或者 web 工具向一个或者许多终端用户进行演示，这样可以使反馈在各种终端用户之间激起对话活动。这种演示通常可以产生这样的情况，终端用户可以‘纠正’他们对于产品中应该包含的内容以及特定的功能如何运用的极端观点。

在第五次迭代末尾，向一个或者多个负责人进行演示是十分重要的——就商业软件而言，这些人要么是过去决定购买您的软件，要么是目前正考虑购买这个软件。让我们直面这个情况：这些演示安装起来非常困难，但是如果您事先准备好几个迭代，情况就完全不一样了。对于没有购买过您软件的负责人来说，您应该总是满腔热情地向 销售 您软件的人推荐这样的演示。

第六次（或者随后的）迭代会是什么情况呢？记住所有这些仅仅是众多处理敏捷演示问题方法中的一种。您可以向执行官或者其他内部人员同时进行演示，或者每次迭代末尾时为终端用户进行演示，或者对演示进行策划用户组会议，或者以其它方式执行。混合并使之相匹配。重要的是您在每次迭代时都向关心它的人进行了演示。同时，这个例子加深了这种以内部涉众开始的方法，并逐渐走向外部，您获得的最佳反馈很少是来自于内部方面的——而是要从那些即将购买并使用您软件的人哪里获取具有挑衅性的彻底的询问反馈。

在这种环境中还有一个额外的观点值得重视。如果操作是在一个特定的迭代中进行就会 难以发现 ，比如当在一个 API 上进行演示的时候，那该怎么办呢？要考虑的关键稳定是：谁会对这个迭代中已经完成的哦工作比较感兴趣，或者在最后几次迭代中？即使是关于 API 或者类似单调的功能，也会有人关心：一个合伙开发团队，一个激进的应用团队，或者其他人。总之，始终要对关心软件功能稳定性和价值的人进行演示。

根据涉众反馈做出决定

演示操作的另一方面并不会十分直观。参考图 2中的这个图表。

图 2： 在一个理想项目上的反馈间隔

在这个简单的哦图表中，想像一个理想的世界：从涉众那获取反馈，反馈以及表现在您所从事迭代的下一次迭代中。问题是，显示的世界是一个混乱的地方。并不是所有的反馈都是公平创建的。让我们假设一个例子，在第一次迭代之后，您将要在九十个终端用户面前进行一次演示，采用较少用户会议的方式或者其它类似的活动。 您可能会收到这样的事实，即您将立即执行他们的建议。因此，您在第二次迭代中就应该开始执行他们的建议。

现在，让我们假设在第二次迭代之后，您从一个负责人那获得反馈，但是您对他的观点并没有把握。如果您立即执行了这个反馈，您将很可能把错误的性能构建到您的产品中。将这个观点与您随后多次迭代中获取的反馈进行验证是非常明智的做法。

真正的目的是：通过对许多迭代过程中各种涉众进行演示的行为，您的整个团队能够开始从内心深处理解什么可以以及什么不能与它们产生共鸣。演示开始成为理智检查和创新行为，而不是团队的几次重要的获取反馈的机会。

看看最终看起来是什么状态。一个高级执行官去访问一个重要的客户，带回这个客户提出的关于一个关键功能的信息。这种情况下您该怎么做？您很可能会袖手旁观并进行一些猜测，假装您可以使当前的发布具备这种功能，从而提高软件的质量。假如情况相反，您拥有与各种利益相关者相互合作的历史记录，您可以对那个执行官说：

‘我知道您已经遇到关于功能 x 的麻烦。只要您需要，我们乐意为您效劳。但是这些业务目标（而非功能）是我们与其他人讨论时得来的。对于其中哦一个业务目标，有二十个客户曾要求我们使它包含在我们产品中，但是我们到现在还不能做到。我们还有一个业务目标，曾有十个客户要求我们这样做。您现在所遇到的这个功能到目前还没有一个人提出过。您会选择哪一种方式呢？’

除了演示还有其它获取反馈的方法吗？

Aile 方法强调以迭代的方式作为获取反馈的主要机制，但是除了这种方法以外，还有另一种方法值得考虑。Scrum 方法为我们提出了 产品所有制 的观念。简单地说，产品所有人对这个软件产品或者应用软件最终的功能具有决定权。对于复杂的项目， 主要产品所有人 的观点与产品所有人一起对于各种子元件或者应用程序用高层次方式组织起来。

这样很好，但或许更紧急重要的是，有一个对于产品所具备性能有最终决策人。但是我所担心的是，这个产品所有人将不能将演示模式置于突出的地位，或者过于相信所谓可靠的信息（比如一个行业分析师），从而反对各种利益关系人的各种观点。

我最终的看法是，产品所有人的观点固然重要，但是要获得有意义的反馈，更多的还是要考虑我们最终的需求。演示虽然重要，但仅仅有演示也是远远不够的。因此，需要另外三种方法来提高演示的重要性，简单概括为： 移植测试， 派驻， 以及 逆向派驻：

在 移植测试 中，为了更好地模仿客户是如何使用您的软件，要将客户架构移植到您的测试环境中。表面看来，这似乎是一个很困难或者机密的活动。事实上恰恰相反，想想您的软件可能在客户系统上留下的‘痕迹’： 预置文件，日志文件，数据场，配置文件，跟踪文件；您可以给它命名。此外，还可以考虑在客户环境中您软件的工作特性。有没有高峰使用期？您越能有创造性地模仿客户的运行环境，您就能对您的软件 实际上 如何被运用获得更多的信息。

派驻 为您和您的软件开发组织提供了一个很好的机会，从而可以真实地了解您的软件是如何被利用的。在派驻期间，您要引进一个或者更多的人从您的特殊客户或者合伙人那运行您的软件，并要求他们利用一周时间在开发过程中测试这个新的发布。他们总会发现一些您没遇到过的问题，这样他们不仅可以了解新产品的功能，还能了解新关于产品如何运用的超前的方面。

逆向派驻 允许您派遣我们技术团队的成员 —— 架构师，开发人员，测试人员，信息开发员，无论是谁——在一个产品环境中花时间与使用您们产品的用户一起合作。简单地说，除了观看客户在实际中进行操作，没有其它更好的方法来了解他们对软件使用的看法。这是无法替代的。在您的逆向派驻过程中，我们关注的焦点是利用强大的部署或者移植来解决问题，或者与使用我们软件高级功能的客户保持密切联系。不管您的利用关系者是谁，都要直接看到他们是如何从您的软件中受益或者如何努力克服您软件中不足的。

这里所简洁阐述的三种方法，应该被看作您所实施的迭代演示中最主要的方法，另外可以用对您软件如何使用以及它所传达的商业价值的深刻见解作为补充说明。这种见解是必不可少的。

还有其它获取反馈的方法吗？当然有。我们发现 betas 对我们的许多产品和应用软件十分有帮助。我们拥有可以共享代码，组件，以及发布前的完整产品的非正式机制。使其他人可以访问和使用您代码的最后一次迭代。这是一个非常有创意的方法。

分割思想

通过演示，移植测试，派驻，以及逆向派驻而进行的频繁的主要缺陷——一种建议我们更多地倾听各种涉众意见的途径——是，它将在某种程度上削弱我们所谓的‘突破性思维’。换句话说，有些人声称如果您所做的只是按照购买者，使用者，安装者，以及支持您软件的人的想法执行，您将永远不会创造出‘下一个伟大作品’。

首先，我认为一种能够促进知识增长的方法就是一种具有能够是主要团队成功的潜力的模式——这种方法能够确保稳定进步的方法，而这种进步不仅仅是取决于那些让人难以理解的美好灵感的。那就是说，如果您的团队开始像这里所描述的那样对他们的各种涉众产生激烈的影响，那么他们就会对 真正的需求与 他们现在的需求保持一致有更好的理解，难道不是吗?