logo标签列表

开发人员应该被允许参与待办事项规划流程吗？

agilescrumbacklog
5
我最近参加了一家公司的面试，他们已经开始在开发周期中引入Scrum。我问其中一位开发人员他的经验如何，听起来他们完全脱离了规划过程。他没有被允许对一个给定的Sprint中的内容进行任何输入，并且没有参与任何规划或梳理活动。
基本上，在最后一个（或两个）Sprint开始时，他会收到一个待办事项清单。他需要将项目分解成各自的任务（以便于在Sprint期间处理），但并未参与任何规划活动；我怀疑他对一项任务需要投入多少努力的决定权很小--我认为架构师决定了团队的决策。
这种方式是Scrum应该处理的方式吗？我的目前团队会全力参与所有规划活动，不断地添加我们的意见，以确定如何处理特性以及需要投入多少努力。我对一个只是简单地向开发者提供待办事项清单而不征求他们意见的公司有些怀疑（和紧张）。
注：我明白一旦Sprint开始，这个清单真的只是一个优先级较高的待办事项清单。我的担心是从一开始就没有参与规划进程的投入。
2
啊！他们正在关注这个新事物，它被称为“Scrum But” http://www.fotoartglamour.com/pictures/mini-waterfall.JPG - sjt
1
他们没有在做Scrum。看起来像是经理的Scrum实施 ;) - user333306
2
那家公司不知道什麼是SCRUM。 - Ladislav Mrnka
2
它是Scrum，不是SCRUM，Scrum不是一个缩写 :) - Pascal Thivent
4
我投票关闭此问题，因为它与编程无关。 - Vadim Kotov
11个回答
14

如果从事工作的人不能提供意见，说出一次迭代可以完成多少工作，让业务决定什么是最重要的，并安排时间来完成任务，那么这样的方法是行不通并且会失败。他们可能在使用新潮的敏捷开发词汇，但实际上做着相同老套的事情。

6
+1表示同意，“他们使用了新潮的敏捷词汇，但做的仍然是老一套。” - Kevin Vermeer
9
他没有被允许对一个Sprint中的内容提出任何意见，并且也没有参与任何计划或预备工作。
显然，他们仍在执行“指挥和控制”以及“微观管理”（团队没有获得赋权和自我组织），并且仍在使用“推式调度”（他们没有启用拉式调度）。
Scrum还有其他特点，但以上几点已足以说明他们没有真正执行Scrum，无论他们如何命名，他们实际上并没有从过时的瀑布模型中转变（他们只是在猪身上抹了些口红）。
这是一个很大的提示，表明他们对Scrum的理解仍然非常肤浅，他们完全没有领会到。如果他们甚至不想改变，这种情况是不会改变的。如果你没有能力使这种情况发生改变，那么就离开吧。
7
这是处理Scrum的正确方式吗？
不是。
+1 点赞为“简洁”，这是敏捷宣言的 12 条原则之一。 - sjt
更重要的是，这个问题大多只是一种抱怨。在这样的问题中，很少有什么可以“回答”的。 - S.Lott
1
@S，抱歉如果这听起来像是一场怒斥，那并不是我的本意。我还是非常新手 Scrum，不知道在我接受的极为有限的培训中是否有遗漏。 - bedwyr
@bedwyr：并不是说你的问题“听起来像”是一场怒斥。实际上，你的问题是：“你同意我的观点吗？”还能是什么呢？我根据这个问题推断出这是一场怒斥。你可以尽情道歉，但你的问题仍然相当琐碎。 - S.Lott
3
我曾在一家自称敏捷的公司工作过。他们有6-8个月的发布周期。一些东西来自待办事项清单，但在“需求收集”阶段，基本上经理们会花一两个星期与公司内各种人见面，并编写一个功能列表。每个4周的“迭代”第一天，开发团队会聚在一起，在一系列会议中分解所有内容。迭代的最后一天是部署日，这时会有一个临时部署，除了开发团队外，没有人能看到。

在8个月的发布周期中，经理们可能在发布的最后两个月里与利益相关者联系一两次，此时提出的唯一问题是，如果不实施这些问题，整个努力就毫无意义。

这不是敏捷，而是瀑布流的变体，从其他方法论中选择了一些不良的想法和方法。归根结底，它仍然具有瀑布流的所有问题。

我从我的雇佣中得出的教训是，开发方法包括某些原因。如果你从一个方法论中挑选，而没有完全理解它（通过完全理解，我指的是实际使用它），那么你很可能不会使用实际上对整个过程至关重要的东西。例如，在XP中，Kent Beck提倡依靠重构来减少前期设计。然而，这实际上起作用的唯一原因是他还提倡TDD和配对编程。如果你有全面的测试套件和额外的眼睛在整个过程中，重构是相当安全的。如果你只挑选第一部分并留下这两个部分，你本质上就是牛仔编码。

出于这个原因，我对自己制定方法论的商店非常怀疑。以敏捷为名的罪行数量绝对惊人。

3
这样处理Scrum是正确的吗？
绝对不是。Scrum力求增加透明度。通过阻止开发人员进行计划活动，他们正在做与Scrum建议相反的事情。
你在这里谈到了两点： 1.冲刺计划-Scrum团队成员在这里肯定是必需的。 2.任务清单修整-可能需要，也可能不需要。您必须明智地使用资源并具有常识。我认为一个拥有强大开发背景的团队成员在这里就可以了。
Scrum中还有一种类型：
发布计划-有些人可能会说在这里不需要开发人员。但根据Scrum指南，“发布计划需要估算和优先考虑发布的产品代办事项”。好的优先考虑可以由PO完成，并由利益相关者提出建议，但如果实际上将要完成工作的人来完成估算，则最准确。因此，在这里涉及开发人员是一个好主意。同样，应明智地使用资源。如果没有涉及所有开发人员并且让人轮流评估有意义，那么这不是一个坏主意。
我建议按照以下结构进行操作： Sprint计划-第1部分：估算并从产品待办事项中拉回冲刺（PO，SM和Team在这里是“猪”） Sprint计划-第2部分：任务分解，估算任务小时数并将它们细分。（SM和Team在这里是“猪”，除非PO也接受任务）
2

在冲刺计划会议期间，团队需要想出如何将选定的产品待办事项转化为可交付的产品功能。如果他们没有参与这个过程，那么他们就无法承诺。

2

针对您的标题问题，答案是：开发人员（团队）必须参加计划会议。计划会议是为开发人员（团队）准备的。

良好的做法是在每个迭代开始时进行两次计划会议：计划会议1和计划会议2。在计划会议1中，产品负责人向团队提供优先级（并且大小估计-大小估计不是在计划会议上完成的）的产品待办事项清单，团队开始讨论最优先的用户故事。对于每个讨论的用户故事，团队应该能够收集到：

  • 详细要求（例如输入表单应具备哪些字段...）
  • 限制条件（例如功能的速度要快多少）
  • 验收测试（结果验证）
  • UI草图（例如UI流程应该是什么样子的）
  • 验收标准（最终用户的验证 - 验收标准不一定是真正的测试。它可以与“易于使用”等相关）

计划会议1应有时间限制。您讨论的用户故事数量应对应于您在即将到来的迭代中能够完成的用户故事数量。在计划会议1结束时，团队必须做出承诺 - 告诉您在即将到来的迭代中会完成多少讨论过的用户故事。迭代计划会议2仅供团队使用，因为团队进一步讨论用户故事并将其拆分为任务。

1

通常情况下，当然他们应该这样做。显然，开发人员想要的程度从现实角度来看是不可能的。然而，如果Sprint通常是“火灾”类型的事务，开发人员根本没有得到任何严肃的输入...那么至少应该定期安排“熵减”Sprint，所有任务都由开发人员专门选择，以清理垃圾。

0

至少需要一些开发人员参与，以便工作能够得到适当的估计和流程管理。

但并非所有开发人员都需要在场。如果有更好的安排，所有开发人员可以参与其中。

另一方面，开发人员需要理解业务优先事项是最重要的，无论他们认为下一个应该是什么。每个人都必须共同努力使其成功。

关于你的比喻，我敢打赌，在（插入汽车制造商的名称）的生产线上没有一个工人会在安排建造发动机所需时间时参与其中 :) 然而，这并不改变你第二段的正确性。 - KevinDTimm
@kevindtimm 是的，我猜这个类比并不是很好。 - hvgotcodes
在丰田公司，应该有生产线工人参与此事。 - Stephan Eggermont
我相信这一点。就我个人而言，我讨厌这种类型的会议，但它们绝对是必要的恶。上周五我花了两个小时参加了一个会议，为团队上的所有开发人员重新安排了任务... - hvgotcodes
0

我不太担心我的输入，但是我很担心我的洞察力。最近我参与了一个项目，在计划书交给我之前我对这个项目一无所知。噩梦开始于当我发现这个过程没有完全思考清楚，数据定义也不完整。最终我不得不重新经历整个过程才能得到我需要的答案。

哦，你不必知道计划的内容就能知道那个 :) - Stephan Eggermont
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接