4

这个线程是我之前的一个后续。这实际上是 2 个问题,所以我希望没有人介意,因为它们是相互依赖的。

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

第一次迭代要做什么?

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

如何与客户沟通?

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

替代文字 http://img690.imageshack.us/img690/2553/communication.png

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


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

4

5 回答 5

6

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

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

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

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

于 2010-05-03T09:25:20.527 回答
3

一般来说,如果我们从头开始,在最初的几次迭代中应该做什么?

许多团队使用零迭代来:

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

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

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

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

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

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

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

你需要一个人来代表客户(在 Scrum中被称为产品负责人):

  • 他提供了单一的权威声音
  • 他对业务有完美的了解(即他可以回答问题)
  • 他知道如何最大化投资回报率(即如何确定功能的优先级)
于 2010-05-07T09:23:50.620 回答
3

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

于 2010-05-03T09:32:35.490 回答
2

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

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

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

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

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

于 2010-05-06T16:48:26.090 回答
1

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

现在我不知道您的团队与您的客户的关系如何,但客户采取“提出要求 - 让工作系统退出”的态度并不罕见,因为他们在提出要求时很热情,但在提出要求时却不那么随和来测试这个功能。

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

干杯

于 2010-05-03T10:29:41.473 回答