案例分享:度量和怀疑论者
我们团队里一位满头华发、经验丰富的程序员给了我一个脸色,仅仅扬了扬眉,给了一个假笑。是的,这个脸色是在告诉我,把度量告诉那些年轻的家伙吧,看他们打算怎样帮助提升我们的团队,你们做你们的,我不会搞砸什么,他的沉默表明了他的观点。我不想说什么,但是他仰起的下巴让我知道他并不买账。他是一个怀疑论者。
一个月过去了。我们召开了团队会议,我给每一位同事展示了一组公司和产品的度量。它展示了我们的产品目前情况怎么样,我们怎样与竞争产品(就我们知道的而言)相比较,已完成的单个特性如何。我们关注那些在过去6个月里实现的产品特性。每个人都非常投入。这是我们整年中开过的最活跃的一个会议。即使我们满头华发的程序员也提出了很多看法。
又一个月过去了。我们召开了另一个团队会议。在这次会议中我们着眼于公司和产品度量的更新,但是我们同样着眼于从我们近几个sprint(我们使用敏捷方法,因此我们工作的增量是“sprint”)提取的团队度量。我们刚刚发布了一个新的特性。我们思索团队度量如何才能够关联到新特性的接受度、哪些度量是重要的及其原因。那位满头华发的程序员说实现最后一个sprint中特性的工作的复杂度太高,他预计我们的测试或许有些一些问题没有发现,并且我们可能预见有不少的问题会在最终产品中发现。尽管我们的QA经理指出所有计划的测试及完整的回归测试都完成了,但我们都认为有些事值得关注。
又过去了几个月。现在我们拥有关于新特性客户接受度的良好数据,虽然不是十分壮观惊人,但很确凿,并且在产品中发现了一些问题。我们的程序员是对的。相对其他我们跟踪过的特性来说,这个特性的问题的比率和复杂度明显比较高。大多数的问题已经在那个点上修改掉了,但是团队依旧做了记录以便于未来考虑。第一次,我们同样开始考虑个体程序员的度量。我们考虑了在sprint中工作的复杂度,包括产品特性开发和产品bug的修复。我们考虑了每个程序员处理的打断事件,并且我们也考虑了每个人负责多少部分的代码。我们考虑了程序员花了多少时间帮助他人,这称为“助攻”。我们也考虑了基于团队收集的度量。我们讨论这些度量怎样可以关联到团队目标、团队的成功、产品的成功和公司目标。我们同意在接下来的月份继续关注这些度量,看我们可以从中学到什么。
有些有趣的度量显现了出来,一些团队成员对它们提出了自己的看法。例如,有一部分程序员有非常高的工作负荷,但是他们负责的事项的平均复杂度又不高。其他程序员又刚好相反,负责高复杂度但是更小工作负荷的事件。我们没有从中得出什么结论,只是发现这非常有趣,并且说出心中的疑惑:这看起来分布不均的任务复杂度对于团队来说是否是件好事。另一个显著的事实是,当其他程序员没有提供任何协助时,一些程序员拥有非常多的“助攻”。我们讨论了怎样度量这个,请主管来扮演观测员。在这一点上,看起来大家都没有问题。那位经验丰富的程序员什么也没有说。
然而,在两天后他走进了我的办公室。“Dang,”这位程序员说道,“一群伙计对那些年轻人帮助了很多。我没有任何“助攻”—— 我没有做这些。我只是想让你知道我明白了。我肯定会去做我的那一部分。”就是那样。
又一个怀疑论者被同化了。