如何处理敏捷团队中的客户端和迭代？

Question

此主题是我previous one的跟进。这实际上是2个问题，所以我希望没有人介意，因为他们彼此依赖。

我们正在开始一个新项目，我们认为这是一个尝试敏捷技术的好机会。我们对几本书和文章中的想法进行了头脑风暴，并提出了最适合我们的概念：2周迭代，然后与客户打电话，他们将在下一次迭代中选择他们想要的东西。我只有几个问题，我们无法弄明白。

第一次迭代怎么做？

如果我们从头开始，通常会在前几次迭代中做些什么？只需对应用程序的代码核心进行一个月的开发，或者从具有有限预编码功能的简单线框开始？通常客户想看到什么？闪亮的东西不起作用或丑陋的东西有效吗？

如何与客户沟通？

我们最初认为将流程设置为：

alt text http://img690.imageshack.us/img690/2553/communication.png

在客户端设置一个联络点是不是一个好主意，或者最好是直接与所有客户端进行通信以防止误传？

---

欢迎任何想法！提前谢谢。

Answer 1

在我看来，敏捷开发的一个关键成功因素是专注于在每次迭代中为客户提供价值。我肯定会选择“有效的丑陋东西”而不是“不起作用的闪亮东西”。执行闪亮的用户界面并试图让客户了解帽子业务逻辑需要花费大量时间来实施，这总是有风险的，Joel Spolsky撰写了一篇很好的文章。

如果客户想要增强UI，他们总是可以将其作为下一次迭代的要求。

关于与客户的沟通，我认为应该稍微调整一下你的观点。用scrum术语来说，你的“焦点”被称为“产品所有者”。让一个人与客户协调是好的，因为可能需要花费大量时间让不同的利益相关者就需求达成一致。但是，产品所有者（或联络人）应与开发人员直接联系，而无需通过项目经理。实际上，产品所有者和项目经理具有相当不同的角色，通过分裂为两个人而获得了很多收益。

产品所有者是利益相关者对开发团队的发言权。另一方面，项目经理负责项目团队的健康，并经常跟踪预算等。这些角色有时具有相反的议程，并且将他们分成两个人，为冲突的利益之间的谈判提供了一个健康的机会。如果一个人同时担任这两个角色，那么这个人往往倾向于支持其中一个角色，自动减少另一个角色。您不希望在项目经理总是将客户端放在团队需求之前的团队中工作。另一方面，没有客户希望产品所有者始终将团队的需求放在第一位，而忽略了客户。将责任分配给两个人有助于纠正这种情况。

Answer 2

我同意安德斯的回答。我的另一个观察是，许多客户发现不可能忽视丑陋。他们关注的是表达而不是功能。因此，您可能需要咬紧牙关并至少做一个“Nice”屏幕，以表明您将关注演示文稿的详细信息。

Answer 3

  

如果我们从头开始，通常会在前几次迭代中做些什么？

许多团队使用Iteration Zero来：

• 设置开发基础架构（源代码控制，开发机器，自动构建，持续集成过程，测试环境等），
• 教育客户并就方法论与他达成一致，
• 创建一个初始功能列表，确定最重要的功能并进行初步估算，
• 定义会议时间（计划会议，演示，回顾），选择迭代长度。

Iteration Zero非常特殊，因为它不向客户提供任何功能，而是专注于以敏捷方式运行下一次迭代所需的功能。但随后的迭代应该开始为客户创造价值。

  

只需对应用程序的代码核心进行一个月的开发，或者从具有有限预编码功能的简单线框开始？

不，不要在一个月内开发应用程序的核心。相反，立即开始提供应用程序的垂直切片（从UI到数据库），而不是水平切片。这并不意味着必须完成屏幕（例如，在搜索屏幕中仅实现一个搜索字段），但理想情况下它应代表最终的外观和视频。感觉（除非您在中间步骤中与客户达成一致）。重要的是制造能够为客户提供直接价值的东西逐步。

  

客户通常想看到什么？闪亮的东西不起作用或丑陋的东西有效吗？

根据我的经验，他们希望看到明显的进展，并希望尽快得到反馈。

  

在客户端设置一个联络点是不是一个好主意，或者最好是直接与所有客户端进行通信以防止误传？

您需要一个人来代表客户（在Scrum中称为产品负责人）：

• 他提供了一个权威的声音
• 他对业务有完全的了解（即他可以回答问题）
• 他知道如何最大化ROI（即如何确定功能的优先级）

Answer 4

敏捷通常希望快速为客户提供有价值的东西。

所以我肯定不花费“开发月份来编写应用程序的核心代码”。对我而言，那种“大前端设计”反模式的气味。另请参阅YAGNI。

从客户那里获取尽可能多的信息，了解他们最需要的内容，并在第一次迭代中实现 。 “有价值”是客户的眼睛。他们会知道他们是否想看到光滑的用户界面（也许他们想在展会上展示产品的幻灯片，所以功能可能是虚假的）或简单的工作功能（也许你正在开发他们需要开始的东西< em>尽快使用）。 Business Value是他们所说的将帮助他们完成工作。

我会尽可能地缩短我的迭代次数（你的2周可以工作，我建议考虑1周）如果你绝对不能让你的开发团队和你的客户在同一地点，而不是打电话客户，我建议开会。演示您在上一次迭代中所做的事情，并征求关于应该留下什么，应该改变什么以及应该添加什么的反馈。

正如其他人所说，您的“焦点”听起来像产品负责人。令我担心的是你的绘图是否意味着开发者不会与PO或客户交互。让敏捷工作的一件事是有很多沟通的时候。与开发团队的沟通总是通过项目经理过滤几乎肯定会导致沟通不畅，工作不必要，错过细节。

Answer 5

我同意给出的两个答案，但我只想从个人经验中加上一点。您的客户是否购买了快速迭代的变化？以及在每次迭代后提供反馈，这将要求客户对每个功能执行可用性测试。

现在我不知道你们的团队与你们的客户有什么关系，但是客户采取“提出请求 - 获得工作系统”的态度并不罕见，因为他们在提出要求时非常热情，但并不是那么热衷于测试功能的时间。

现在这可能完全不适合您的情况，但总是值得考虑您的客户工作流程以及您的团队的变化。

干杯