对于那些喜欢从头到尾独立地拥有大块代码的开发人员，我们如何使他们感到敏捷？

使用Scrum从瀑布到敏捷的过渡大约在中间。我们已经从技术/学科孤岛中的大型团队变为较小的跨职能团队。

不出所料，敏捷的改变并不适合所有人。少数开发人员很难适应敏捷的需求。我真的想让他们保持参与和挑战，并最终享受每天上班的乐趣。这些人都是聪明，快乐，有进取心的人，我个人和专业都尊重他们。

基本问题是这样的：有些开发人员的主要动机是乐于进行一些艰巨的工作，仔细考虑设计，仔细考虑潜在问题，然后逐步解决问题，而在与扩展人员的最小交互下一段的时间。他们通常会及时高质量地完成工作；他们的工作是可维护的，并且与整体架构相适应。过渡到重视交互作用和共同责任的跨职能团队，并在较短的时间间隔内交付工作功能后，团队不断发展壮大，整个团队将这一难题解决了。许多人发现这是一个积极的变化。一个喜欢承担一个问题并从头到尾独立承担责任的人会失去这样的工作机会。

人们乐于接受变革，这不是问题。当然，我们已经见过一些不喜欢变革的人，但是在我所关心的情况下，个人表现出色，真正乐于接受变革，他们努力工作，他们看到团队其余成员的表现不断变化，他们想适应。这不是某人遇到困难或阻碍主义者，或想ho积最充实的工作。他们只是没有像以前那样在工作中找到快乐。

我敢肯定，我们不可能是唯一一个没有撞到这个地方的地方。其他人如何处理呢？如果您是一个开发人员，因为自己是端到端拥有大量工作的动力，并且已经适应了另一种工作方式，那么对您有什么帮助？

我要说的是，很少有软件商店能够幸运地拥有罕见的区别，而敏捷对于方法论来说确实是毫无意义的。如果您的整个团队都是由真正优秀的软件开发人员组成，他们对业务和与公司以及彼此之间的寿命有深刻的了解，并且您的业务需求和客户需求通常总是相似的，并且很少在中间进行更改发行版，那么您很幸运可以在如此罕见的环境中工作，在这种环境中，敏捷实际上可能会受到伤害。

在混乱且不断变化的业务需求和客户需求，不断变化或变化的项目资源以及紧迫或变化的期限中，它被设计为最有效的方法。这样的环境对于典型的瀑布式开发意味着一定的厄运，因为它容易受到团队在项目中进行更改，容易受到需求变化以及极易受到日期变化的影响。

对于您的宝贵团队成员，我感到自己的工作不再快乐。他们可能是非常有才华的人，他们全神贯注于他们的工作，但最终，许多无法控制的因素仍然可以使该项目无效。进行功能开发的最佳方法是让他们失去个人态度和表达，并根据团队方法进行思考。

如果您发现这对他们不起作用，则可以为他们找到特殊用途。如果他们非常有才华和经验丰富，请查看他们是否会对架构角色感兴趣，布置高级设计，方法，尝试新技术并发展最佳实践。让这些人控制和审查设计文档。

如果这仍然不适合他们，则可能让他们在单独的分支上进行极其复杂的技术重构，大量涉及的原型和概念验证，或者有时需要完成但又不太适合他们的其他开拓性工作，分别进行工作。单个项目或发行版的范围。

他们只是没有像以前那样在工作中找到快乐。

正确。

这是您做错了一个很大的症状。

敏捷不应该给人们带来坏的新秩序。

敏捷应该允许团队以最有效的方式进行自我组织。

自组织意味着管理不会施加奇怪的规则。它不会强加时间表，也不会强加不必要的交互作用。

一些开发人员的主要动力是高兴地从事艰苦的工作，仔细思考设计，仔细考虑潜在问题，然后在很长一段时间内仅与其他人进行最少交互而逐个解决问题

他们为什么不能继续这样做？

为什么要更改它们？

请阅读《敏捷宣言》几次。

敏捷宣言说

个人与流程和工具之间的互动

并不是说强迫人们以一种不舒服，没有生产力的方式工作。

如果您要强迫人们进行过多的低价值“互动”，那么您就走得太远了。

工作软件超过全面的文档。

他们在这样做吗？然后不理他们。

通过合同谈判进行客户协作。

你已经在做这个了吗？那不要改变。

响应按照计划进行的转换。

这些人在哪里已经能够应对变化？如果是这样，那么他们已经很敏捷了。他们不需要改变。

我的公司尝试过（并且经过多年尝试仍在尝试）进行相同的过渡，到目前为止，就我个人而言，我还没有看到太大的成功。在此过渡期间，我大量学习了敏捷开发以及不同的方式/方面/关注点/技术，我非常同意的一件事是，当整个团队由资深，高素质的人员组成时，纯敏捷开发最适合（或至少所有同一级别的人）。

我的上一个版本是一个“敏捷”团队，该团队的恕我直言，太多的开发人员到处都是技术水平，我们试图让每个人都参与同一项目。那是一场灾难。我们所做的交谈/争论多于工作，最后，团队生产的是平均水平的工作（请阅读《 Peopleware或Mythical Man Month》，以了解平均水平）。忘记设计模式，忘记低耦合或将代码分解为小的类和方法。忘记尝试使任何事情变得有趣，因为a）所有团队成员都无法解释和理解（至少不是及时地），并且b）由于我们敏捷，无论我开始这个迭代如何，其他人都完全不了解将在下一次迭代中继续。亲身，

我绝对讨厌这样的事实，即我无法使用C ++模板做任何事情，也无法编写一些很酷（但有些复杂）的低级框架库，这会使我们的生活变得更加轻松。当团队中没有其他人甚至能够读取STL头文件，但我们所有人一次都应该做一件事情时，该怎么做？整个项目最终被逐个功能强加，因为敏捷似乎强调了这一点。

同时，我的公司中很少（很少）我绝对愿意与他人并肩分享我的所有代码。

但是现在您面临一个选择。A）将所有产生高质量代码的优秀，高级开发人员放到自己的团队中，并将其余的人放到一个单独的团队中。或B）尝试平衡团队，并把好团队与不太好的团队放在一起。在（A）中，问题在于您的团队之一表现不佳，不会从好家伙那里获得好的技能/习惯。在（B）中，您的好人（在纯敏捷的环境中）会感到沮丧，并将开始撰写简历。我的是最新的。

那你该怎么办？

我不知道这是否是正确的解决方案。大约一年后再问我。但是，如果您组建了一个团队而不是“纯粹的敏捷”，却清楚地确定了哪些人具有更大的影响力（设计，代码审查...），并确保该人理解这一点，并为此承担了额外的责任，该怎么办？当团队成员开始一起工作时，找出那些养成良好习惯/做法的人，并将其提升到与您的好人相同的水平。希望随着人们花一个或两个版本一起工作，他们将学习其他人的想法以及他们的工作方式，因此他们将更兼容同时使用同一代码。但是直到那件事发生之前，如果您只是将人们投入到一个项目中，那只会是沮丧（再次，只是我的看法）。

我的某些想法是基于我是如何专业从事软件的。当我是一个合作社时，我和一个曾是我的导师的人一起工作。他教了我很多东西，从道德编码到良好的设计，再到阅读成千上万行您没有编写的代码。最初，我们处于同一水平，如果我们被安排在一个敏捷团队中并告诉我们可以互相编写代码，那将是可笑的。但是随着时间的流逝（几年），我们开始非常相似地思考。我可以一眼就能理解他的代码，他多次告诉我，他绝对没有问题（对此感到惊讶），可以浏览他从未见过的代码。这花了好几年，而不是一整夜。过去几年在敏捷环境中经历了一场又一场的灾难之后，

这不是一个真正的答案，但总结了我的经验/观察。我确实想看看别人会怎么说。

什么是敏捷？

是吗：

• 您必须遵循的一组规则才能实现规则制定者的意图？

• 在您的特定优势，要求和限制范围内完成工作的最佳方法？

如果您认为敏捷是第一位的，并且您始终遵循每一个Scrum规则，并不断担心自己是否做对了，那么此链接可能会给您带来些启发。

如果您更多地考虑第二个，那么恭喜您-您“敏捷”了。任何敏捷方法论都只能暗示如何完成工作。如果您选择的敏捷方法的任何方面都不适合您，那么您有责任停止使用，更改或以其他方式敏捷关于它。重要的是您要取得成就，而不要受到人为约束的束缚-不仅仅是我们从过去的瀑布时代就知道和喜欢的约束，因为PM会麻烦您获取没有人会遇到的完整记录的图表读这本书的原因不仅在于“这就是该过程要做的事情”，还应从您正在使用的软件的限制中进行阅读。如果每天的混乱都让人感到束手无策，那就不要眨眼了！因为规则这样盲目地拥有它们，并不比旧方法更敏捷。

现在，如果您有一些家伙被关在一个只有一加仑可乐和一个比萨饼舱口的房间里完成工作，那么请利用这个事实。给他们一些系统中大部分是独立的部分并将其锁定。完成后，您应该让他们将这项工作与系统的其余部分集成在一起（或者，如果他们愿意，请其他人来完成）。

Alistair Cockburn 在他的方法中对此进行了描述。如果您拥有“ 3级从业者”，那么一种完美有效的敏捷方法如下：

“将4-6人放置在一个配有工作站和白板的房间中，并与用户接触。让他们每隔一两个月向用户交付运行中经过测试的软件，否则就别管它们了。”

当您有很多人时，您需要找到一种使他们建设性地一起工作的方法，这意味着适合所有情况的1-尺码方法可能不会非常有效。因此，您需要始终将任务划分为多个部分，以确保强调共同的目标。可以将这些人送去编写代码，但必须使他们知道自己的东西将如何成为团队其余工作的组成部分，而未能实现目标则是他们正在生产的产品的失败。一旦他们了解了这一点（即，他们不能做自己想做的事情并交付不可用的东西），那么您的工作就完成了。

可以说敏捷并不适合每个人，敏捷也不适合每个项目。同时，敏捷是一个非常宽泛的术语，而Scrum只是敏捷过程的一种实现-我可以以某种方式说这种实现可能受到最大的限制，它试图通过众所周知的步骤来建立标准化的过程。

要考虑的另一个领域是敏捷的目的是什么？开发人员的工作方式敏捷吗？也许-有些方法确实朝那个方向发展。但是敏捷本身涵盖了开发之外的领域。敏捷不仅仅是驱动整个过程，交互的工作方式，按时交付具有最重要功能的工作产品的方式，控制资源的方式，如何查看当前项目的位置，等等

有些方法不会尝试更改您的开发过程中的任何内容-Scrum不是那种方法。所有敏捷方法都强调持续改进。您将在过程中发现一些效率低下的步骤，然后尝试对其进行改进/更改-这就是敏捷方法。查看另一种流行的敏捷方法-看板。

您/您的公司已决定使用Scrum，这可能会导致某些人不喜欢它而离开的事实。您应该分别与每个开发人员打交道。您应该与每个人谈论这一点，并且应该尝试找到一些兴趣点，使他们重新享受工作。

他们可以扮演导师的角色，可以教别人，并向他们展示如何在迭代工作时将代码重构为更好的体系结构。它们可以共同构成跨项目使用的一些全局体系结构蓝图。他们还可以进行概念验证，当客户进行查询以考虑需求的可行性时，可以参与RFI（信息请求）。他们可以与技术水平较低的开发人员结成对，并共同完成复杂的任务，等等。他们的主要价值应该在于运用自己的技能，并允许其他人向他们学习。

全球范围内的Scrum和敏捷确实以某种方式压低了个人并确定了团队的优先级-团队交付应用程序，而不是个人。这个想法是基于这样一个事实，即您将永远不会拥有一个团队，每个人都有相同的技能和经验。

如果您成功过渡到Scrum，他们应该看到整个流程得到了改善，交货时间减少了，质量得到了改善，客户也更加满意。他们仍然可以相信，已开发的应用程序本身比它们要糟得多，但这就是要点-客户不想要有史以来最好的代码。客户需要能够满足其需求的最小/最便宜/最快的工作代码。如果蛮力足以做到这一点，那就去吧。这可能会给高技能的开发人员带来问题，但这并不是敏捷的失败，而是业务需求和完美主义相互抵触的地方。

如果您解决了一些主要问题并将其交给优秀的开发人员，它将对整个团队都有利。随后，每个人都可以跟上进度并在此过程中学习一些东西。只是不要以这种方式构建整个应用程序。

您无需将代码降低到最低公分母。您会使经验不足的人赶上更好的开发人员。

关于什么是“敏捷”或不是敏捷，已经有很多讨论，关于敏捷过程的很多个人感受，经验和疑虑在这里共享，但是我还没有真正看到这个问题的实际答案。最初的问题是当您的顶级开发人员看到他们以纯艺术形式编写的代码时，如何保持积极性，并将他们的汗水和血液投入其中，被其他人砍伐并“腐败”。请注意，无论是否敏捷，这都会在某个时刻发生，现在更加明显了，因为他们仍在与其他人同时处理代码，而不是在通常情况下提供支持他们只是看不到所做的更改。

我在这里看到的关键是扩大这些开发人员的责任，并帮助他们将重点转移到更大的领域。也许这意味着一个新头衔，例如软件架构师，团队负责人或高级软件工程师。然后向他们展示这是一个机会，不仅可以一次在一个项目上，而且可以在多个项目上产生更大的影响。主人翁意识仍然存在，但他们的注意力不应再集中在交付一个伟大的项目上，而是要帮助树立所有人的标准项目。帮助他们表达他们对构建伟大事物的强烈渴望，但是将重点转移到建立公司的软件工程实践以及其他开发人员上。这可能不是让他们的同事想破解代码的想法，而是让他们有机会上一个台阶，指导他们的团队成员，使他们达到更高的水平。

我将尝试说明一些其他答案尚未解决的方面，而IMO非常重要。

基本问题是这样的：有些开发人员的主要动机是乐于进行一些艰巨的工作，仔细考虑设计，仔细考虑潜在问题，然后逐步解决问题，而在与扩展人员的最小交互下一段的时间。他们通常会及时高质量地完成工作；他们的工作是可维护的，并且与整体架构相适应。

这类开发人员可能会发现很难适应敏捷的环境，他们的态度经常被视为“不愿意改变”，可能与自我或过时有关。

经常被忽略的是，为了解决复杂的问题，一个人需要处理很多信息，而这可能需要大量的分析，思考，尝试，草拟解决方案，将其丢弃，再尝试另一种解决方案。如此复杂的问题可能需要花费几个小时到几周的时间才能完成，直到您获得完整的解决方案为止。

一种方法是，开发人员接受问题说明，然后回到自己的房间，并在两三个星期后返回解决方案。在任何时候（需要时），开发人员都可以与团队中的其他成员或与利益相关者进行某种互动（询问特定问题），但是大部分工作是由分配任务的开发人员完成的。

在敏捷场景中会发生什么？经过快速分析（整理）后，团队将问题分解为小块（用户故事）。希望用户故事彼此独立，但事实并非总是如此：为了将一个复杂的问题分解为真正独立的部分，您需要了解一些通常只需要几天才能获得的知识。换句话说，如果您能够将一个复杂的问题分解成多个独立的小部分，则意味着您已经基本解决了该问题，而您仅剩下勤奋的工作了。对于需要三个星期的工作的问题，第二个星期可能就是这种情况，而不是在冲刺开始时进行几个小时的梳理之后。

因此，在计划了冲刺之后，团队将研究问题的不同部分，这些部分之间可能会相互依赖。试图集成不同的解决方案可能会产生很多通信开销，这些解决方案可能同样好，但是彼此之间是完全不同的。基本上，反复试验工作分布在所有参与的团队成员中，并具有额外的通信开销（以平方倍增加）。我认为其中一些问题在Paul Graham的这篇文章中得到了很好的说明，特别是第7点。

当然，在团队成员之间共享工作可以减少与一名团队成员离开项目有关的风险。另一方面，关于代码的知识可以通过其他方式传达，例如使用代码审查或向同事进行技术演示。在这方面，我认为并不是在所有情况下都可以使用的灵丹妙药：共享代码所有权和结对编程不是唯一的选择。

此外，“在较短间隔内交付工作功能”导致工作流程中断。如果功能块是“可以在冲刺结束时完成”的“在登录页面中添加取消按钮”这一功能块，那么可能就可以了，但是当您执行复杂任务时，您不希望出现此类中断：尝试以最快的速度开100公里的汽车，然后每5分钟停车一次，以检查您的行驶距离。这只会减慢您的速度。

当然，拥有频繁的检查点是为了使项目更可预测，但是在某些情况下，中断可能会非常令人沮丧：人们几乎无法加快速度，因为它已经是时候停止并提出一些东西了。

因此，我不认为问题中描述的态度仅与自我或对变革的抵抗有关。也可能是某些开发人员认为上述解决问题的方法更有效，因为它使他们可以更好地了解他们正在解决的问题和所编写的代码。强迫此类开发人员以其他方式工作可能会降低其生产率。

另外，我不认为让团队中的某些成员单独解决特定的难题是违反敏捷价值观的。毕竟，团队应该自我组织并使用多年来发现最有效的流程。

只是我的2美分。

Some developers are primarily motivated by the joy of taking a piece of difficult 
work, thinking through a design, thinking through potential issues, then solving
the problem piece by piece, with only minimal interaction with others, over an 
extended period of time

听起来他们是“独行侠”。在规范的Scrum中，这些人根本不适合团队（他们错过了“交互”功能）。

如果他们不是“独行侠”，那么就有希望。如果您正确执行Scrum，则它们必须是将要使用的功能设计的一部分（在Sprint计划期间）。这是他们唯一一次与他人互动的时间。您甚至可以将与该功能有关的所有故事“分配”给他们。

在Sprint期间，他们只会受到日常Scrum的“拥护” ...直到您可以证明他们（通过行动，而不是通过言语）仅15分钟的时间，并且只能确保一切正常顺利。紧贴三个问题，大多数人将停止遵守。

在我们的团队中，我们有一个专门的小组来提高性能。我们并没有看到太多，只是在冲刺开始时谈论要进行的更改，而在回顾结束时。他们有自己的“ Scrum负责人”，向Scrum of Scrum团队报告。我可以告诉你，他们很开心。

如果Joe（您的Hero开发人员）有点灵活，那么我认为没有问题：

如上所述，让团队自我组织：如果让Joe亲自咀嚼可以最好地解决某些问题，那么您会期望一个思想开放的自我组织团队能够自己得出结论。

唯一的挑战仍然存在于Scrum施加的一些约束中：

1. 定期提供功能：如果让Joe几个月来咀嚼问题，直到最后一刻都没显示，那么Joe确实不是敏捷的：他将产品所有者当作人质，不让他重新审视产品的那一部分。通过这种做法，他还有可能迟到，没有人注意到。（但是根据您的描述不太可能）。补救措施：与乔一起坐下来与PO在一起，分解用户故事并就中间交付品达成一致，最好（但不一定）与用户价值达成共识，这会太多吗？

2. 遵守产品所有者设置的优先级：如果代码段是专家所有的，那么您冒着这样的情况，即产品的发展取决于每个专家的可用性，而不是商业优先级：团队的其他成员可能正在使用不太重要的功能，而前3个功能却停滞了，因为“只有Joe可以做到”。那很糟。那时，团队应该（暂时）改变他们的习惯，并将乔的工作分配给更多的团队成员。

简而言之：如果英雄开发者Joe同意PO的观点，他将如何展示每个冲刺的进度，那么团队可以为他分配某些故事，而不必理会他。但是，如果PO对Joe的工作量过多，而对团队的工作量却不够（反之亦然），则Joe和团队必须适应，而不是PO。

应当为敏捷团队量身定制适合团队的规则-这实际上可以是个人定制；例如，我在一个规则为的团队中工作：

所有代码都必须成对编写，但David可以单独编写代码。

David是一位高级开发人员/架构师，主要从事其他人会在自己的代码中使用的工具方面的工作。他非常拥有自己编写的代码。它是可维护且经过测试的，并且团队中的每个人都知道他可能是那里最好的编码器，并且让他构建某些框架并将其完整地呈现给团队可以使团队得到最好的服务。

我对花园的性格内向者没有答案，但是对于异常内向的人，团队将乐意采用不同的规则以获取收益。