客户参与敏捷开发的最佳实践？

Question

我们需要让我们的客户开发合作伙伴参与我们的开发过程。我们或多或少遵循敏捷方法。一些客户合作伙伴是偏远的，其他合作伙我们需要尽量减少差旅费用。

我们的客户正在接受医疗保健，他们往往很忙，很贵，也很难安排。

哪些实践和技术可以支持客户参与？我们正在使用电话，电话会议和电子邮件。我们对利用维基技术感到好奇，并希望听到对其他人有用的东西。

Answer 1

无论客户是在同一个小隔间还是在地球的中途，除了通信延迟 - 关键因素是可用性。

太忙而无法在几天内回复您的电子邮件的客户将导致您的迭代迟到或失败

客户对敏捷有两个重要的承诺：

1. 可以及时回答问题
2. 在迭代期间不改变主意/优先级

客户必须承诺提供有关可用性的合理服务级别协议（SLA），例如1小时响应时间或24小时响应时间等，您需要通过滞后因子调整所有估计和时间表。如果客户不会提交或不提交，请取消迭代并重新规划，再次将客户的承诺置于最前沿。 不只是“猜测”您认为客户可能想要的东西。

结论：没有客户的承诺，敏捷将无效。

Answer 2

我对敏捷方法的经验主要用于桌面应用程序。当我们的客户偏远时，我们花了一些时间让工程师到客户现场配置/安装演示装备。工程师与客户一起进行测试和演示设置/计划，该环境将提供客户认为复制部署环境重要方面的环境，但将演示系统与现有基础架构隔离开来（以便我们可以随时推送更新） ）。工程师还设置了部署系统，将我们的应用程序转移到生产环境中，这样我们就可以在不在现场的情况下“部署”。我们的应用程序可以自我更新（针对每个版本或每个版本），我们会仔细检测版本以记录所有错误，并将所有崩溃作为错误提交给我们的错误跟踪器。这样我们至少知道出了什么问题，即使我们不知道什么是正确的。

对于显示在客户测试平台上的每个版本/版本，我们提供（简短）截屏视频，由项目负责人或主要开发人员讲述，演示任何新功能。发行说明包含我们希望客户考虑的任何长期问题或问题（即无法通过电话或电子邮件立即解决的问题），并且应用程序会为用户显示这些说明。

最后，也可能最重要的是，我们将客户和/或客户的联络人员放在我们的日历服务器上，并配置他们的日历应用程序以使用该帐户。然后这两种方式 - 我们可以与客户安排时间（现场，电话，电子邮件等），他们也可以与我们的开发人员一样。

Answer 3

一个选项：在“客户合作伙伴”网站上安装客户代理，该客户代理可以提取这些客户可用时所需的信息。让这些代理建立牢固的关系，使它们能够代表客户视图。他们的时间全是你的。当问题出现时他们无法回答时，他们可以随时访问您的客户合作伙伴 - 即使是在咖啡热线中。

Answer 4

敏捷客户的全部意义在于与开发人员进行公开和自由的讨论（IE即时反馈）。如果您的实际客户无法提供此服务，那么您需要一个可以填补此角色的中介/代理。您不需要 实际客户，您只需要能够充分代表客户利益的人，以满足客户的需求。

Answer 5

只是一些想法：

如果您确实选择使用Wiki，请确保它支持整个wiki范围的“最近更改”列表，最好是一个特定于用户的列表。与开发人员距离越远，就越有可能将电子邮件作为其计算机使用的隐喻。如果他们不能立即告诉他们什么时候有新东西可以看，他们就永远不会探索它。您最好还需要向他们发出信号，告诉他们您需要关注事项，或者他们会像CC一样对待变化。

我非常相信创建交互视频屏幕（叙述）并将其分发给用户。与真实的演示不同，客户不会觉得他们需要打断，他们可以反复回放并重复观看相同的交互，注意细节。

最后，如果您确实分发原型，请确保派人（或至少是屏幕共享会话）以查看原型的使用方式。上下文设计是有效的。您可以指望使用原型的人与您期望的方式不同，并且您必须了解他们如何使用它来真正了解问题所在，即使他们没有报告问题。

Answer 6

您是否考虑过类似LogMeIn的内容。

这将允许客户登录已经运行应用程序的网络上的PC，或者允许您在其中一台计算机上安装/更新应用程序。

这将解决远程客户问题，并且还将支持敏捷流程中持续的客户反馈要求。

我用它以前的公司提供技术支持，但没有理由（除了可能成本）它不适合你的情况。

这也是了解用户如何使用您的应用程序的一种很好的方式，因此可以找出哪些有效，哪些无效。

Answer 7

首先，确保您有产品经理或产品所有者关闭开发人员。这个人将管理与客户的关系。

然后，产品经理可以在每次迭代结束时向客户演示产品，并在开发人员需要反馈以实现用户故事时询问客户问题。

当您参与其中时，您可以从客户那里获得积极反馈，这真是令人惊讶。

我们没有使用维基，大部分通讯都是通过电子邮件，电话和屏幕共享应用程序完成的（我们使用的是GoToMeeting，但有很多替代方案）。

Answer 8

你可能应该在一个地方与所有人一起开始。面对面的时间非常宝贵。这包括所有开发人员。准备一些元计划问题，但也有足够的时间来混合。

Answer 9

我认为，对于高度依赖客户参与的敏捷流程的大多数定义，您已经错过了“最佳实践”，这对于现场，最好是“团队内”客户始终存在。所以我想我们正在寻找一种“次佳实践”。 ：）

有可能在现场引入“代理客户”。我不得不承认对代理客户的价值持怀疑态度。我担心在混合中引入某种二流和其他不必要的业务分析师功能的风险，信噪比的增加和乱码消息的可能性。它还存在允许忙碌的真实客户减少他们参与流程的风险，这可能会导致不满。我想知道是否可能有一些具有良好领域知识的人最近退休并可能以此身份担任顾问？

与远程客户的通信带宽比面对面低得惊人，直到我开始与另一个国家的用户打交道之后，我还没有完全意识到这一点。即使有视频，损失也很大。

你的迭代有多长？规划迭代有多难？可能更容易进行更长的迭代并更少地完成更多的计划，或者减少迭代长度并进行更小但更频繁的计划会话？是不是一个客户涉及​​

在每次迭代结束时，您是否拥有可用且可用的构建？参与的用户是否有时间在下一次计划会议之前获得实际操作时间？通过频繁发货保持用户参与似乎表面上是一个好主意，可能会立即进行小规模的迭代（一周？两周？）

维基的想法可能有用：你看过FIT Framework吗？这是一种集成的验收测试/ wiki，可能有助于从远程客户那里获得验收测试。我想我也希望提供某种（单独的或集成的）“项目仪表板”，可能会定期推送给关键客户以及按需提供。用它作为白板，大可见图表之类的东西的替代品。有许多可供选择的开源或低成本选项 - 编写您自己的简单替代方案也不需要太费时或昂贵。

最重要的是，请记住，“敏捷”是一种全能的标签，用于开发，重点是Agile manifesto中所支持的价值观和原则。在一种情况下被认为是“最好的”在另一种情况下可能不是这样。如果您了解原则并定期以批判的眼光审查您的方法，那么您可能会接近最适合您情况的最佳实践应用。

我有一段时间没有看过它，但是在作者列表上有Beck和Fowler，Planning Extreme Programming中应该有一些有用的东西。

Answer 10

在我之前的职位@ drchrono.com中，我收集了全国20,000名临床医生的数据/反馈/迭代请求。最好的方法是向uservoice.com这样的网站传福音。我举办了“每日现场网络示范”，有时有50到100名医生（医生从我们的网站注册）。在这些演示中，我将展示我们当前的产品并传播用户的声音，以便将他们的反馈推动到我们的开发团队的有用工具中。所有这些都是远程完成的，并导致经常性收入增长总体增长1,400％。