我最近采访了一家公司，该公司已经开始在他们的开发周期中引入 Scrum。我问其中一位开发人员他们的经验如何，听起来他们完全脱离了规划过程。他不被允许对给定 Sprint 的内容提供任何意见，也没有参与任何计划或修饰活动。
基本上，在最后一个（或两个）Sprint 开始时，他收到了一份待办事项清单。他必须将项目分解为各自的任务（以便可以在 Sprint 中处理它们），但没有参与任何计划活动；我怀疑他是否被允许对一个项目可能需要多少努力进行大量投入——我怀疑建筑师为团队决定了这一点。
这是应该如何处理 Scrum 的吗？我目前的团队完全参与了所有的规划活动，不断地添加我们关于如何处理功能以及它们可能需要付出多少努力的意见。对于一家简单地向开发人员提供待办事项清单而不征求他们意见的公司，我有点怀疑（和紧张）。
注意：我知道一旦 Sprint 开始，该列表实际上就是一个优先的待办事项列表。我担心的是没有从一开始就参与到规划过程中。
如果那些从事这项工作的人没有提供意见，说明什么工作量可以适合一个 sprint，并让业务决定什么最重要，应该安排什么来适应。它不会工作逃跑。他们使用新的时髦的敏捷词，但做同样的旧事情。
(...) 他不被允许对给定 Sprint 的内容提供任何意见，也没有参与任何计划或修饰活动。
显然，他们仍然在做指挥和控制和微观管理（团队没有被授权和自组织），他们仍然在使用基于推送的调度（他们没有启用拉式调度）。
Scrum 还有其他特点，但以上几点足以说他们没有在做 Scrum，不管他们如何命名，他们并没有真正改变过时的瀑布式方法（他们只是在猪身上涂了一些口红）。
这是一个很大的暗示，他们仍然对 Scrum 是什么一无所知，他们根本不明白。如果他们甚至想改变的话，如果没有一些检查和调整，这将不会改变。如果你没有能力做到这一点，那就逃跑吧。
这是应该如何处理 Scrum 的吗？
不。
我在一个自称敏捷的地方工作。他们有 6-8 个月的发布周期。有些东西来自积压，但在“需求收集”阶段，基本上经理们会花一两周时间与公司的各种人会面，并写一份功能清单。每 4 周“迭代”的第一天，开发团队都会聚在一起，在一系列会议中分解所有内容。迭代的最后一天是部署日，在那里会有一个开发团队以外的人从未见过的临时部署。
在 8 个月的发布周期中，管理人员可能会在发布的最后两个月与利益相关者接触一次或两次，此时在那些会议中提出的唯一有可能在发布前完成的问题是如果不实施，这些问题已经严重到使整个努力毫无用处。
这不是敏捷的，这是瀑布的变体，从其他方法论中挑选的想法和方法论选择不佳。归根结底，它仍然存在与瀑布相同的问题。
我从我的工作中得到的教训是，开发方法包含一些东西是有原因的。如果您在没有完全理解的情况下从方法中挑选（并且完全理解，我的意思是实际使用过它），那么您很有可能不会使用对整个事物实际上至关重要的东西。例如，在 xp 中，kent beck 提倡依靠稍后的重构来减少前期设计。然而，这确实有效的唯一原因是他还提倡 TDD 和结对编程。如果你有一个全面的测试套件，并且对整个事情有额外的观察力，那么重构是相当安全的。如果您只是挑选第一部分而将这两个部分排除在外，那么您本质上就是牛仔编码。
我对出于这个原因推出自己的方法论的商店非常怀疑。以敏捷的名义犯下的罪行数量绝对令人震惊。
这是应该如何处理 Scrum 的吗？
当然不。Scrum 致力于提高透明度。通过阻止开发人员计划活动，他们正在做与 Scrum 建议相反的事情。
您在这里谈到了 2 点： 1. Sprint 计划 - Scrum 团队成员应该是绝对需要的。2. 待办事项梳理 - 这里可能需要也可能不需要。你必须明智地使用你的资源，并且有常识。我认为一名具有强大开发人员背景的团队成员在这里就可以了。
Scrum 中还有一种类型：
发布计划——有些人可能会说这里不需要开发人员。但根据 Scrum 指南 - “发布计划需要估计和优先考虑发布的产品待办事项”。优先级可以由 PO 完成并由利益相关者提出建议，但如果由实际要做这项工作的人完成，估计将是最准确的，因此让开发人员参与进来是个好主意。再次，应该明智地使用资源。如果不让所有开发人员参与并让人们轮流进行估算是有意义的，那不是一个坏主意。
我建议遵循以下结构：Sprint 计划 - 第 1 部分：从产品待办列表中估算和提取 Sprint 中的待办事项（PO、SM 和团队在这里是猪） Sprint 计划 - 第 2 部分：任务分配、估计任务时间并将其分解。（SM和Team都是猪，PO是鸡，除非PO也接任务）
在 sprint 计划会议期间，由团队决定如何将选定的产品 backlog 转变为可交付的产品功能。如果他们不是这个过程的一部分，那么他们将无法提交。
您的标题问题的答案是：开发人员（团队）必须参加计划会议。计划会议是针对开发人员（团队）的。
好的方法是在每个 sprint 开始时召开两次计划会议：计划会议 1 和计划会议 2。在计划会议 1 中，产品负责人将优先级（和大小估计 - 大小估计不在计划会议上进行）产品积压工作提供给团队和团队开始讨论最优先的用户故事。对于每个讨论过的用户故事，团队应该能够收集：
计划会议 1 应该有时间限制。您能够讨论的用户故事的数量可以对应于您将能够在即将到来的 sprint 中完成的用户故事的数量。在计划会议结束时，1 个团队必须做出承诺——说明在即将到来的 sprint 中将完成多少个讨论过的用户故事。Sprint 计划会议 2 仅适用于团队，因为团队会进一步讨论用户故事并将其分解为任务。
一般来说，他们当然应该这样做。显然，它永远不可能达到开发人员想要的程度。但是，如果冲刺通常是“发火”类型的事务，开发人员根本没有得到认真的投入……那么至少应该有定期安排的“熵减少”冲刺，其中所有任务都由开发人员的目的是清理垃圾。
至少需要一些开发人员在场，这样才能对工作进行正确估计和流水线化。
但并非所有开发人员都需要在那里。一切都可能存在，这更有意义。
另一方面，开发人员需要了解业务优先级是优先级，无论他们认为接下来应该发生什么。每个人都必须共同努力，才能使它发挥作用。
我不是很担心我的意见，而是我的洞察力。我最近参与了一个项目，在计划交给我之前我对这个项目一无所知，据说是完成的。当我发现这个过程没有完全考虑好并且数据定义不完整时，噩梦就开始了。我最终不得不再次经历整个过程才能得到我需要的答案。
团队可以在没有正式过程或会议的情况下参与规划过程。规划过程非常流畅。一开始，目标应该是尽快开始冲刺。在第一个 sprint 之前花太多时间在计划上，感觉非常瀑布，浪费了每个人的时间。作为一名团队成员，我会因为不参与其中而感到宽慰，除非它表明组织的功能失调。团队应该始终可以自由地持续发表想法（因为那是真正计划发生的时候）。但是，你提到的两件事是我最关心的。
首先，团队应该是唯一确定他们可以在这个 sprint 中完成多少待办事项的人。他们肯定会参与估算工作量。这是个大问题。
Second, the Team does not sound like they have access to the product owner (maybe there ins't even one here). Even if the team has not been involved in the "planning" thus far, surely if I were talking to the product owner in the planning meeting, or had access to them at other times, I would voice suggestions over time.