9

这是另一个试图弄清楚 Scrum 在现实生活中如何/应该如何工作的问题。这是我遇到的一个典型场景：

注意：下面不使用术语“产品所有者”。那是因为真正的“产品负责人”——在这种情况下是产品经理——不会做出最终决定。DB Lead 在决定应用程序如何与 DB 交互时对许多事情有最终决定权。QA 对事物的外观/工作方式有自己的想法 - 并且他们的想法作为错误输入，并且通常（每个人）都希望被这样对待。

  1. 产品经理写了这样一个故事“X 用户需要一个页面来做 Y”。
  2. 在 sprint 计划会议上，故事被添加到 sprint backlog 中。
  3. 一些可怜的开发人员抓住（或分配）了这个故事。
  4. 开发人员询问产品经理“您希望页面是什么样的”。
  5. 产品经理（如果有的话）说：“嗯，好吧，它需要收集 A、B 和 C。”
  6. 开发人员开始对它应该是什么样子进行最佳猜测。
  7. 开发人员尝试将页面连接到存储过程并询问数据库领导一些问题。DB 负责人说“Page 也需要 D 和 E。不应该需要 B”。
  8. 开发人员进行更改并提交。
  9. QA 说“我认为 E 令人困惑”。
  10. 开发人员必须努力让 QA、DB 负责人和产品经理就最终页面的内容达成一致。

我的理解（根据我们对 scrum 的学习方式）是开发人员有责任充实页面的需求。在我们的环境中，如上所示，这给开发人员带来了令人沮丧的体验，并且在等待获得所有权力以就需求做出统一决定时浪费了大量时间。

有时可能需要数小时才能确定 2 小时任务的要求！与 1 人相处已经够难的了 - 3 人就更难了！

我知道这是反 Scrum，但在我看来，产品经理、数据库主管和 QA 团队应该在计划会议之前开会，并讨论要添加到 sprint 的任务的细节。（开发人员很少考虑任何输入，当我们在会议中尝试这样做时，可能需要一整天 - 不是开玩笑 - 才能为积压中的所有项目列出所有细节。）

有没有人处理过这个？有什么建议么？我不想啰嗦太久，所以如果您需要更多详细信息，请告诉我。

谢谢！

4

13 回答 13

10

那是因为真正的“产品负责人”——在这种情况下是产品经理——不会做出最终决定。

这正是你的问题。Scrum 说

产品负责人不是一个人，而是一个角色。每个人都可以成为产品负责人。

如果您的产品经理无法做出这些决定，恕我直言，他不是产品负责人。在这种情况下，找到可以做出这些决定的人，因为这是您真正的产品所有者。

作为开发人员（scrum 中的“团队”角色），我只需要了解产品负责人对这个功能的期望。他是所有者，他向我解释了页面的外观，我将根据他的描述进行制作。数据库负责人不是产品所有者。QA 不是产品所有者。我按照产品负责人的要求制作了页面，如果数据库负责人或 QA 对此有疑问，他们应该与产品负责人交谈。或者实际上产品负责人应该提前与他们交谈。

另外，如果 DB 负责人和 QA 也以某种方式为产品负责人服务，为什么他们没有参加 sprint 计划会议？在那种情况下，当产品经理说 A、B 和 C 时，他们可能会立即喊出“反对”。DB 负责人可能会说他需要 D 和 E，而 B 不应该在那里。QA 可以说，他们认为 E 令人困惑。只要在冲刺之后最终必须批准我的实施的人甚至不同意他们想要拥有的东西，我根本不会碰这个东西。

于 2008-10-09T21:41:58.603 回答
2

我注意到的一些事情...

1）您提到开发人员提取用户故事

确实应该在计划期间将其分解为任务。

2）您提到要花一整天的时间才能解决问题。

Sprint 计划可能需要一整天的时间。你最好一次性花费这些时间并获得足够的信息以朝着正确的方向前进，而不是花费大量时间重新散列。

于 2008-10-09T18:44:23.797 回答
2

几个建议：

上下文：“X 用户需要一个页面来执行 Y”缺少上下文。我喜欢这样的框架“作为一个 XI 想要做 Y，所以我可以 Z”。它略有不同，但 Z 部分添加了用户尝试完成的内容的上下文。

验收标准：你没有提到验收标准。故事应该包括一个验收标准列表，以表明故事何时完成。我喜欢这样的措辞“给定 X，当 Y，然后是 Z”（例如，“假设X 用户已登录并且银行余额为正，当他导航到 Y 页面时，他会在余额旁边看到一个笑脸”。通常，会有这些验收标准的清单。

我想你会发现，当产品经理被迫定义验收标准时，他/她会更好地了解他/她想要通过故事完成什么，并且可以更详细地传达它。另外：我还发现测试人员审查可测试性问题的验收标准很有帮助。

What vs. How：听起来你在迭代过程中仍在争论需要完成什么。INVEST* 故事标准中的可协商性概念更适用于故事的实施方式。在故事添加到迭代之前应该已经定义的内容。

*INVEST - 独立、可协商、有价值、可评估、小型、可测试

于 2008-10-10T17:26:24.690 回答
1

我的建议是让 PO 在决定什么是预期行为方面成为任务的所有者。这可能意味着要经历十几个或更多奇怪的情况，其中构建的系统允许 Y 也必须做一些事情，以防 Z 关闭或 W 没有及时响应等。

虽然充实细节可能是开发人员的工作，但这只是向适当的人提出问题。PO 应该说“哦，对不起，我现在确实想要 D 和 E”，因为流程的一部分是处理不断变化的需求，因此关键在于结果而不是 101 步骤已完成以使产品的新版本为冲刺结束做好准备。

另一种选择是让团队负责人或小组经理，如果在一家大公司，开发人员的经理应该与项目分开，成为你可以说的资源，“我想做 D，但需要更多细节并且似乎无法安排与 PO 的会面，”并希望此人好运。

于 2008-10-09T19:02:45.723 回答
1

问题不在于“Scrum 与现实世界的冲突”。问题是“尽管存在其他问题，但我希望 Scrum 能带来好的东西”。

您的问题的根本原因是有人不想等待利益相关者。其他一切都是解决此问题的方法。让开发人员早早地从一个不完整的故事开始会导致开发人员、DBA 和 QA 之间的不愉快的舞蹈。早点开始是 - 嗯 - 没有帮助。

如果你有一个可靠、一致的用户故事，DBA 和 QA 就无法发号施令。只要你有细节，你就可以胜过他们的意见。

您不能责怪您当前的流程（或一般的 Scrum），因为您没有来自利益相关者的可靠用户故事。

有时可能需要数小时才能确定 2 小时任务的要求！与 1 人相处已经够难的了 - 3 人就更难了！

你让这听起来像是一件坏事。2 天的谈话确定要求，然后是 2 小时的技术工作是一个很好的比例。这表明，关心和思考。这表明你在做正确的事。

小心强加旨在让开发人员忙碌的临时任务，以免他开始用剪刀跑。

如果要花几天时间才能把故事讲好，那么，我能说什么呢？这需要几天时间。度过这些日子。这就是它所需要的。

不要因为开发人员不编码而责骂他们。第一个开始编码的人输了。

解决方案

当 PO 无法设想由软件赋能的未来状态时，您需要在流程中引入具有技术远见的人。有时他们称这个角色为“业务分析师”。一些业务分析师是壁橱设计师和建筑师。解雇他们。一些业务分析师可以帮助 PO 明确由新软件支持的新工作方式的愿景。奖励他们。

于 2008-10-09T22:18:30.400 回答
1

听起来您在混淆 Scrum 和 XP 的Planning Game。当然，您可以根据组织的需要调整方法，但即使作为 XP 规划游戏，我认为它也没有抓住重点。

规划游戏或 Sprint 规划的基本前提是开发人员或“猪”（包括 DB Lead 和 QA）正在放弃权利，将产品的“什么”和“何时”指定给利益相关者或“鸡”（产品经理）。因此，那些能够指定“什么”的人事先开会讨论要提交的细节或优先事项，这当然不是“反 Scrum”。

正如我在这里回答的那样，详细信息在 Sprint backlog 中填写。这可能是用户故事的形式，但 Sprint Backlog 更多地切入设计和任务。

于 2008-10-10T04:43:48.970 回答
0

你可能不需要在所有事情的计划会议之前开会，但只有在发现冲突时才开会。与所有利益相关者快速开会并做出每个人都同意的决定可能是最简单的。

仅仅因为你进行了 scrum，并不意味着你不应该在之后举行更小、更有针对性的会议。

于 2008-10-09T18:29:35.277 回答
0

开发人员有责任确保他完全理解在 givrn 任务中他需要做什么。如果某些要求不清楚，您必须要求澄清，直到开发人员和他的同事/经理都完全了解需要做什么。

您应该提出诸如“我们如何定义此任务的成功执行”或“客户如何期望它”等问题。

开发人员应确保在迭代计划会议结束之前，他完全了解下一个周期需要做什么。如果某些要求仍不清楚，则应在 SCRUM 会议中将其作为阻碍您实现目标的事情来解决。

于 2008-10-09T18:36:40.007 回答
0

呃，首先与所有利益相关者交谈，然后设计/实施故事不是更简单吗？

编辑：根据评论和对原始问题的更仔细阅读，我认为您可能一直在称您的流程为“敏捷”或“Scrum”，但实际上并非如此。根据您的原始观点，这就是我认为出了问题的地方 [警告：我对 scrum 不是很熟悉，但我已经使用 XP 好几年了]：

  1. 产品经理写了这样一个故事“X 用户需要一个页面来做 Y”。

    • 产品经理不是客户，他也不是开发人员。用户故事应该由客户和开发人员编写。所以，这一步不是 XP/Agile，这是瀑布。如果“用户X”需要一个页面来做“Y”，那么你和用户X必须写关于Y的故事。只有这样，开发者和用户才能对故事有一个共同的理解，这就是用户的全部意义。故事。PM 说“去写一个页面让用户 X 做 Y”不是一个故事，而是一个任务。所以，看起来你的团队从一开始就掉队了。

  2. 在 sprint 计划会议上，故事被添加到 sprint backlog 中。

    • 所以现在 sprint backlog 实际上只是 PM 创建的任务列表。你已经被我的朋友吓坏了，这不是敏捷方法，这是伪装成敏捷方法的传统项目管理。

  3. 一些可怜的开发人员抓住（或分配）了这个故事。

    • 让我们看看，因为故事是对话的占位符，而让开发人员和客户一起编写故事的目的是提供对话基础的相互理解，然后随机分配一个故事（这实际上是一个 PM任务）给没有进行过这种对话的开发人员同样不敏捷 - 这只是任务分配，在所有程序员都是可互换的机器中的齿轮假设下，这当然是荒谬的

  4. 开发人员询问产品经理“您希望页面是什么样的”。

  5. 产品经理（如果有的话）说：“嗯，好吧，它需要收集 A、B 和 C。”

    • 再一次，PM 不是客户；谁在乎 PM 对页面的看法？重要的是用户 X 对页面的看法。

  6. 开发人员开始对它应该是什么样子进行最佳猜测。

我现在要停下来，因为我越来越沮丧。这不是敏捷，这很荒谬：

  • 客户不参与故事
  • 开发者不参与故事
  • 没有发生开发人员与客户的对话
  • 总理正在编造事情
  • 随机的开发人员被交给了由 PM 组成的任务

这应该以何种方式成为敏捷方法？称它为敏捷并不能做到这一点——这完全是关于方法的原则，而不是术语。难怪这个过程失败了！

于 2008-10-09T19:20:50.837 回答
0

我还没有做过 scrum（尽管我已经研究过它并且喜欢它），但在我看来，如果用户故事真的像你所说的那样准系统，那么 PM 就没有做好他们的工作。至于度过一天的实用性：召集一次与所有 3 方的会议并一起讨论，而不是试图成为中间人。

于 2008-10-09T19:34:48.313 回答
0

我的理解（根据我们对 scrum 的学习方式）是开发人员有责任充实页面的需求。

是和否。

是的，如果您可以自己从头到尾执行任务。

不，如果您的代码与其他人的代码交互，或者用户的 I/O 是面对面的，那么您需要就代码/用户界面的规范达成一致。最重要的是，什么不能做，以及如何在必要时解决它。

在我们的环境中，如上所示，这给开发人员带来了令人沮丧的体验，并且在等待获得所有权力以就需求做出统一决定时浪费了大量时间。

我完全知道那是什么感觉！你不是碰巧在我这里工作吗？:)

这是我必须经历的一个真实世界的例子：

  • 设计师预先设计了一个 UI 页面。它是关于显示分层的 HTML 页面，并在顶部和右侧有按钮，有点像选项卡式对话框，但两侧都有选项卡。样机看起来不错，看起来很合理，没有什么大问题。伴随着一些关于这个对话框可以做什么等的详细描述。似乎一切都已经完成并说完了。
  • 设计师实际上给了我在我们的数据库中实现数据结构的任务。这是不寻常的，但已通知 Scrum Master。尽管如此，由于人类语言的语言障碍以及他是设计师而我是来自不同领域的程序员这一事实，我们俩的交流还是有点困难。
  • 我致力于实现数据库中的表并将其 UI 添加到我们的数据库前端应用程序中。我对小问题做了一些假设，这通常是我得到的大多数任务的情况。我还调整（尽我所能标准化）给我的数据，并告诉它如何在对话框中使用，以便它最适合 DB 前端应用程序的设计。出现了一些我试图解决的问题，因为如果我进行了常规的非规范化，其中一个设计要求要么呈指数级增长（数据库），要么在前端变得不可用。所以我选择为此买单，我得到了，但不幸的是，这后来证明是一个严重的误解，让我们陷入困境。
  • 接下来，导出数据库的程序员有一些问题。我回答他们。我重新设计了一些东西，以便他可以更轻松地导出内容，我们分别正在解决他工作环境的一些限制。其他问题只需要澄清设计师使用的“不寻常和令人困惑的术语”。
  • 第三个程序员开始着手实现设计师的 UI 模型。随即提出了一些问题。正在对数据库表进行更多调整。突然间，我承诺了一些我在 DB 前端应用程序中难以实现的事情，但我能够解决它。但是，DB 导出器程序员也必须重写一些代码，而且他对新的数据布局不满意。
  • 现在我们发现在第 1 部分中存在重大误解。我得到了另一个返工任务来重做 50% 的工作。幸运的是，还没有人将生产数据输入数据库，所以我可以废弃大部分。尽管如此，这项任务已经花费了最初设想的 3 倍。
  • 同样，这需要导出器和 UI 程序员添加更多时间。
  • 最后，有人开始将生产数据输入数据库前端并且不知道如何使用它。他发现自己在两个程序员之间进行交流：UI 程序员和 DB 前端程序员（我），他们对任务有不同的看法。正在进行更多的返工，但大部分时间都花在解释事情是如何工作的。

这只是故事中非常浓缩的一小部分。我认为这不是一本有趣的书，我不能提供太多细节，也不想记住发生的一切。这个例子中的主要问题是什么？

  • 不熟悉数据库和前端的设计师
  • 不熟悉 UI 设计的 DB Programmer
  • 设计师和DB程序员有误会，各自根据经验做出自己的假设
  • 在技​​术设计上做出让步，以适应 DB 前端和 DB 导出器的限制
  • 避免在数据库前端和导出器中编写成本代码，因为这会浪费最初的任务估计时间
  • 由于不断的需求和实施变化，一直存在混乱。我们没有同时合作，而是一次一个，间隔几天甚至几周。

但最大的问题是：Pod 间通信。每个人都习惯于在自己的吊舱内工作，而且由于人们彼此了解以及他们在做什么，因此并非所有事情都需要解释或写下令人痛苦的细节。然而，一旦与其他 pod 成员开始交谈，没有人会想到沟通会如此困难。人们想非常详细地了解看似显而易见的事情。有些问题只是没有“坚持”并且一遍又一遍地出现。这让所有相关人员感到沮丧，这进一步限制了沟通的有效性。

我的意思是：通信是关键，一旦涉及到其他通常不能一起工作的 pod，通信开销可能会翻两番。如果你没有为此做好准备，它可能会导致挫败感、士气低落、执行乏力等等。

人们越习惯于彼此合作，他们就越不需要交流。反过来也是如此。请注意这一点并提前计划。

于 2008-10-09T19:45:43.157 回答
0

我的团队一直面临这个问题。我们得到了一个非常广泛的用户故事，并被要求在 2 周的迭代中交付其中的几个。我们花了一周时间与 PO 交谈（我们跨站点工作）充实一个用户故事的细节（如果幸运的话，我们可以做两个），并编写我们自己的用户故事，以便可以针对功能/验收测试进行编写他们。然后我们开始估计每一个的复杂性，并承诺我们可以在剩下的一周内实际完成多少。

一个广泛的用户故事总是被分解成至少 6 或 7 个更精细的用户故事。这让我们了解了更广泛的用户故事到底有多复杂，并且通过反复这样做，我们希望与我们的 PO 沟通，他们需要为我们提供更好的用户故事，但到目前为止我们还没有取得太大的成功。

正如 S.Lott 在他的回答中所说，如果您的用户故事不清楚或过于高级，您必须扮演业务分析师的角色，以弥合 PO 和开发团队之间的差距。

于 2008-10-10T04:24:26.997 回答
0

我知道这是反scrum，

我建议你（和你的队友）不要过分关注“Scrum”、“反 Scrum”、“XP”之类的。

您是软件创建者，因此，我鼓励您相信自己是最优秀的人和专业人士，可以创建您付费创建的软件，无论有关敏捷（或任何其他方法）的书籍或顾问怎么说

但在我看来，产品经理、DB Lead 和 QA 团队应该在计划会议之前开会，并讨论要添加到 sprint 的任务的详细信息

同意你。

这就是我在参与的许多（敏捷）团队中成功完成的。这种做法有助于更好地了解要完成的工作，并估计复杂性。这不是要在几周内编写规范文档，而是要更好地了解故事背后的内容，包括功能和技术方面。维基页面（或类似工具）通常足以收集此类信息。

当我们在会议中尝试这样做时，可能需要一整天 - 不是开玩笑 - 才能为积压的所有项目列出所有细节。

是的，散列所有细节可能需要很多时间，而这在大多数情况下是不必要的。这是在获取不到信息和获取太多信息之间取得平衡的问题。填充一个 wiki 页面（屏幕大小）通常就足够了。获取此信息可能需要 10 分钟到 2 小时。

如果这需要更多时间，这可能是因为故事相当大和/或不确定，您可能需要考虑如何拆分它。

希望这有帮助。

于 2013-02-23T14:10:44.820 回答