如何与敏捷团队中的客户和迭代打交道？ [关闭

Question

这个线程是我的后续 前一个. 。实际上，这是两个问题，所以我希望没有人互相依赖。

我们正在开始一个新项目，我们认为这是尝试采取行动敏捷技术的绝佳机会。我们对我们在几本书和文章中阅读的想法进行了头脑风暴，并提出了最适合我们的概念：2周的迭代，然后与客户联系，他们会选择他们想在下一次迭代中拥有什么东西。我只有几个问题，我们无法弄清楚自己。

在第一次迭代中该怎么办？

通常，如果我们从划痕开始，该怎么办？只需将其开发一个月以编码应用程序的核心，或者从具有有限的预编码功能的简单线框架开始？通常客户想看什么？闪亮的东西不起作用或可行的丑陋东西？

如何与客户沟通？

我们最初认为将过程设置为这样的过程：

Alt Text http://img690.imageshack.us/img690/2553/communication.png

在客户方面有一个焦点是一个好主意，还是最好与所有客户进行直接沟通以防止沟通不畅？

---

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

Answer 1

我认为，敏捷开发的关键成功因素是专注于在每次迭代中为客户提供价值。我肯定会选择“确实有用的丑陋的东西”而不是“无效的闪亮东西”。做闪亮的UI并试图让客户了解帽子业务逻辑需要大量时间实施是有风险的 乔尔·斯波尔斯基（Joel Spolsky） 已经写了一篇很好的文章。

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

关于与客户的沟通，我认为您的SCETCT应该进行稍微调整。用Scrum说话您的“焦点”称为“产品所有者”。让一个人与客户协调是一件好事，因为要使不同的利益相关者对需求达成共识可能需要大量时间。但是，产品所有者（或焦点）应与开发人员直接联系，而无需浏览项目经理。实际上，产品所有者和项目经理具有非常不同的角色，可以通过两人分手来获得很多收益。

产品主是开发团队的利益相关者的声音。另一方面，项目经理负责项目团队的福祉，并且经常跟踪预算等。这些角色有时会有反对的议程，并让他们分手两个人为矛盾的利益之间的谈判提供了健康的机会。如果一个人都有两个角色，那么这个人通常倾向于偏爱其中一个角色，自动减少另一个人。您不想在项目经理始终在团队需要面前将客户提供的团队工作。另一方面，没有客户想要一个总是将团队需求放在首位的产品所有者，否定客户。将责任分解在两个人身上有助于解决这种情况。

Answer 2

我同意安德斯的回答。我的一个额外观察是，许多客户发现不可能无知丑陋。他们关心演示而不是功能。因此，您可能需要咬着子弹并进行至少一个“漂亮”屏幕，以表明您将注意演示细节。

Answer 3

通常，如果我们从划痕开始，该怎么办？

许多团队都使用 迭代零 到：

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

零迭代非常特别，因为它不会为客户提供任何功能，而要关注以敏捷方式运行下一次迭代所需的功能。但是随后的迭代应开始为客户提供价值。

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

不，不要在一个月内开发应用程序的核心。取而代之的是，立即开始交付应用程序的垂直切片（从UI到数据库），而不是水平切片。这并不意味着必须完成屏幕（例如，在搜索屏幕中仅实现一个搜索字段），但理想情况下应该代表最终外观和感觉（除非您同意客户在中间步骤中同意）。重要的部分是建立为客户提供直接价值的事物 逐步.

通常客户想看什么？闪亮的东西不起作用或可行的丑陋东西？

根据我的经验，他们希望看到可证明的进展，您希望尽快获得反馈。

在客户方面有一个焦点是一个好主意，还是最好与所有客户进行直接沟通以防止沟通不畅？

你需要 一 代表客户的人（被称为 产品拥有者 在Scrum中）：

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

Answer 4

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

所以我当然会 不是 花费“开发月份到应用程序的核心”。对我来说，“大型前设计”反图案的气味。另外，请参阅 Yagni.

从客户那里获取有关他们最需要什么的信息，并实施 那 在您的第一次迭代中。客户眼中的“有价值”。 Thet会知道他们是否想看到Slick UI（也许他们想在贸易展览会上进行有关该产品的幻灯片展览，因此功能可以是假的）或简单的工作功能（也许您正在开发他们需要开始的东西 使用 尽快）。 商业价值 是什么 他们说 将帮助他们完成工作。

如果您绝对不能让您的开发人员团队和客户共同置于协同，而不是与客户打来电话我建议开会。演示您对以前的迭代的所作所为，并征求有关应该停留，应该改变什么以及应该添加的内容的反馈。

正如其他人所说，您的“焦点”听起来像是产品主。我对您的图纸感到担心的是，这意味着暗示开发人员不与PO或客户互动。使敏捷工作的一件事是有很多沟通。几乎可以肯定，与开发团队的沟通始终通过项目经理进行过滤，这肯定会导致沟通不畅，不必要的工作和遗漏的细节。

Answer 5

我同意给出的两个答案，但我只会从个人经验中添加一件事。您的客户是否为快速迭代而购买了更改？除了在每次迭代之后提供反馈，这将要求客户对每个功能进行可用性测试。

现在，我不知道您的团体关系与您的客户是什么关系，但客户不寻常地接受“提出请求 - 启动工作系统”的态度，因为他们在提出要求时很热情，但在时间上不像那样的时间测试该功能。

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

干杯