敏捷MVP（最有价值的播放器/程序员）

最近，我参与了一个敏捷项目（使用Scrum），管理层提出了一个想法，即团队将在每个sprint的末尾提名开发人员“ MVP”和QA“ MVP”。球队。然后，MVP将获得少量金钱奖励，免费午餐以及奖杯，以展示在他的办公桌上。到目前为止，我们已经有了两个冲刺，并且有了这个奖励系统。

我从中看到的好处如下：

• 已修复了更多错误（这是高层管理人员希望看到的，其所需方向发生了变化）
• 每个“团队”的MVP都会得到认可并获得自尊心的提升（或者这是自我的提升？）

我已经注意到做这种事情的一些不利方面（至少从开发人员的角度来看）：

• 有一些开发人员非常关注数量，以致错误修复的质量下降了。一个区域的修复导致另一区域的退化。
• 有一些开发人员正在挑选“更轻松/更快捷”的错误来增加错误数量。我猜这里可能是好是坏。
• 较高的优先级（很多时候与“更难/更长的修复时间”相关）实际上已变为较低的优先级。
• 阻塞性缺陷无法及时解决，因为通常它们会花费更长的时间，并且需要与质量保证部门进行更多的协调。
• 开发团队中的团队方面已丢失。开发人员和质量检查人员在团队合作方面的合作也没有改善，但与以前相比并没有太大改变。
• 无法轻松识别/跟踪超出错误修复范围或朝着那个数字方向努力。

我确实相信上述每个“坏”问题都可以在一定程度上得到解决，具体取决于团队如何处理每个“坏问题”。

那么我的问题是，有没有人成功完成过类似的事情，您在每个冲刺中都认可了MVP？如果是这样，您认为促成成功的因素是什么？

敏捷强调团队的努力，而不是个人的努力。所以不，这种方法显然不是敏捷的。

与其鼓励团队协作，不如鼓励每个团队成员专注于自己的结果。它甚至可能导致成员避免互相帮助（或更糟），从长远来看，这将阻止团队变得更好。

如果他们表现出色，我建议对整个团队予以奖励。

我认为这是应用不良游戏化的一个很好的例子。问题在于，您的程序员潜在地有内在动力来解决问题和克服挑战（查找和修复硬错误），而且，由于您已经实施了Scrum，因此作为团队工作。换句话说，他们潜在地想做好。

现在，至少对于其中一些人，这种内在动力或部分内在动力已由以标题（“每周MVP”）和奖励（金钱和免费午餐）组成的extrinsinc动机取代，而奖励是游戏机制中经常要包括的部分游戏化过程。

游戏化可以在工作中成功应用，但是您必须非常谨慎地利用内在/外在动机。外在动机必须具有助长自决的动力，以使动机成为内在的。但是这里发生的是相反的情况，程序员为了赢得胜利正在“游戏”。

要解决此问题，您可以做的是请管理层稍微更改规则：

• 给出与门票的难度和优先级相匹配的分数。使其变得更有趣，更重要的是，修复难以发现/重现的错误。
• 给出合作解决问题的观点（再次是TEAM）。在这里，您可以让更多的程序员与QA进行交互。举例说明程序员和质量保证人员共同解决的问题。
• 给出不同的标题，一个标题最多，一个标题最多。这应该满足程序员的竞争本能。
• 通过总结团队中每个成员的得分，可以在开发人员和质量检查人员之间建立友好的竞争关系

然而，减少出现回归错误的可能性是另一个问题。例如，您可以应用负面分数，但是我敢肯定这不是一个好主意，因为这将是一种惩罚。如果在过去一周内未检测到回归错误，则最好是自动以几分来开始冲刺。如果检测到回归错误，则程序员从0开始。

另外，在“游戏化”中有“游戏”。游戏的基本方面是您自愿参加/参与。在工作中，这可能是由管理层强加的，但通常不应强迫任何人这样做。

总而言之，这个MVP并不一定是个坏主意，但是可以稍微改变一下方法，使业务（解决重要的错误）首先出现，并强调团队合作而不是个人。

对团队成员的努力进行某种形式的小组认可可能会成为一个有价值的激励因素，但是在这种情况下，这听起来像是被误用了。您声明MVP是通过投票选择的，但是有很多提及每个Sprint修复的错误数量。听起来您的时间对MVP有一个有趣的定义-我认为应该得到“最有价值”头衔的人就是那个冲刺中为软件增添了最大价值的人。如果团队成员挑选出可以快速修复的错误，尽快消除这些错误，并导致回归错误和其他问题，那么他们并没有增加价值，而是为有能力的人创造更多的工作。跟着他们解决并解决这些问题。

我的建议是，下次您的团队获得其中一张票时，尝试进行适当的讨论。不要只是举手示意；先说说。如果某人似乎是根据他们所做的“修正”的数目获得选票，则（有技巧地）指出那些修正导致回归的地方，并建议也许应该提名修正那些回归的人来清理其他人的一团糟。如果有人将整个sprint都花在了一个棘手的问题上，请向团队指出，强调一个事实，尽管此人的解决方案数量是一个，但他们已经一手解决了软件的一个主要问题-该问题原本是如此讨厌，以至于没有人想碰它。

选择简单的修补程序并以匆忙或随意的方式进行修补是没有价值的，因此，仅执行此操作的开发人员可能不符合MVP候选资格。选择新的MVP时，请忽略团队和团队中的所有人员，然后查看软件。选择自上次以来该软件中最重要的更改。我的意思是这里单身；“没有那么多微小的错误”并不是一个重大变化。是否修复了特别明显的错误？是否添加了重要的新功能？一旦确定了这一重大变化，请问是谁对此负责。其中之一可能是您的实际MVP。如果“不作为许多微小的虫子”是唯一的区别，那么与只然后，错误计数是衡量MVP的有效方法-即便如此，我还是要研究固定的错误与造成的回归错误的比率。某人造成的每个错误都会从其计数中扣除至少1个。实际上，我要说的不止1个，因为错误的修复将导致您不得不寻找一个未知的错误，这比已经发现的已知错误更糟。一个已知的错误需要开发人员进行修复。一个未知的错误需要QA进行查找，而开发人员则需要进行修复，然后QA会错过它。

从理论上讲，如果开发人员意识到获得奖励的方法是解决更少，更大的问题，他们将针对棘手，复杂，阻塞性缺陷。这有时需要他们团结起来，要么是因为没有足够多的肉类问题可以解决，要么是因为该问题非常棘手，需要更多的眼睛。也许暗示着，在这样的情况下，如果尚不能立即确定一组人员中有哪些人在修复错误上做更多的工作，则可以分享该奖项-并记住，已完成的工作！==编写了几行代码。开发人员可能会知道这一点，但是您说过涉及管理，而管理层并不总是了解这一点。

嘿，如果其他所有方法都失败了，请忘记MVP程序。与其他参与讨论的开发人员进行交流，并指出MVP奖项对软件的负面影响。看看是否可以让他们忽略它，或者不要让它变得如此重要。下班后将奖杯放在抽屉里，下班后将现金奖赏给团队使用，再用免费的午餐买一些可以分享的东西，例如一堆纸杯蛋糕。敏捷是一个团队系统；强调个人绩效风险会使团队相互竞争。团结您的立场，分配您的bug填充软件，在截止日期之后，预算超支。

这是一个典型的例子，说明特定实践（公众认可为MVP）如何对团队的行为产生重大而间接的影响。这超出了激励，动机和奖励，实际上触及了环境/行为心理学和决策架构中的思想。酷的东西。

问题是-您如何设计一个流程，使您的团队看上去自然而然地做所有正确的事情，而不必制定严格的政策或强迫人们做某事？

我已经写过关于使用费用（按Donald Norman的《日常事物设计》的传统）进行流程设计的一种机制，该流程可以为您的团队设计。基本思想是过程中的实践直接影响一个人的行为。这样，当您的流程中的能力与团队的价值观不完全一致时，就会出现问题。

我已经为此主题举办过几次研讨会，并且不时以小组的形式出现这个特定问题。将负担理论应用到您在问题中分享的案例可能看起来像这样.....

假设您的团队重视一致性，可预测性和高质量代码。

您已经得到了一系列负面行为的清单，这些负面行为似乎都来自使用缺陷度量标准来选择团队MVP。例如，队友似乎自然地会随意选择并修复错误，从而对您的所有三个价值观产生负面影响。（我假设以前也有问题，这就是导致MVP想法的原因）。

我们将尝试通过进行一些小而重要的更改来更改团队行为，而不是基于缺陷度量标准来拥有单个MVP。

• 让任何人对任何明显地拥护您的团队价值观的个人（以及所有人，不仅仅是一个人）给予“团队荣誉”。这将通过示例使团队价值体系民主化，从而提高可预测性。（我们实际上是在我们的团队中执行此操作。）
• 开始对编程（或分配“错误伙伴”）以修复所有错误。这将通过避免草率或半确定的编程决策来提高质量，并鼓励一致性，因为伙伴会抑制不稳定的行为。（这个想法通常在研讨会上提出，看起来很直观。）

这些只是一些示例来演示该方法并帮助您入门...

这种方法的优点在于，您正在积极设计流程更改，并且有正当理由进行更改。就像在对象或UI设计中一样，您甚至可以衡量结果以了解事情是否正常。

要确保像MVP计划这样的工作正常进行，最容易的调整之一就是奖励团队成员，因为他们对团队的成功最有价值，而不是最努力的工作。

我们成功地做到了这一点，就是认出那些甚至没有从事bug或功能的人，但是做了一些很棒的事情，使团队中的每个人都取得了成功。例如，我们有一位开发人员负责指导团队中的许多新成员，以便他们可以学习体系结构以及我们的工作方式。我们的速度猛增是因为我们让这些新招募人员能够快速而有效地交付结果，尽管单个开发人员的速度下降是因为他花更多的时间来帮助团队的其他成员。

奖励团队合作精神，团队会注意到最重要的是团队，而不是他们个人的成功。