过去几天，Scrum Development Yahoo 讨论小组有个激烈的讨论，如果团队中某人“表现欠佳”，你该怎么办？针对Rotten apple in Scrum team这个帖子，回帖多达 130 多篇，讨论也五花八门，从对该问题的建议，到团队士气以及谁来负责的讨论，再到怎样衡量个人这样的经典争论，以及怎样识别一个团队是否是真正的“团队”，当然还有一些其它的内容。
争论是这样引发的，Marko Majkic 说他发觉团队中有一个人“表现欠佳”，并询问大家有什么好的建议（引用自最早的帖子以及稍后的回复）：
开发人员平均每人完成 38 个 usp（用户故事点数）。而有个人只贡献了 19 个──只有其他人的一半
……
我并不认为这个家伙懒惰，或者心怀恶意。对我来说，他看上去心不在焉，或者没把精力放在工作上
……
我应该在 Scrum 回顾会议上提出来吗？或者我应该与这个家伙私下里谈谈？要是你会怎么做呢？
这句话引出了很多的话题，其中之一就是讨论 Marko 最早的那个问题，怎样处理那个表现欠佳的人。许多回帖都建议，当前最重要的是做一个全新而客观的评估，看究竟发生了什么。Paul Hudson 总结说道：
正如其他人所说，退一步海阔天空。 根据你的描述，在我看来，你可能认为那个人效率低下，应该责备他，而没有指出隐藏的问题，去帮助他。
……
我（以及其他的几个人）建议你从另外一个角度考虑。根本没有什么灵丹妙药。你需要找出那个人是否有什么问题或顾虑，并跟他一起讨论这些问题。
……
所以 [具体的] 建议包括:
a） 确认这真的是个问题，并且就是你认为的那样
b） 对那个家伙可能遇到的问题多了解一些
c） 在团队中或者私下里提出来并讨论这个问题
如何按照 Paul 列出的建议去做呢，有人给出了进一步的建议，比如：
- 谨慎选择字眼来描述这个人；就是说，用“烂苹果”来描述这种情况就挺糟糕的，更不用说来描述这个人了！（注意 Marko 完全赞成这个观点）
- Mark Levison的建议是，用初学者之心解决这一情况（由 Jean Tabaka 和 David Hussman 提出)
- 其他一些人（包括 George Dinwiddie）的建议是，花点时间与这个人结对编程
- 还有其它一些建议，判断时要保持客观，包括从 Linda Rising 那里学习
有趣的是进一步的讨论显示，Marko 并不是特别担心那个人本身干了多少活，他的担心其实是这样的，团队中其他人可能很快对那个人做出一些不好的行动，比如可能在回顾会议上提出这一问题。然而正如期望的那样，很快很多回帖强调说这种结果正是我们期望的，不需要感到害怕。如 Ilja Pruess所述：
实际上我更为担心的是，如果 * 不 * 说出来会对团队的氛围有什么影响。
……
所以我觉得如果团队中有人对这种“表现不佳的人”心有不满，协调者的责任是 * 鼓励 * 组员讲出来，并帮助他们委婉地解决这个问题。
从这里也引出了对“团队士气”这个话题的讨论。该由谁“负责 [保持团队士气]？”对这一问题的反应尤其值得注意。Alistair Cockburn、Dan Rawsthorne、Michael Wollin、Paul Hudson，以及其他一些人进行了辩论，这是不是 Scrum Master 的核心作用？还是项目经理的？产品负责人的？团队自己的？CEO 的？其他人的？或者以上所有人的？讨论中间引用了一篇资料翔实的文章介绍怎样提高士气。
受 Marko 最初描述的启示，大家对如何衡量一个人的表现也展开了讨论（Marko 用的是“每个人完成的点数”），Ron Jeffries 提醒说如果团队是一个真正的“团队”，就不应该有所谓的“每个人完成的点数”这种说法。相关的讨论也提出，衡量大家的表现（客观地）不一定是错的，但是应该只是你对某个人主观评价的标准之一（比如，Eric Deslauriers 的回帖）。
对这一话题想了解更多，可以查看最近很火的InfoQ 上关于“业绩评估”的文章， 以及 George Dinwiddie 在博客上发表的team chemistry和judging performance，当然还有Mark Levison 的一篇文章。
最后请谨记，写作本文时Scrum Development Yahoo 讨论小组针对该问题有 130 个回帖，所以需要知道 InfoQ 的这篇文章只是对一些关键条目的简要概述。如果想了解全部内容，您可以亲自去查看那个帖子，当然您也可以在那里或者这里发表自己的想法。
注册/登录 InfoQ 发表评论