The short answer is an emphatic NO! Scrum does not blur or depreciate the skills required for specialization. Scrum does not promote generalization.
The long answer is that in Scrum, the most important thing is to get the work "Done". The team, as a team (as opposed to a collection of individual "stars") collaborate, as needed, in order to get the job done. Whatever it takes - however they want (Scrum is about self managing, self motivating teams, right?).
What this means is that a scrum team may be composed of several specialists, who primarily do what they specialized in (DBA, Graphic Design, even technical writers). The team, as a whole, should have all of the skills required to fulfill the requirements. This is not the same as saying that each team member has to have all of the skills aforementioned.
That being said, it is often desired - often by the members themselves - that members other than the specialists be at least adequate in skills different from their specialty. Another poster already mentioned Scott Ambler's "General Specialist". This helps the team when there's too much work of one kind, when the specialist is absent, and it helps the member when he really would like to gain experience outside his specialty.
Given that the team is self organizing, if for some reason a specialist finds himself in the middle of the sprint, without any work to do in his specialty, the best way to deal with it, is to simply ask the specialist what he wants to do. Let the team decide. The specialist can decide to help in his other areas of adequacy, do a POC for the next sprint, "shore-up" the defenses by fixing some long forgotten technical debt, or shine the shoes of the members who are working.
Yup. I don't know if this is the long answer. But it definitely was a long answer. :-)
The point of Scrum is for the developers to self-organize. We use scrum where I am, and jobs get passively sorted by a person's focus. We don't do it on purpose with a chart and list, it just happens. We all know who's best at what, or what their main/secondary focuses are. If the 'main' person needs help, they get the person/people with a secondary focus in it to help. We do get plenty of tasks not necessarily in line with whatever our particular focus is, but you always know who to ask for help then.
For your example - I don't know that if you say had 3 server guys and 5 gui guys, that you'd expect to get all the work done in that sprint (if the server guys + some help from the others wasn't enough). The way the sprint is supposed to work is that from a prioritized list, the developers pick what they think they can get done in that 30-day timeframe. If that meant the GUI guys needed 2 days of server-side training in order to help, that's what it'd mean. Unless there were concurrent things also high up the list that they could do instead. The sprint tasks are not supposed to be dictated by management as a psuedo-deadline.
If you have a Safari account, there's an interesting mostly case-study book by one of the guy/s who invented scrum.
I've been working as a ScrumMaster for about 18 months and have worked with two different teams. I initially expected to experience the potential issues you raise but this has not been the case. What I generally observe is that the team evolves into a mixture of specialists and generalists as people find the appropriate role for themselves - one that they can enjoy and be successful at. This is self-organisation at work. I have never had a case where our specialists were sitting idle.
If this did occur, I would expect it to be raised as an issue in Sprint Retrospective and the team would discuss how to improve the situation. The most obvious (and brutal) conclusion would be to change the team composition.
I am not sure why skill set will get blurred. There is a fair amount of confusion in the agile world. Scrum is a project management process and not a software development process and should not be seen as one. The engineers have to follow their own methodologies like TDD or extreme programming to add their own part to being agile.
Nothing goes away in scrum.
PM's still document as they go Architects still architect their components. The only thing is they just delay some major decisions to more responsible point in time. Developers should still follow best practices such as SOLID principles to enable for refactoring in a consistent manner as features change.
If you find for any reason ('sudden change of technology' or not) that the amount of work required for a system over a sprint is greater than the amount available then there's a problem with your scheduling.
One fix is that, as you suggest, you take programmers from other areas and throw them onto the mix. How well this works depends on the skills of that person and how different the problem domain is, but treating programmers as generic units that can be farmed out as needed is generally not a successful strategy for developing software.
The best thing about Scrum is exactly the fact that skills do get a bit blurred! The point is to avoid silos at all costs by spreading specialist knowledge across the team and letting people work a bit outside their comfort zone.
Obviously this is not for everybody. Some developers are happy in their own narrow specialist field and such people are more of a hindrance in a Scrum process than an asset, whereas well-rounded and multi-talented people who are determined to get the job done, usually adapt very very well to it and are far more productive.
One of the key benefits of Scrum is to get the whole team actually involved and invested into the project instead of tackling their own special tasks and then riding off to the horizon. I'd claim that for most people, this is a far more rewarding way of working than the conveyor belt -approach of waterfall processes.
So I'd advise to boldly embrace the mixing of skills and having people come together to take down nasty problems instead of relying on specialist silos. The result of teams consisting of motivated people can be surprising.
Sounds like this would lead to more well-rounded developers, and also allow those who are experts in certain areas to continue to contribute their expertise.
I haven't used Scrum much myself (yet), but from your description, these types of teams would lead to a team/organization that is also more well-rounded as a whole - and shouldn't that be the goal of any team?
Handling sudden changes is part of Agile and this may mean that some people have to go off and learn new skills. Course this is more within the general Agile philosophy than anything Scrum-specific. There may be some extreme cases where the customer or business decides to change the world by bringing in something new and thus has to handle the subsequent pain of those people ramping up but if this is what they want and the developers are overruled, then there are only a couple of choices: (Take your lumps and try to handle the major changes) or (quit and get out of there).
While there can be some cases where someone that has specialized in something may be able to do things faster, this doesn't necessarily mean much if that is just one person on the team that is an expert and there is enough work in that area for 10 people for the whole sprint. Should those not an expert simply not do that work and let that one person attempt to get through as much as he or she can? I don't think so but there should be something to be said for those that aren't the best at something still trying to get done what they can get done.
发布评论
评论（9）
简短的回答是明确的不！ Scrum 不会模糊或贬低专业化所需的技能。 Scrum 不提倡泛化。
长的答案是，在 Scrum 中，最重要的是“完成”工作。 团队作为一个团队（而不是单个“明星”的集合）根据需要进行协作，以完成工作。 无论需要什么——无论他们想要什么（Scrum 是关于自我管理、自我激励的团队，对吗？）。
这意味着 Scrum 团队可能由多名专家组成，他们主要从事自己擅长的工作（DBA、图形设计，甚至技术作家）。 团队作为一个整体，应该具备满足要求所需的所有技能。 这并不意味着每个团队成员都必须具备上述所有技能。
话虽这么说，但通常是成员自己希望除专家之外的成员至少足够拥有与其专业不同的技能。 另一张海报已经提到了斯科特·安布勒的“全科专家”。 当一种工作太多、专家缺席时，这对团队有帮助；当成员真正想获得专业之外的经验时，这对团队有帮助。
考虑到团队是自组织的，如果由于某种原因，某个专家发现自己处于冲刺的中间，而在他的专业领域没有任何工作可做，那么最好的处理方法就是简单地询问专家他想要做什么做。 让团队决定吧。 专家可以决定在他擅长的其他领域提供帮助，为下一个冲刺进行 POC，通过修复一些长期被遗忘的技术债务来“加强”防御，或者为成员擦鞋谁在工作。
是的。 我不知道这是否是长答案。 但这绝对是一个很长的答案。
:-)
The short answer is an emphatic NO! Scrum does not blur or depreciate the skills required for specialization. Scrum does not promote generalization.
The long answer is that in Scrum, the most important thing is to get the work "Done". The team, as a team (as opposed to a collection of individual "stars") collaborate, as needed, in order to get the job done. Whatever it takes - however they want (Scrum is about self managing, self motivating teams, right?).
What this means is that a scrum team may be composed of several specialists, who primarily do what they specialized in (DBA, Graphic Design, even technical writers). The team, as a whole, should have all of the skills required to fulfill the requirements. This is not the same as saying that each team member has to have all of the skills aforementioned.
That being said, it is often desired - often by the members themselves - that members other than the specialists be at least adequate in skills different from their specialty. Another poster already mentioned Scott Ambler's "General Specialist". This helps the team when there's too much work of one kind, when the specialist is absent, and it helps the member when he really would like to gain experience outside his specialty.
Given that the team is self organizing, if for some reason a specialist finds himself in the middle of the sprint, without any work to do in his specialty, the best way to deal with it, is to simply ask the specialist what he wants to do. Let the team decide. The specialist can decide to help in his other areas of adequacy, do a POC for the next sprint, "shore-up" the defenses by fixing some long forgotten technical debt, or shine the shoes of the members who are working.
Yup. I don't know if this is the long answer. But it definitely was a long answer.
:-)
Scrum 的重点是让开发人员进行自组织。 我们在我所在的地方使用 Scrum，工作会根据一个人的关注点被动地排序。 我们并不是故意用图表和列表来做到这一点，它只是发生了。 我们都知道谁最擅长什么，或者他们的主要/次要焦点是什么。 如果“主要”人员需要帮助，他们就会让次要人员提供帮助。 我们确实有很多任务不一定符合我们的特定重点，但你总是知道该向谁寻求帮助。
对于你的例子 - 我不知道如果你说有 3 个服务器人员和 5 个 gui 人员，你会期望在该冲刺中完成所有工作（如果服务器人员+其他人的一些帮助不是）足够的）。 冲刺的工作方式应该是，开发人员从优先级列表中选择他们认为可以在 30 天的时间内完成的事情。 如果这意味着 GUI 人员需要 2 天的服务器端培训才能提供帮助，那就是这个意思。 除非有并发的事情也排在他们可以做的清单的前面。 冲刺任务不应该由管理层规定为伪截止日期。
如果您有 Safari 帐户，可以阅读一本有趣的、主要是案例研究的书，作者是 Scrum 的发明者之一。
The point of Scrum is for the developers to self-organize. We use scrum where I am, and jobs get passively sorted by a person's focus. We don't do it on purpose with a chart and list, it just happens. We all know who's best at what, or what their main/secondary focuses are. If the 'main' person needs help, they get the person/people with a secondary focus in it to help. We do get plenty of tasks not necessarily in line with whatever our particular focus is, but you always know who to ask for help then.
For your example - I don't know that if you say had 3 server guys and 5 gui guys, that you'd expect to get all the work done in that sprint (if the server guys + some help from the others wasn't enough). The way the sprint is supposed to work is that from a prioritized list, the developers pick what they think they can get done in that 30-day timeframe. If that meant the GUI guys needed 2 days of server-side training in order to help, that's what it'd mean. Unless there were concurrent things also high up the list that they could do instead. The sprint tasks are not supposed to be dictated by management as a psuedo-deadline.
If you have a Safari account, there's an interesting mostly case-study book by one of the guy/s who invented scrum.
我作为 ScrumMaster 工作了大约 18 个月，并与两个不同的团队合作过。 我最初预计会遇到您提出的潜在问题，但事实并非如此。 我通常观察到，随着人们找到适合自己的角色——一个他们可以享受并取得成功的角色，团队就会演变成专家和通才的混合体。 这是自组织在起作用。 我从来没有遇到过我们的专家无所事事的情况。
如果确实发生这种情况，我希望它会在 Sprint 回顾中作为一个问题提出，并且团队将讨论如何改善这种情况。 最明显（也是残酷）的结论是改变团队构成。
I've been working as a ScrumMaster for about 18 months and have worked with two different teams. I initially expected to experience the potential issues you raise but this has not been the case. What I generally observe is that the team evolves into a mixture of specialists and generalists as people find the appropriate role for themselves - one that they can enjoy and be successful at. This is self-organisation at work. I have never had a case where our specialists were sitting idle.
If this did occur, I would expect it to be raised as an issue in Sprint Retrospective and the team would discuss how to improve the situation. The most obvious (and brutal) conclusion would be to change the team composition.
我不确定为什么技能集会变得模糊。 敏捷世界中存在相当多的混乱。 Scrum 是一个项目管理过程，而不是一个软件开发过程，因此不应被视为一个过程。 工程师必须遵循自己的方法，例如 TDD 或极限编程，以将自己的部分添加到敏捷性中。
Scrum 中什么都不会消失。
总理仍在记录他们的行动
架构师仍然设计他们的组件。 唯一的问题是他们只是将一些重大决定推迟到更负责任的时间点。
开发人员仍应遵循SOLID原则等最佳实践，以便以一致的方式进行重构：特征发生变化。
I am not sure why skill set will get blurred. There is a fair amount of confusion in the agile world. Scrum is a project management process and not a software development process and should not be seen as one. The engineers have to follow their own methodologies like TDD or extreme programming to add their own part to being agile.
Nothing goes away in scrum.
PM's still document as they go
Architects still architect their components. The only thing is they just delay some major decisions to more responsible point in time.
Developers should still follow best practices such as SOLID principles to enable for refactoring in a consistent manner as features change.
我认为 Scott Ambler 在 http://www.agilemodeling.com/essays/ 中非常彻底地解决了这个问题GeneralizingSpecialists.htm...
他的泛化专家概念正是集体所有权/Scrum 团队所要求的，并且对我来说完全有意义。
但在现实生活中很难实现;-)
I think Scott Ambler addresses this issue very thoroughly in http://www.agilemodeling.com/essays/generalizingSpecialists.htm...
His concept of a Generalizing Specialist is exactly the thing Collective Ownership / Scrum Team calls for, and makes total sense to me.
Its hard to achieve in real life though ;-)
如果您发现出于任何原因（无论是否“技术突然发生变化”）系统在冲刺中所需的工作量大于可用量，那么您的调度就有问题。
一个解决办法是，正如您所建议的那样，您将来自其他领域的程序员投入其中。 这种方法的效果如何取决于该人的技能以及问题领域的不同程度，但是将程序员视为可以根据需要外包的通用单位通常不是开发软件的成功策略。
但这仍然是一个调度问题。
If you find for any reason ('sudden change of technology' or not) that the amount of work required for a system over a sprint is greater than the amount available then there's a problem with your scheduling.
One fix is that, as you suggest, you take programmers from other areas and throw them onto the mix. How well this works depends on the skills of that person and how different the problem domain is, but treating programmers as generic units that can be farmed out as needed is generally not a successful strategy for developing software.
This is still a scheduling problem though.
Scrum 最好的一点就是技能确实变得有点模糊！ 关键是要不惜一切代价在整个团队中传播专业知识并让人们在自己的舒适区之外工作，从而避免孤岛。
显然这并不适合所有人。 一些开发人员对自己狭窄的专业领域感到满意，这样的人在 Scrum 过程中更多的是一种障碍，而不是一种资产，而决心完成工作的全面发展和多才多艺的人通常能够很好地适应它并且生产力更高。
Scrum 的主要好处之一是让整个团队真正参与并投入到项目中，而不是解决他们自己的特殊任务，然后就一事无成。 我想说，对于大多数人来说，这是一种比瀑布流程的传送带方法更有价值的工作方式。
因此，我建议大胆地采用多种技能的混合，让人们齐心协力解决棘手的问题，而不是依赖专业的孤岛。 由积极进取的人组成的团队的结果可能会令人惊讶。
The best thing about Scrum is exactly the fact that skills do get a bit blurred! The point is to avoid silos at all costs by spreading specialist knowledge across the team and letting people work a bit outside their comfort zone.
Obviously this is not for everybody. Some developers are happy in their own narrow specialist field and such people are more of a hindrance in a Scrum process than an asset, whereas well-rounded and multi-talented people who are determined to get the job done, usually adapt very very well to it and are far more productive.
One of the key benefits of Scrum is to get the whole team actually involved and invested into the project instead of tackling their own special tasks and then riding off to the horizon. I'd claim that for most people, this is a far more rewarding way of working than the conveyor belt -approach of waterfall processes.
So I'd advise to boldly embrace the mixing of skills and having people come together to take down nasty problems instead of relying on specialist silos. The result of teams consisting of motivated people can be surprising.
听起来这会带来更全面的开发人员，也让那些在某些领域的专家能够继续贡献他们的专业知识。
我自己（还）还没有使用过 Scrum，但从你的描述来看，这些类型的团队将导致一个整体上更加全面的团队/组织 - 这不应该是任何团队的目标？
Sounds like this would lead to more well-rounded developers, and also allow those who are experts in certain areas to continue to contribute their expertise.
I haven't used Scrum much myself (yet), but from your description, these types of teams would lead to a team/organization that is also more well-rounded as a whole - and shouldn't that be the goal of any team?
处理突然的变化是敏捷的一部分，这可能意味着有些人必须离开并学习新技能。 当然，这更多地属于一般的敏捷哲学，而不是特定于 Scrum 的任何东西。 可能存在一些极端的情况，客户或企业决定通过引入新的东西来改变世界，因此必须处理这些人随后增加的痛苦，但如果这是他们想要的并且开发人员被否决了，那么就会有只有几个选择：（克服困难并尝试应对重大变化）或（退出并离开那里）。
虽然在某些情况下，专门从事某项工作的人可能能够更快地完成工作，但如果团队中只有一个人是专家，并且该领域有足够的工作可以完成，那么这并不一定意味着什么。整个冲刺有 10 个人。 那些不是专家的人是否应该干脆不做这项工作，而让那个人尝试尽可能多地完成这项工作？ 我不这么认为，但对于那些在某件事上不是最擅长但仍在努力完成他们能完成的事情的人来说，应该有一些话要说。
Handling sudden changes is part of Agile and this may mean that some people have to go off and learn new skills. Course this is more within the general Agile philosophy than anything Scrum-specific. There may be some extreme cases where the customer or business decides to change the world by bringing in something new and thus has to handle the subsequent pain of those people ramping up but if this is what they want and the developers are overruled, then there are only a couple of choices: (Take your lumps and try to handle the major changes) or (quit and get out of there).
While there can be some cases where someone that has specialized in something may be able to do things faster, this doesn't necessarily mean much if that is just one person on the team that is an expert and there is enough work in that area for 10 people for the whole sprint. Should those not an expert simply not do that work and let that one person attempt to get through as much as he or she can? I don't think so but there should be something to be said for those that aren't the best at something still trying to get done what they can get done.