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

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

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

关于与客户的沟通,我认为你的权杖应该稍作调整。用Scrum术语来说,你的“焦点”被称为“产品所有者”。让一个人与客户协调是很好的,因为让不同的利益相关者在需求上达成一致需要花费很多时间。但是,产品所有者(或焦点)应该直接与开发人员联系,而不需要经过项目经理。事实上,产品所有者和项目经理有着非常独特的角色,通过将两个人分开来获得很多好处。

产品所有者是利益相关者对开发团队的声音。另一方面,项目经理负责项目团队的福祉,并经常跟踪预算等。这些角色有时会有相反的议程,将其分为两个人,为利益冲突之间的谈判提供了一个健康的机会。如果一个人同时拥有两个角色,那么这个人往往倾向于偏爱其中一个角色,自动减少另一个角色。你不想在项目经理总是把客户放在团队需要之前的团队中工作。另一方面,没有客户希望产品所有者总是把团队的需求放在第一位,否定客户。把责任分给两个人有助于补救这种情况。

我同意安德斯的回答。我的另一个观察是,许多客户发现不可能贬低丑八怪。他们关心的是表现而不是功能。因此,您可能需要咬紧牙关,至少做一个“不错”的屏幕,以显示您将注意演示细节。

如果我们从头开始,通常在前几个迭代中要做什么?

许多团队使用 Iteration Zero 到:

• 设置开发基础设施(源代码管理、开发机器、自动构建、持续集成过程、测试环境等)。
• 对客户进行了培训,并同意他的方法,
• 创建特性的初始列表,确定最重要的特性并进行初始估计,
• 定义会议时间(计划会议、演示、回顾),选择迭代长度。

迭代0非常特别,因为它不向客户提供任何功能,而是关注以敏捷的方式运行下一个迭代需要什么。但随后的迭代应该开始向客户交付价值。

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

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

客户通常希望看到什么?有光泽的东西不起作用,还是丑陋的东西起作用?

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

在客户方有一个焦点是一个好主意,还是最好与所有客户直接沟通,以防止沟通错误?

你需要 一 代表客户的人(被称为 产品拥有者 在Scrum):

• 他提供了一个单一的权威声音
• 他对业务有很好的了解(即他能回答问题)
• 他知道如何最大化投资回报率(即如何优先考虑功能)

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

所以我肯定会的 不 花费“开发一个月来编写应用程序的核心代码”。对我来说,这是“大前卫设计”反模式的味道。此外,参见 YAGNI .

从客户那里获取关于他们最快需要什么的信息,并实施 那个 在第一次迭代中。”“有价值”在客户眼中。他们会知道他们是否想看到光滑的用户界面(也许他们想在展销会上展示产品的幻灯片,所以功能可能是假的)或者简单的工作特性(也许你正在开发他们需要的东西) 使用 ASAP)。 Business Value 是什么 他们说 帮助他们完成工作。

我会尽可能缩短我的迭代时间(你的两周可以工作,我建议考虑1周),如果你绝对不能让你的开发团队和你的客户在一起,而不是与客户打电话,我建议开个会议。演示您在前一个迭代中所做的工作,并征求关于应该保留什么、应该更改什么以及应该添加什么的反馈。

正如其他人所说,您的“焦点”听起来像是产品所有者。让我担心的是,你的画是否意味着开发人员不与订单或客户互动。使敏捷工作的一件事是当有大量的交流时。与开发团队的交流总是通过项目经理过滤的,几乎肯定会导致沟通错误、不必要的工作和遗漏的细节。

我同意给出的两个答案,但我只想从个人经验中增加一件事。您的客户接受了快速迭代的变化吗?以及在每次迭代之后提供反馈,这将要求客户对每个特性执行可用性测试。

现在我不知道你的团队与你的客户的关系是什么,但是对于客户来说,采取一种“提出请求-解决工作系统”的态度是很正常的,因为他们在给出需求时很热情,但在测试特性时却不那么随时随地。

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

干杯