我的组织一直在尝试引入更多“敏捷”方法。我们一直在尝试Scrum方法，大多数团队或多或少都适应了它。我喜欢它作为一个整体，但我担心该方法的一个潜在的严重影响：由于团队一直专注于功能和积压项目，并且测试人员与整个开发过程更加整合，似乎技能组合正在变得模糊，人们对个人能力的尊重程度较低。
我们的一些开发人员非常擅长服务器端技术和优化重量级数据配置。其他人已经投入了大量的职业学习GUI技术，并在应用程序中对用户和可用性有了基本的了解。技能组合都不比另一组技能好，但它们肯定是不同的。
这是Scrum流程的必然结果吗？由于团队中的每个人（据我所知）都有助于满足下一个功能/要求，积压项目或测试目标，因此基本理念似乎是“任何人都可以做到”。根据我的经验，这根本不是真的。大多数工程师（开发人员，测试人员等）都拥有他们多年来磨练的特定技能，而在我看来，Scrum方法往往会贬低他们之前所尊重的那些能力。
以下是澄清的示例：
如果服务器端数据配置发生突然的技术更改，并且sprint的待办事项列表中的每个项目都基于这一新变化，那么GUI开发人员（可能没有时间成为适应新技术）可能无法为冲刺做出贡献。至少，他们需要投入时间来加速，然后他们的代码将因为缺乏经验而受到怀疑。
我理解快速发展需要阻止“角色孤岛”，但这并不能打折一个基本现实：人们根据需要，兴趣或经历发展技能。当人们认为他们的位置是“插件能力”之一时（例如我们可以“插入”任何人来完成这项特定任务），人们似乎没有那么积极性。 Scrum如何解决这个问题？如果没有，有人在采用Scrum方法时解决了这个问题吗？
答案 0 :(得分：16)
简短的回答是强烈的 NO ！ Scrum 不模糊或贬低专业化所需的技能。 Scrum不会促进泛化。
答案很长，在Scrum中，最重要的是让工作“完成”。团队作为一个团队（而不是一群个体“明星”）根据需要进行协作，以完成工作。无论需要什么 - 无论他们想要什么（Scrum是关于自我管理，自我激励的团队，对吧？）。
这意味着scrum团队可能由几位专家组成，他们主要负责他们的专业（DBA，平面设计，甚至是技术作家）。作为一个整体，团队应具备满足要求所需的所有技能。这与说每个团队成员必须具备上述所有技能不同。
话虽如此，经常需要 - 通常由会员自己 - 除专家以外的其他成员至少足够的技能与他们的专业不同。另一张海报已经提到过Scott Ambler的“综合专家”。当专家缺席时，这可以帮助团队完成一种类型的工作，当他真正希望获得他的专业以外的经验时，它可以帮助该成员。
鉴于团队是自我组织的，如果由于某种原因，专家发现自己处于冲刺的中间，没有任何工作可以做他的专业，最好的处理方法，就是简单地询问专家是什么他想做。让团队决定。专家可以决定在充分性的其他领域提供帮助，为下一个冲刺做一个POC，通过修复一些长期被遗忘的技术债务“支持”防御，或者闪耀成员的鞋子谁正在工作。
烨。我不知道这是否是 长答案。但它肯定是一个长的答案。 ： - ）
答案 1 :(得分：12)
Scrum的观点是让开发人员自我组织。我们在我所处的位置使用scrum，并且根据一个人的关注点对作业进行被动排序。我们不是故意用图表和列表来做的，它只是发生了。我们都知道谁最擅长什么，或者他们的主要/次要重点是什么。如果“主要”人员需要帮助，他们会让那些以次要为中心的人/人来帮助他们。我们确实得到了许多不一定与我们特别关注的任务相符的任务，但是你总是知道该向谁寻求帮助。
对于你的例子 - 我不知道如果你说有3个服务器人和5个gui家伙，你希望在那个sprint中完成所有工作（如果服务器人员+其他人的帮助）还不够。 sprint的工作方式是，从优先级列表中，开发人员选择他们认为可以在30天的时间范围内完成的工作。如果这意味着GUI人员需要2天的服务器端培训才能提供帮助，这就是它的意思。除非在列表中同时存在并发事项，否则他们可以做到。冲刺任务不应该被管理层规定为伪造的截止日期。
如果你有一个Safari帐户，那么发明scrum的人就会有一本很有趣的案例研究书。
答案 2 :(得分：3)
我作为ScrumMaster工作了大约18个月，并与两个不同的团队合作。我最初期望遇到你提出的潜在问题，但事实并非如此。我通常观察到的是，当人们为自己找到合适的角色时，团队会发展成为专家和通才的混合体 - 他们可以享受并成功。这是工作中的自我组织。我从来没有遇到过我们的专家闲置的情况。
如果确实发生了这种情况，我希望将其作为Sprint Retrospective中的一个问题提出，该团队将讨论如何改善这种情况。最明显（和残酷）的结论是改变团队组成。
答案 3 :(得分：2)
我不确定为什么技能组会变得模糊。敏捷世界中存在相当多的混乱。 Scrum是一个项目管理过程，而不是一个软件开发过程，不应该被视为一个过程。工程师必须遵循他们自己的方法，如TDD或极限编程，以便为敏捷添加自己的部分。
scrum中没有任何东西消失。
PM仍然是他们去的文件 建筑师仍然在构建他们的组件。唯一的问题是他们只是将一些重大决策延迟到更负责任的时间点。 开发人员仍应遵循SOLID principles等最佳实践，以便在功能发生变化时以一致的方式进行重构。
答案 4 :(得分：2)
我认为Scott Ambler在http://www.agilemodeling.com/essays/generalizingSpecialists.htm ...
中非常彻底地解决了这个问题他的概括专家概念正是集体所有权/ Scrum团队所要求的，对我来说是完全合理的。
虽然在现实生活中难以实现; - ）
答案 5 :(得分：1)
如果您发现任何原因（“技术突然变化”），系统在sprint上所需的工作量大于可用数量，那么您的日程安排就会出现问题。
一个问题是，正如你所建议的那样，你从其他领域带走程序员并将它们抛到一起。这种工作的效果取决于该人的技能以及问题领域的差异，但将程序员视为可根据需要进行养殖的通用单位通常不是开发软件的成功策略。
但这仍然是一个调度问题。
答案 6 :(得分：1)
关于Scrum最好的事情就是技能确实有点模糊！重点是通过在团队中传播专业知识并让人们在舒适区之外工作，不惜一切代价避免孤岛。
显然这不适合所有人。一些开发人员对自己狭隘的专业领域感到高兴，这些人在Scrum流程中更多地是一个障碍而不是资产，而那些决心完成工作的全面和多才多艺的人通常非常适应它并且效率更高。
Scrum的一个主要好处是让整个团队真正参与并投入到项目中，而不是解决他们自己的特殊任务，然后骑行到地平线。我声称，对于大多数人来说，这是一种比传送带更有价值的工作方式 - 瀑布流程的方法。
所以我建议大胆地接受技能的混合，让人们聚在一起解决讨厌的问题，而不是依靠专业的孤岛。由有动力的人组成的团队的结果可能令人惊讶。
答案 7 :(得分：0)
听起来这会导致更全面的开发人员，也允许那些在某些领域的专家继续贡献他们的专业知识。
我自己还没有使用过很多Scrum，但是根据你的描述，这些类型的团队会导致团队/组织整体上更加全面 - 而且不应该是目标任何团队？
答案 8 :(得分：0)
处理突然变化是敏捷的一部分，这可能意味着有些人不得不去学习新技能。当然，这比一般的敏捷哲学更符合Scrum特有的。可能存在一些极端情况，客户或企业决定通过引入新的东西来改变世界，因此必须处理那些人们随后的痛苦，但如果这是他们想要的并且开发人员被推翻，那么只有几个选择:(拿你的肿块并尝试处理重大变化）或（退出并离开那里）。
虽然在某些情况下某些专门从事某事的人可能能够更快地完成任务，但如果团队中只有一个人是专家并且有足够的工作，那么这并不一定意味着什么。该区域为整个冲刺的10人。如果那些不是专家的人根本不做那项工作而让那个人试图尽可能多地通过这项工作吗？我不这么认为，但对那些仍然没有做到最好的人来说，应该有一些东西可以说是他们可以完成的事情。