敏捷团队如何处理客户和迭代？ [关闭]

Question

这个帖子是我previous one 的后续。这实际上是 2 个问题，所以我希望没有人介意，因为它们是相互依赖的。

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

第一次迭代要做什么？

如果我们从头开始，通常在最初的几次迭代中会做什么？只是给它一个月的开发时间来编写应用程序的核心代码，还是从具有有限预编码功能的简单线框开始？客户通常希望看到什么？闪亮的东西不起作用还是丑陋的东西起作用？

如何与客户沟通？

我们最初的想法是将流程设置为这样的：

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

在客户端设立联络点是个好主意，还是直接与所有客户沟通以防止沟通不畅？

---

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

Answer 1

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

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

关于与客户的沟通，我认为你的 scetch 应该稍微调整一下。用 Scrum 术语谈论你的“焦点”被称为“产品负责人”。让一个人与客户协调是很好的，因为要让不同的利益相关者就需求达成一致可能需要很多时间。然而，产品负责人（或联络人）应该直接与开发人员联系，而不是通过项目经理。事实上，产品负责人和项目经理的角色完全不同，如果分到两个人身上会收获很多。

产品负责人是利益相关者对开发团队的代言人。另一方面，项目经理负责项目团队的福祉，并经常跟踪预算等。这些角色有时会有相反的议程，让他们分成两个人，为利益冲突之间的谈判提供了一个健康的机会。如果一个人同时兼任两种角色，则该人通常倾向于偏爱其中一个，而自动减少另一个。您不想在项目经理总是将客户置于团队需求之前的团队中工作。另一方面，没有客户想要一个始终将团队需求放在首位而忽视客户的产品负责人。将责任分配给两个人有助于纠正这种情况。

Answer 2

我同意安德斯的回答。我的一个额外观察是，许多客户发现不可能忽视丑陋的。他们关心的是展示而不是功能。因此，您可能需要硬着头皮做至少一个“Nice”屏幕，以表明您会注意演示细节。

Answer 3

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

许多团队使用Iteration Zero 来：

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

零迭代非常特别，因为它不向客户提供任何功能，而是专注于以敏捷方式运行下一次迭代所必需的内容。但随后的迭代应该开始为客户带来价值。

只给它一个月的开发时间来编写应用程序的核心代码，还是从具有有限预编码功能的简单线框开始？

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

客户通常希望看到什么？闪亮的东西不起作用还是丑陋的东西起作用？

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

在客户端设立联络点是个好主意，还是直接与所有客户沟通以防止沟通不畅？

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

• 他提供了单一的权威声音
• 他对业务非常了解（即他可以回答问题）
• 他知道如何最大限度地提高投资回报率（即如何确定功能的优先级）

Answer 4

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

所以我当然不会花费“一个月的开发时间来编写应用程序的核心代码”。对我来说，这有点“大前端设计”反模式的味道。另请参阅YAGNI。

尽快从客户那里获取有关他们需要什么的信息，并在您的第一次迭代中实施那个。 “有价值”在客户眼中。 Thet 会知道他们是想看漂亮的 UI（也许他们想在贸易展上展示关于产品的幻灯片，所以功能可能是假的）还是简单的工作功能（也许你正在开发他们需要开始的东西 使用尽快）。 Business Value 是 他们所说的 将帮助他们完成工作。

我会尽可能缩短迭代（您的 2 周可以工作，我建议考虑 1 周）如果您绝对不能让您的开发团队和您的客户在同一地点，而不是与客户，我建议开会。演示您在上一次迭代中所做的工作，并就应该保留的内容、应该更改的内容以及应该添加的内容征求反馈。

正如其他人所说，您的“联络点”听起来像是产品负责人。我担心您的绘图是否意味着开发人员不与 PO 或客户进行交互。让敏捷发挥作用的一件事是当有大量的沟通时。与开发团队的沟通总是通过项目经理过滤，这几乎肯定会导致沟通不畅、不必要的工作和遗漏细节。

Answer 5

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

现在我不知道您的团队与您的客户的关系如何，但客户采取“提出要求 - 让工作系统退出”的态度并不罕见，因为他们在提出要求时很热情，但对测试该功能的时间。

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

干杯