我的组织一直在尝试引入更多“敏捷”方法。我们已经尝试了一段时间的 Scrum 方法，并且团队中的大多数人或多或少地适应了它。我喜欢它作为一个整体，但我担心该方法的一个潜在的严重影响：由于团队始终专注于功能和积压项目，并且测试人员与整个开发过程更加集成，似乎技能组合正在成为模糊，人们对个人能力的尊重越来越少。
我们的一些开发人员在服务器端技术和重量级数据供应的优化方面表现出色。其他人则投入了大量的职业来学习 GUI 技术，并对用户和应用程序的可用性有了基本的了解。两种技能都不比另一种好，但它们肯定是不同的。
这是 Scrum 过程的必然结果吗？由于团队中的每个人（据我所知）都为满足手头的下一个功能/要求、待办事项或测试目标做出了贡献，因此基本理念似乎是“任何人都可以做到”。根据我的经验，这根本不是真的。大多数工程师（开发人员、测试人员等）都有他们多年来磨练出来的特定技能，而在我看来，Scrum 方法往往会贬低他们以前受到尊重的那些能力。
这是一个澄清的例子：
如果服务器端数据配置发生技术突然变化，并且冲刺的待办事项列表中的每一项都基于这种新变化，那么 GUI 开发人员（他们可能还没有时间适应新技术）可能无法为冲刺做出贡献。至少，他们需要投入时间来提升，然后他们的代码会因为缺乏经验而受到怀疑。
我理解快速发展的必要性以阻止“角色孤岛”，但这并没有贬低一个基本现实：人们根据需要、他们的兴趣或他们的经验发展技能。当人们认为他们的位置是一种“插入能力”（例如，我们可以“插入”任何人来完成这项特定任务）时，他们似乎就没有那么积极了。Scrum 如何解决这个问题？如果没有，是否有人在采用 Scrum 方法时解决了这个问题？