Scrum 过程最终是否会剥夺团队成员各自的技能？ [关闭]答案

【问题标题】：Does the Scrum process ultimately divest team members from their respective skills? [closed]Scrum 过程最终是否会剥夺团队成员各自的技能？ [关闭]
【发布时间】：2009-04-10 17:45:30
【问题描述】：

我的组织一直在尝试引入更多“敏捷”方法。我们已经尝试了一段时间的 Scrum 方法，并且团队中的大多数人或多或少地适应了它。我喜欢它作为一个整体，但我担心该方法的一个潜在的严重影响：由于团队始终专注于功能和待办事项项目，并且测试人员与整个开发过程更加集成，似乎技能组合正在成为模糊，人们对个人能力的尊重越来越少。

我们的一些开发人员在服务器端技术和重量级数据配置的优化方面表现出色。其他人则投入了大量的职业来学习 GUI 技术，并对用户和应用程序的可用性有了基本的了解。两种技能都不比另一种好，但它们肯定是不同的。

这是 Scrum 过程的必然结果吗？由于团队中的每个人（据我所知）都为满足手头的下一个功能/要求、待办事项或测试目标做出了贡献，因此基本理念似乎是“任何人都可以做到”。根据我的经验，这根本不是真的。大多数工程师（开发人员、测试人员等）都有他们多年来磨练出来的特定技能，而在我看来，Scrum 方法往往会贬低他们以前受到尊重的那些能力。

这是一个澄清的例子：

如果服务器端数据配置发生技术突然变化，并且冲刺的待办事项列表中的每一项都基于这种新变化，那么 GUI 开发人员（他们可能还没有时间成为适应新技术）可能无法为冲刺做出贡献。至少，他们需要投入时间来提升，然后他们的代码会因为缺乏经验而受到怀疑。

我了解快速发展的必要性以阻止“角色孤岛”，但这并没有贬低一个基本现实：人们根据需要、他们的兴趣或他们的经验发展技能。当人们认为自己的位置是“插入能力”之一时（例如，我们可以“插入”任何人来完成这项特定任务），他们似乎就没有那么积极了。 Scrum 如何解决这个问题？如果没有，是否有人在采用 Scrum 方法时解决了这个问题？

【问题讨论】：

+1 进行非常有见地的分析。我希望我的第一个 scrum master 能够理解开发人员不仅仅是开发人员，而是特定领域的专家，这不是一件坏事，而是一件好事。
我认为有些人可能会认为这是一件坏事，至少在您只有一两个人是某件事的专家并且如果这些人离开公司就会搞砸的情况下.
我不认为任何一种关于专业化的观点（好的或坏的）是有效的或无效的，但只是你可以拥有不同的观点——它和其他一切一样都是一种权衡。尽管在敏捷世界中，有些人可能会说拥有一个更全面的团队会使整个组织更加敏捷。

标签： scrum

【解决方案1】：

简短的回答是强调NO！ Scrum 不会模糊或贬低专业化所需的技能。 Scrum 不提倡泛化。

答案很长，在 Scrum 中，最重要的是让工作“完成”。团队作为一个团队（而不是单个“明星”的集合）根据需要进行协作，以完成工作。不惜一切代价——不管他们想要什么（Scrum 是关于自我管理、自我激励的团队，对吧？）。

这意味着一个 Scrum 团队可能由几位专家组成，他们主要从事他们擅长的工作（DBA、平面设计，甚至是技术作家）。作为一个整体，团队应该具备满足要求所需的所有技能。这并不是说每个团队成员都必须具备上述所有技能。

话虽如此，但通常是成员自己通常希望除专家之外的成员至少足够掌握不同于他们专业的技能。另一张海报已经提到了 Scott Ambler 的“普通专家”。当某类工作过多、专家缺席时，这对团队有帮助，当成员真正想获得专业以外的经验时，这对团队有帮助。

鉴于团队是自组织的，如果由于某种原因，专家发现自己处于 sprint 的中间，在他的专业领域没有任何工作可做，最好的处理方法就是简单地询问专家什么他想做。让团队决定。专家可以决定在他充分性的其他领域提供帮助，为下一个 sprint 做 POC，通过修复一些长期被遗忘的技术债务来“加强”防御，或者擦亮成员的鞋子谁在工作。

是的。我不知道这是否是长答案。但这绝对是一个长答案。 :-)

【讨论】：

我希望我能多次投票赞成。自组织，在 sprint 中选择你自己的任务：人们会做他们感兴趣的事情，直到没有更多的那种工作……但工作会扩大以填补时间。理想情况下，人们会挑战自己并完成自己舒适区之外的任务，但这不能被强迫。当然，新员工或新成员可能总是在他们的舒适区之外工作。
通常很难让某人在他的舒适区之外挑战自己。我的团队中有一个程序员，他“不做 GUI”。不过，我正在努力……
如果您是专家，并且对于给定的 sprint，您无事可做，但 SCRUM 大师一直在问您为什么不工作，会发生什么？跨度>
专家并不一定意味着“无法在您的专业领域之外工作”。事实上 - 它不应该。如果SM问你这个问题，回答他。告诉他真相。一个好的 SM 会引导你尝试扩展自己。也许您可以在您的专业之外对团队及其目标有所帮助？也许您可以与某人配对完成一项专注于您没有但想拥有的技能的任务？也许您足够有资格从事不属于您专业的任务？您能想到专家可以做的其他有价值的事情吗？
#comfortzone：SM 的工作是发现机会并挑战团队/个人走出舒适区。

【解决方案2】：

Scrum 的重点是让开发人员自组织。我们在我所在的地方使用 scrum，并且工作会根据一个人的关注点被动排序。我们不是故意用图表和列表来做的，它只是发生了。我们都知道谁最擅长什么，或者他们的主要/次要重点是什么。如果“主要”人需要帮助，他们就会让具有次要关注点的人/人提供帮助。我们确实有很多任务不一定符合我们的特定重点，但您总是知道该向谁寻求帮助。

对于您的示例 - 我不知道如果您说有 3 个服务器人员和 5 个 gui 人员，您是否希望在该 sprint 中完成所有工作（如果服务器人员 + 其他人的帮助还不够）。 sprint 的工作方式是，从优先列表中，开发人员选择他们认为可以在 30 天的时间内完成的工作。如果这意味着 GUI 人员需要 2 天的服务器端培训才能提供帮助，那就是它的意思。除非他们可以做的事情也排在首位。冲刺任务不应该由管理层规定为伪截止日期。

如果您有 Safari 帐户，那么其中一位发明 Scrum 的人写了一本有趣的案例研究书。

【讨论】：

感谢您的好评！这里有一个问题：如果所需的培训更多怎么办？如果服务器开发人员需要学习一门新语言（例如 Silverlight 或 Flex），因为 GUI 不再使用团队的原始语言编码，该怎么办？
所需的培训应显示在 sprint 待办事项列表中（团队拥有它）并在发现为有效任务后立即进行估计。如果这意味着 sprint 不能因此而成功 - 你知道你有一个问题要处理。 Scrum 不能解决问题。它只是有助于使他们成为焦点。您最终可能会得到各种解决方案。外包一些任务，缩小冲刺范围，...

【解决方案3】：

我作为 ScrumMaster 工作了大约 18 个月，曾与两个不同的团队合作过。我最初预计会遇到您提出的潜在问题，但事实并非如此。我通常观察到的是，当人们找到适合自己的角色时，团队会演变成专家和通才的混合体——他们可以享受并获得成功。这是工作中的自组织。我从来没有遇到过我们的专家无所事事的案例。

如果确实发生了这种情况，我希望它会在 Sprint Retrospective 中作为一个问题提出，并且团队将讨论如何改善这种情况。最明显（也是最残酷）的结论是改变团队组成。

【讨论】：

【解决方案4】：

我不确定为什么技能组合会变得模糊。在敏捷世界中存在相当多的混乱。 Scrum 是一个项目管理过程，而不是软件开发过程，不应被视为一个过程。工程师必须遵循他们自己的方法，如 TDD 或极限编程，才能为敏捷添加自己的部分。

scrum 中什么都不会消失。

PM 在他们去的时候仍然是文件架构师仍然在构建他们的组件。唯一的问题是他们只是将一些重大决定推迟到更负责任的时间点。开发人员仍应遵循 SOLID principles 等最佳实践，以便在功能更改时以一致的方式进行重构。

【讨论】：

【解决方案5】：

我认为 Scott Ambler 在 http://www.agilemodeling.com/essays/generalizingSpecialists.htm... 中非常彻底地解决了这个问题...

他的泛化专家概念正是集体所有权/Scrum 团队所要求的，对我来说完全有意义。

但在现实生活中很难实现；-)

【讨论】：

【解决方案6】：

如果您出于任何原因（“技术突然变化”与否）发现系统在冲刺期间所需的工作量大于可用量，则说明您的日程安排存在问题。

一个解决方法是，正如您所建议的，您从其他领域招募程序员并将他们混在一起。其效果如何取决于此人的技能以及问题领域的不同程度，但将程序员视为可以根据需要外包出去的通用单元通常不是开发软件的成功策略。

但这仍然是一个调度问题。

【讨论】：

【解决方案7】：

Scrum 最棒的地方就是技能确实有点模糊！关键是通过在团队中传播专业知识并让人们在他们的舒适区之外工作，不惜一切代价避免孤岛。

显然，这并不适合所有人。一些开发人员在他们自己狭窄的专业领域中很开心，这些人在 Scrum 过程中更多的是障碍而不是资产，而决心完成工作的全面和多才多艺的人通常非常适应并且效率更高。

Scrum 的主要好处之一是让整个团队真正参与并投入到项目中，而不是解决他们自己的特殊任务然后骑马奔向地平线。我声称对于大多数人来说，这是一种比传送带式瀑布流程更有价值的工作方式。

因此，我建议大胆地采用混合技能，让人们齐心协力解决棘手的问题，而不是依赖专家孤岛。由积极进取的人组成的团队的结果可能令人惊讶。

【讨论】：

【解决方案8】：

听起来这样会培养出更全面的开发人员，同时也让某些领域的专家能够继续贡献他们的专业知识。

我自己（目前）还没有大量使用 Scrum，但根据您的描述，这些类型的团队会导致团队/组织在整体上更加全面——这不应该是目标任何团队？

【讨论】：

【解决方案9】：

处理突然的变化是敏捷的一部分，这可能意味着有些人必须离开并学习新技能。当然，这更多地属于一般的敏捷哲学，而不是任何特定于 Scrum 的东西。在某些极端情况下，客户或企业决定通过引入新事物来改变世界，因此必须处理这些人的后续痛苦，但如果这是他们想要的并且开发人员被否决，那么就有只有两个选择：（忍气吞声并尝试处理重大变化）或（退出并离开那里）。

虽然在某些情况下，专门从事某事的人可能能够更快地完成工作，但如果团队中只有一个专家并且有足够的工作量，这并不一定意味着什么整个冲刺的那个区域可以容纳 10 人。那些不是专家的人是否应该干脆不做这项工作，让那个人尽可能多地尝试通过？我不这么认为，但对于那些在某事上仍不擅长但仍在努力完成他们可以完成的事情的人来说，应该有话要说。

【讨论】：