根据完成的成功用户案例评估Scrum成员是否正确？

当我的经理告诉团队“ 现在开始将对成功的用户案例进行评估！ ”

我们震惊地坐在那儿，那是他给我们的下颚瞬间之一：-)

我们认为这是愚蠢的想法，因为这将破坏敏捷开发方法论的所有概念和目标。

让我知道你们的想法吗？我们如何说服他？

桑迪，很遗憾，您经理的说法是对Scrum特别是敏捷的一般误解。

提出的方法破坏了合作，违反了集体密码所有权的原则。敏捷（如果是真正的敏捷）中的用户故事在被多人触摸之前很少完成。此外，您将不时拥有用户案例，这些用户案例需要进行大量整理才能在迭代中完成。当单个激励在相反方向上对齐180度时，您将如何获得全部收益？

您的团队本能是正确的。当您集体讨论对经理的反应时，我建议您短期内阅读哪些资料？查看知名敏捷专家的博客，例如Mike Cohn，Martin Fowler，Elizabeth Hendrickson，Jurgen Appelo，Esther Derby等，并查找有关敏捷团队组织的文章。

我对这种评估方法的主要反对意见是，它可能成为开发人员之间合作的障碍。我认为开发团队生产力的重要组成部分是团队成员相互帮助的意愿。据我了解建议的方案，它可能导致开发人员坚持自己分配的任务，而忽略其他被卡住的团队成员，而他们只要一点帮助就很容易被卡住。

我们一直在寻找程序员对团队和业务的贡献。

这与测量代码行或错误数量相当，但稍微复杂一些。

乍一看，衡量没有任何问题，但是当您考虑它时，便开始提出异议：

• 那更复杂的故事呢？

是最显而易见的一个-我敢肯定还有其他人。

您的经理显然认为这是个好主意，因此您需要小心，当您提出异议时也可以提出解决方案。该解决方案可能必须是对其方案的修改，而不是新的方案。

因此，例如，您可能要指出，只从事“简单”故事的人比从事“更困难”故事的人能完成更多的工作，这可能导致专注于开发中次要的方面。因此，一种解决方案可能是考虑故事点的数量，而不是仅仅考虑故事的数量。

我同意ChrisF的观点，即任何衡量标准都可以追溯到相同的问题。您所称赞的是您得到的。无论系统如何，总会有人在玩这个系统。

我发现奖励程序员的唯一真正有效的方法包括三个步骤。

1. 领导者了解并了解团队中员工的能力。
2. 经理会听取潜在客户对不负重任的团队成员的建议。
3. 整个团队都因获得成功的冲刺而受到赞誉。

整个关键在于，程序员不是可以通过查看统计信息进行“调整”的机器中的齿轮。真正的人需要从整体上进行检查和改进，团队需要能够以合作而不是竞争的方式相互依赖。

绩效不佳的团队在被认为可以放手之前，将获得一切改善和丰富的机会。最终，优秀的程序员将在这种环境中蓬勃发展，而拒绝改进的贫穷程序员将被放任。

大多数情况下，用户故事是集体努力完成的。这实际上使基于该指标的个人评估成为不可能。

由于计划过程也是团队合作的结果，因此度量标准本身可以很容易地进行操纵，甚至整个系统都将很快被安装。这绝对是您在以人为本的过程中所不想要的。

我认为良好的表现必须由基于团队成功的某种奖励系统来认可，但“用户故事”并不是成功的良好指标。