我们有一个“典型的” SCRUM团队，我们致力于冲刺，并保持积压。最近，我们遇到了一个问题，即试图集成/处理一个超能力的开发人员进行带外工作（选择在正常工作时间/冲刺之外工作）的工作。

举个例子，如果团队承担了50个工作点，那么说他们将在sprint结束之前完成SCRUM框架内的所有工作，并且他们和公司都很高兴。团队成员之一决定自己在空闲时间上处理积压项目。他们不签入此工作，而是保存它（我们使用TFS，它在架子集中）。

如何处理呢？一些问题..

• 在下一次冲刺期间，该团队成员说，编程工作已完成99％，仅需要代码审查和测试。您如何在SCRUM和敏捷方法中处理此问题？
• 其他开发人员抱怨说，由于工作是在带外完成的，因此没有参与与这些故事相关的设计决策。
• 我们的产品负责人很想参加这项“免费”的工作，而过分追求成就的成员可能会故意这样做，以便使产品获得更多功能，否则团队将无法在冲刺中完成这些功能。有观点认为这正在打破“进程”。显然，质量检查，UI和文档工作仍需要完成。

我看到了很多关于不强迫SCRUM团队加班的讨论，但是团队成员的工作超出了Sprint计划和执行过程中提出的期望又超出了预期吗？我会犹豫要与这个人打交道，并说你不能做更多的工作（当然要小心烧伤），但与此同时，这似乎在团队的某些成员（但不是全部）上引起了一些问题。

如何将一个过高的成员完成的工作整合到SCRUM和敏捷过程中进行软件开发？

好的，所以有人会热情地编写出色的代码，而这是必须要做的，只是没有顺序。所有应有的重视：

让他们

这会在您的Scrum冲刺中引起一些麻烦。在宏伟的计划中，这真的重要吗？如果他能完成应有的工作，那就让他继续为您打造伟大的事物。

我认识了一些很棒的程序员，他们离开了公司，因为他们没有让程序员脱离Scrum这样的人工系统的约束（我本人在被视为夸张的质量保证之后就离开了我的上一份工作）。如果有其他开发人员对输入的投诉（我可能会补充说，这是完全有效的投诉），那么最好引入“ 20％的时间”程序，以使他（和其他人）以最小的干扰来做自己最擅长的事情。

让开发人员尝试使用新技术或功能，而不是将来的故事（可能需要其他人的帮助）。您可能会发现一个巨大的新机会，而如果没有其他机会，这是永远不会发现的。我敢肯定，如果您允许他们，他们愿意尝试一些事情。

我认为您应该在这里考虑两件事：

1. 不要阻碍别人的创造力。
   • 如果开发人员想从事非工作时间，那么就让他们。
2. 不要为他人创造工作。
   • 如果开发人员想从事非工作时间， 那么最好不要为别人做更多的工作。

第二点可能是其他开发人员担心的问题。

就像您提到的那样，他们不喜欢在没有整个团队投入的情况下编写代码的事实。这可能是因为就设计而言，它最终是劣等的。设计欠佳的代码可以感染周围的其他代码。

所以，你可以做什么？

让雄心勃勃的开发人员根据自己的意愿编写代码，但要明确指出 没有理由假定将使用他的课外代码。

毕竟，他是团队的一部分，所以团队应该参与所有代码的开发方式。

但是，如果他的工作是合理的，并且符合团队同意的设计，那么他将能够使用他已经写过的很多东西（奖金！）。如果没有，这将迫使他在下次决定领先时考虑更多关于自己的设计的想法。

这样，没有人被告知NO，也没有人为他们创建额外的工作。

让他回到团队

您应该问问自己（或者更好的团队，包括成绩斐然的人）：

为什么这种行为有问题？

由于您将开发人员标记为成就超群的人，所以我想他的工作质量很好，所以我认为这不是问题。

但是似乎还有其他问题：

• 额外的工作没有经过正确的测试
• 它没有记录
• 团队的其他人都不知道
• 开发人员决定下一步实施，而不是PO
• 开发人员没有从各个利益相关者那里得到任何反馈，无法将其纳入自己的工作。

下一个我为什么会这样：

开发人员为什么这样做？

• 如果在sprint结束时还没有足够的工作要做，那么应该就下一步要解决的问题制定团队决策（包括PO）。开发者为什么要避免这个决定？

回答完这些问题后，您就可以开始回答自己的问题了：

• 如果没问题，让他去做。尽管有些人将SCRUM视为一种宗教，但事实并非如此。
• 在团队中，您更有可能遇到两个问题：一个由流氓开发人员引起的问题和一个触发流氓开发人员行为的问题。找到一种方法来解决后者，第一个将消失。

我非常喜欢将免费工作添加到组合中的想法，但这不是免费工作-除非那个开发人员同时也是测试人员，QA，构建人员，设计师以及其他所有人员，否则不是免费的。如果他的工作可以不受任何影响地进入下一个冲刺，那就去吧。但是我认为从来没有这样。至少其他每个人都必须了解他的所作所为及其对他们的影响。他们必须了解他的变化已经到来，因此不能重复他的努力-很难告诉某人他们在一项任务上已经努力工作，只是发现流氓家伙上周做到了。

但是，您在敏捷的环境中工作，而我对敏捷的了解之一是它旨在为您服务，而不是对您不利。因此，您需要更改工作方式，以允许此类课外活动发生。这意味着要征求大家的意见和协议，没有他们的支持就无法做到这一点。它至关重要。如果团队不喜欢它，那么这个流氓家伙就会停止这样做。结束。不管他的工作多么出色，都不是一个人在做自己喜欢的事情，而是团队的努力。团队是第一位的。

因此，您需要在下一次计划会议上让所有人坐下来讨论此事，所有团队成员都需要决定允许它，或者更改您的流程以更好地管理此类活动。

也许您会得到一个解决方案，使每个人都可以处理他们喜欢的项目并将它们带到桌面（您可以想象交付时会造成的混乱：）首先突出了它的问题），或者您可以强制执行每个开发人员都有自主权来开发自己喜欢的解决方案的领域，类似于有多少个开源项目可以工作的“贡献者”，或者您可以给每个人一些空闲的时间进行试验（原来的20％的时间）。

该开发人员是否编写测试并编写干净/可靠的代码，还是只是将自己能迅速完成的工作推销出去？我个人不允许任何人在规定的时间以外工作，因为这会破坏您的估计，并指出您还会遇到其他问题。

但是，您不应在过程中僵化。Scrum只是一个框架，因此您可以随时调整流程以包括额外的时间（但同样很难计划某人的工作）。

您也可以要求他从事项目以外的工作。在看新技术或对他的事情进行培训时，他的工作方式有所不同。最重要的是，在您计划的时间表之外进行的任何事情都会破坏您的估计，我不会让这种事情发生。

我们也面临着同样的事情，基本上我们的承诺是20分，但是在上周甚至是冲刺的中期，我们用尽了编码任务，但是由于测试和其余的过程，我们没有冒险选择另一个PBI，所以程序员要做的是调查积压并开始开发未来的PBI（默默地！），并在计划中告知团队其他成员PBI已准备好进行代码审查和测试！就像你说的

实际上，我们的PO引起了一些担忧，即我们似乎有能力，但我们没有充分利用团队的潜力，这部分是正确的，但是是的，也许我们的程序员可以做更多，但是我们的测试人员无法跟上这一速度，因此冲刺失败的风险。在考虑了这个问题之后，我们发现我们需要改变对Scrum的看法，主要问题是人们不想冒险，因为我们承诺 PBI，所以团队对于冒这样的风险感到不满意。新的PBI，以防我们有免费的程序员。

简单地说，我们开始预测 PBI，而不是做出承诺。预测基本上意味着我们在计划和开始冲刺时会选择25个点，而当程序员在冲刺中途有空时，由于没有更多的编码任务，因此他/她会选择一个将来的PBI并将其放在Current Sprint中并开始工作在此之上，如果PBI可以在同一sprint中通过所有过程（测试，合并等），那么如果不是我们不会因为该PBI而使sprint失败并且只是继续进行剩余的工作（测试或合并等）到下一个Sprint，然后重新扑克以剩下的工作。因此，在更坏的情况下，可以在两个不同的Sprint中完成此操作。我知道这听起来像Scrumbut，但实际上改善了我们的工作方式。我可以总结一下它的好处如下：

• 由于承担了更多的PBI风险，它克服了冲刺失败的恐惧症
• 它使您的程序员和团队的额外工作可见
• 它提高了您的团队速度

但是，对于经验不足的团队而言，也许会减少承诺对团队完成PBI的推动力

其他一些答案表明，“过分成就”的开发人员是“流氓”或“违反Scrum原则”。这是不正确的，应该鼓励该开发人员（尽管您不应该在这段额外的时间内让别人去做任何具体的事情，但是您可以提出建议并帮助培养想法）。

Scrum中没有任何东西可以规定人们的工作方式，而他所做的任何额外工作自然都可以融入团队的运作之中。

他的工作应纳入产品积压，并在下一次计划会议中进行评估。如果您无法立即预测剩余的工作量，则应在冲刺的某个时间花一些时间来解决它（即Spike）。

有趣的是，您将开发人员描述为“过分成就”，我认为这意味着他比其他团队成员增加了更多的价值。

进行额外工作会造成困难，这意味着您的团队存在某些次优（甚至功能失调）的问题。

如果是这样，您应该问自己，为什么他仅凭一点点额外的努力就能取得更大的成就？

您能否使团队的其他成员取得更大的成就？

我已经看到了对团队进行微管理的情况，可能是通过规定的用户故事，完成的定义，最终使开发人员感到窒息。这个开发人员在做他想做的工作吗？我假设他正在做出正确的决定。这样在工作周中工作也会对团队的其他成员有所帮助吗？

让他们也当老师

拥有团队中最优秀和最先进的技能的明星开发人员真是太好了。我对此表示赞赏和赞赏。这些人通常是将组织联系在一起的“胶水”。

我将挑战视为“如何使经验不足的开发人员更接近最先进的开发人员的生产力”。

做到这一点的一种好方法是专注于让明星开发者花费更多的时间来教学，培训和指导经验不足且速度较慢的团队成员。首先，我将与星级开发人员进行一对一讨论，以便他们知道您在做什么以及为什么。在其他方面，它可能会被怀疑为隐藏的议程/管理不善

站立时，每天一次或两次，如果此人没有工作并且其他人仍在执行任务，则可以进行配对编程，以便她可以与初级成员配对并传授自己的丰富知识和经验。确保问一个问题：“有人需要帮助吗？有人在寻找一对吗？”

您还可以为最佳的开发人员找到一些“边际”工作，以帮助他们停止工作，例如增强所有人使用的工具集，运行技术书籍俱乐部讨论小组或参与其他组织项目。

我要回答一个不同的问题。我认为如何处理Scrum中的这种情况确实并不重要。无论如何，Scrum更像是一个准则。如果您希望这种情况发生，请找到一种简单的方法来调整您的流程，就像简单地假设工作已经完成一样。

真正的问题是您是否希望这个开发人员去做他正在做的事情。我认为该问题的答案中有几个方面起着关键作用：

1. 程序员做得好吗？
2. 每个人都可以跟他一起做自己的工作吗（好事还是坏事）。毕竟，他在躲避设计过程！
3. 是否支付了额外的小时数。

所有这些都会影响他在做什么对您的产品是否有意义。同样，将您的决定纳入设计过程并不是真正的问题。保持灵活性。

这违反了Scrum的租户，因为团队没有在sprint中决定工作。这是一个Scrum 团队。如果要执行纪律，团队需要纪律该程序员。

这造成的另一个问题是，它影响了团队的速度。带外工作不计入速度和消耗。因此，完成了带外工作，团队平均速度达到了50点，但是完成了50分以上。产品负责人将看到此情况，并在下一个冲刺中要求更高的速度。可能没有速度。

团队（不是PO或ScrumMaster）需要与流氓程序员解决此问题。