客户参与敏捷开发的最佳实践?[关闭]

我对敏捷方法的经验主要是针对桌面应用程序的。当我们的客户处于远程时,我们会花时间让工程师到客户站点配置/安装一个演示平台。工程师与客户合作进行测试和演示设置/计划,该设置/计划将提供一个客户认为可以复制部署环境的重要方面但将演示系统与现有基础设施隔离的环境(以便我们可以随时推送更新)。工程师还设置了部署系统,将我们的应用程序转移到生产环境中,这样我们就可以在不在现场的情况下“部署”。我们的应用程序可以自我更新(针对每个版本或每个构建),并且我们会小心地将版本记录到日志中。 全部的 错误并将所有崩溃作为错误提交给我们的错误跟踪程序。这样我们至少知道哪里出了问题,即使我们不知道哪里出了问题。

对于出现在客户测试平台上的每个版本/构建,我们提供一个(简短的)屏幕广播,由项目负责人或主要开发人员叙述,演示任何新功能。发行说明包含我们希望客户考虑的任何长期问题(即无法通过电话或电子邮件立即解决的问题),应用程序将为用户显示这些说明。

最后,可能最重要的是,我们为客户和/或客户的联络人提供一个账户 我们的 日历服务器,并配置他们的日历应用程序以使用该帐户。然后这两种方式都可以——我们可以和客户安排时间(现场、电话、电子邮件等),他们也可以和我们的开发人员做同样的事情。

不管客户是在同一个隔间还是在地球的中间,除了通信延迟,关键因素是 可利用性 .

如果一个客户太忙以至于几天都无法回复您的电子邮件,则会导致您的迭代延迟或失败。

客户对敏捷有两个关键承诺:

1. 能够及时回答问题
2. 在迭代过程中不要改变他们的想法/优先级

顾客 必须 承诺对可用性达成合理的服务水平协议(SLA),例如1小时响应时间或24小时响应时间等,您需要根据滞后因素调整所有估计和计划。如果客户不承诺或不遵循,取消迭代并重新计划,将客户的承诺再次推向最前沿。做 不 只是“猜测”一下你认为客户可能想要什么。

底线:没有客户承诺,敏捷 不会工作 .

一种选择是:在“客户合作伙伴”网站上安装一个客户代理,当这些客户可用时,该代理可以提取您需要的信息。让这些代理构建坚实的关系,使它们能够表示客户视图。他们的时间都是你的。当出现他们无法回答的问题时,他们可以随时与客户合作伙伴联系——即使是在咖啡线上。

敏捷中客户的全部观点是与开发人员进行开放和自由的讨论(即即时反馈)。如果您的实际客户无法提供此服务,那么您需要一个能够担任此角色的中介/代理。你不 需要 实际的 客户,你只需要一个能很好地代表客户利益的人来满足客户的需求。

只是一些想法:

如果您确实选择使用wiki,请确保它支持整个wiki范围的“最近更改”列表,最好是特定于用户的列表。与开发人员的距离越远,电子邮件就越可能成为他们使用计算机的隐喻。如果他们不能立即知道什么时候有新的东西让他们看到,他们将永远不会去探索它。你最好也需要向他们发出信号,告诉他们你需要他们关注一些事情,否则他们会像对待CCS那样对待变化。

我非常相信创建交互的视频屏幕截图(叙述),并将它们分发给用户。与真正的演示不同,客户不觉得需要中断,他们可以反复回放和重新观看相同的交互,关注一些细节。

最后,如果您确实分发原型,请确保向某人(或至少是屏幕共享会话)发送原型,以查看原型是如何使用的。上下文设计是有效的。你可以以不同于你期望的方式指望人们使用你的原型,你必须理解他们是如何使用它来真正理解问题所在的,即使他们没有报告问题。

你有没有考虑过 LogMeIn .

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

这将解决远程客户问题,并支持敏捷过程中持续不断的客户反馈需求。

我用它作为以前的公司的技术支持,但没有理由(除了成本)它不适合您的情况。

这也是一个很好的方法,可以实际查看用户如何使用您的应用程序,从而找出哪些有效,哪些无效。

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

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

令人惊讶的是,当你涉及到客户时,你能从他们那里得到积极的反馈。

我们没有使用wiki,大部分的交流都是通过电子邮件、电话和屏幕共享应用程序完成的(我们使用的是gotomeeting,但是有很多其他的选择)。

你可能应该在一个地方和每个人一起做一次开球。面对面的时间是无价的。包括所有开发人员。准备一些元计划问题,但也有足够的时间只是混在一起。

我认为,对于高度依赖于客户参与的敏捷过程的大多数定义,您已经错过了“最佳实践”,这将是针对现场客户的,最好是“团队内”客户的。所以我想我们正在寻找“下一个最佳实践”。:)

有可能在现场引入“代理客户”。我不得不承认,我非常怀疑代理客户的价值。我担心的是,随着信噪比的增加,以及可能出现乱码消息,在这种混合中引入某种二流或不必要的业务分析师功能的风险。这也带来了允许忙碌的真实客户减少参与过程的风险,这可能导致不满。我想知道是否有一个拥有很好的领域知识的人最近退休了,可以担任顾问?

与远程客户的通信带宽比面对面要低得惊人,这是我在与其他国家的用户打交道之前没有完全意识到的。即使有了视频,损失也很大。

你的迭代时间有多长?计划迭代有多困难?进行更长的迭代和更频繁地进行更多的计划,或者缩短迭代长度并进行更小但更频繁的计划会话,会更容易吗?是否有多个客户参与

在每次迭代结束时,您是否有一个可用的和可用的构建?在下一次计划会议之前,相关用户是否有时间进行实际操作?让用户经常参与运输似乎是一个好主意,这可能是为小的频繁迭代(一周?两个星期?)

维基的想法可能奏效:你看过 FIT Framework ?它是一种集成的验收测试/wiki,可能有助于从远程客户那里获得验收测试。我想我也会寻求提供某种(独立或集成的)“项目仪表盘”,可能会定期向关键客户推送,也可能按需提供。用它来代替像在白板、大的可见图表之类的东西。有许多开放源码或低成本的选择可能有用-编写自己的简单替代方案也不需要太费时或昂贵。

最重要的是,要记住,“敏捷”是一种全面的开发标签,它强调的是 Agile manifesto . 在一种情况下被认为是“最好的”,在另一种情况下可能不是这样。如果你了解这些原则,并且经常用一个批判的眼光来回顾你的方法,那么你可能会非常接近你的情况下的最佳实践应用程序。

我已经有一段时间没看了,但是贝克和福勒在作者名单上,应该有一些有用的东西 Planning Extreme Programming .

在我之前的职位@drchrono.com,我汇总了来自全国20000名临床医生的数据/反馈/迭代请求。做到这一点的最好方法是宣传像uservoice.com这样的网站。我和50到100名医生(医生直接从我们的网站注册)举行了“每日网络直播”。在这些演示中,我将演示我们当前的产品并宣传用户语音,以将他们的反馈转化为我们开发团队的有用工具。所有这些都是远程完成的,导致经常性收入增长总体增长1400%。