是否应允许开发人员参与积压计划流程？

Question

我最近采访了一家公司，该公司已开始为其开发周期引入Scrum。我向其中一位开发人员询问了他们的体验是什么，听起来他们完全脱离了规划过程。他不允许任何关于什么进入特定Sprint的输入，也没有参与任何计划或修饰活动。

基本上，在最后一个Sprint（或两个）开始时，他被交给了待办事项清单。他不得不将项目分解为各自的任务（因此他们可以在Sprint上工作），但没有参与任何计划活动;我怀疑他被允许对项目可能需要多少努力的大量投入 - 我怀疑建筑师为团队决定了这一点。

这应该如何处理Scrum？我现在的团队完全参与所有计划活动，不断添加我们对如何解决功能以及可能采取多少措施的意见。我对一家公司有点怀疑（并且紧张），该公司只是将开发人员列入待办事项清单而不要求他们提供意见。

注意：据我所知，一旦Sprint启动，该列表确实是一个优先的待办事项列表。我担心的是从一开始就没有投入到规划过程中。

Answer 1

如果那些正在从事这项工作的人不愿意提供投入，说明什么样的工作可以适应冲刺，并让业务决定什么是最重要的，应该安排适合。它无法逃脱。他们正在使用新的时髦敏捷词，但做同样的旧事。

Answer 2

  

（...）他不允许任何关于什么进入特定Sprint的输入，也没有参与任何计划或修饰活动。

显然，他们仍然在做命令和控制和微观管理（团队没有权力和自我组织），他们仍在使用基于推送的调度（他们没有启用拉调度）。

Scrum有其他特点，但上述几点足以说明他们没有做Scrum，无论他们如何命名，他们都没有真正从过时的瀑布方式转变（他们只是做了一些口红在猪身上。）

这是一个很大的暗示，他们对Scrum的内容仍然完全无能为力，他们根本没有得到它。如果他们甚至想要改变，如果没有一些检查和调整，这不会改变。如果你没有能力实现这一目标，那就逃跑吧。

Answer 3

  

这应该如何处理Scrum？

没有

Answer 4

我在一个自称敏捷的地方工作过。他们有6-8个月的释放周期。有些事情来自积压，但在“需求收集”阶段，基本上管理人员会花一两个星期与公司中的不同人员会面，并编写功能列表。每4周“迭代”的第一天，开发团队将聚集在一起，在一系列会议中分解所有内容。迭代的最后一天是部署日，在那里会有一个内部部署，开发团队之外的任何人都看不到。

在8个月的发布周期中，管理人员会在发布的最后两个月内与利益相关者可能联系一次或两次，此时会议中提出的唯一问题是在发布之前完成任务的机会很大，如果没有实施，那么这些问题就足以使整个工作变得毫无用处。

这不敏捷，这是瀑布式的一种变体，从其他方法中挑选出很少的想法和方法。在一天结束时，它仍然存在与瀑布相同的所有问题。

我从我的工作中吸取的教训是，开发方法包含了一些原因。如果你是从一种方法中挑选而没有完全理解它（并且通过完全理解，我的意思是实际上已经使用它），你很可能不会使用对整个事物来说实际上非常重要的东西。例如，在xp中，肯特贝克主张后来依靠重构作为削减前端设计的方法。然而，这实际上有效的唯一原因是他还提倡TDD和结对编程。如果你有一个全面的测试套件和额外的眼睛，整个事情，重构是相当安全的。如果你只是挑选第一部分并将这两部分保留下来，那么你基本上就是牛仔编码。

由于这个原因，我对那些推出自己的方法论的商店非常怀疑。以敏捷的名义犯下了绝对令人震惊的罪行。

Answer 5

  

这应该如何处理Scrum？

绝对不是。 Scrum努力提高透明度。通过阻止开发人员进行计划活动，他们正在做与scrum建议相反的事情。

你在这里谈到了2点： 1. Sprint计划 - 这里肯定需要Scrum团队成员。 2.积压修饰 - 这里可能需要或不需要。你必须明智地和常识地使用你的资源。我认为，一个具有强大开发人员背景的团队成员在这里可以。

Scrum中还有一种类型：

发布计划 - 有些人可能会说这里不需要开发人员。但根据Scrum指南 - “发布计划需要对发布的产品Backlog进行估算和优先排序”。井优先级可以由PO完成并由利益相关者建议，但如果由实际上将要开展工作的人完成估算将是最准确的，因此将开发人员纳入此处是一个好主意。同样，应该明智地使用资源。如果不让所有开发人员参与其中并让人们轮流估计是有意义的，那不是一个坏主意。

我建议遵循以下结构： Sprint Planning - 第1部分：从产品积压中评估Sprint积压（PO，SM和Team是猪） Sprint Planning - 第2部分：任务，估计任务时间并将其分解。 （SM，团队是猪，PO在这里是鸡，除非PO正在执行任务）

Answer 6

在sprint计划会议期间，团队需要弄清楚如何将所选产品的待办事项转变为可交付的产品功能。如果他们不属于此流程，那么他们将无法提交。

Answer 7

标题问题的答案是：开发人员（团队）必须参与规划会议。规划会议适用于开发人员（团队）。

好的方法是在每个sprint开始时举行两次计划会议：计划会议1和计划会议2.在计划会议中1产品所有者给出优先级（并且计划的大小估计 - 未在计划会议上进行大小估计）产品积压到团队和团队开始讨论大多数优先用户的故事。对于每个被误解的用户故事，团队应该能够收集：

• 详细要求（例如输入表格必须具有的字段......）
• 约束（例如功能有多快）
• 验收测试（结果验证）
• UI草图（例如UI流程应该如何）
• 验收标准（来自最终用户的验证 - 验收标准不一定是真正的测试。它可以是与“易于使用”等相关的东西。）

规划会议应该有时间边界1.您能够讨论的用户故事数量可以与您在即将到来的冲刺中完成的用户故事数量相对应。在规划会议结束时，1团队必须做出承诺 - 比如在讨论sprint中将完成多少讨论过的用户故事。 Sprint计划会议2仅适用于团队，因为团队会进一步讨论用户故事并将其分解为任务。

Answer 8

一般来说，他们当然应该。显然，开发人员喜欢的程度实际上是不可能的。然而，如果冲刺通常是“Hair On Fire”类型的事务，开发人员根本没有得到严肃的输入......那么在最低限度应该有定期安排的“熵减少”冲刺，其中所有任务都是由开发商为了清理废话。

Answer 9

至少有一些开发人员需要在那里，因此可以正确估计和流水线工作。

但并非所有开发者都需要在那里。一切都可以是更有意义的。

另一方面，开发人员需要了解业务优先级是优先事项，无论他们认为下一步应该如何。每个人都必须共同努力才能让它发挥作用。

Answer 10

我并不是很担心我的意见，而是我的洞察力。我最近参与了一个项目，在计划交给我之前我不知道该项目。当我发现这个过程没有经过深思熟虑并且数据定义不完整时，噩梦就开始了。我不得不再次完成整个过程，以获得我所需要的答案。

Answer 11

团队无需正式流程或会议即可参与规划流程。规划过程非常流畅。一开始，目标应该是尽快开始冲刺。在第一次冲刺之前花费太多时间进行规划感觉非常瀑布，浪费了每个人的时间。作为一个团队成员，我不会参与其中，除非它表明组织的功能失调。团队应该始终可以自由地发表意见（因为那是真正的计划发生时）。但是，你提到的两件事最让我担心。

首先，团队应该是唯一确定他们可以执行此冲刺的积压项目的人。他们当然会参与估算工作量。这是一个大问题。

其次，团队听起来并不像他们可以访问产品所有者（也许这里甚至没有）。即使团队到目前为止还没有参与“规划”，当然如果我在计划会议上与产品所有者交谈，或者在其他时间访问过产品所有者，我会随着时间的推移发出建议。