《程序员度量:改善软件团队的分析学》一案例分享:度量和怀疑论者

案例分享:度量和怀疑论者

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

时间: 2017-08-17

《程序员度量:改善软件团队的分析学》一案例分享:度量和怀疑论者的相关文章

《程序员度量:改善软件团队的分析学》一导读

前 言 是否存在一种合理的方法来衡量程序员的技能与贡献,并且也同样适用于团队所有的人?是否可以通过度量来帮助个人提高程序员的自我意识,以及促进团队工作.出谋划策和目标设定?能否通过详尽的数据帮助你做出更好的聘用决策,或者更公平地进行绩效考核,从而让你的软件开发团队变得更成功? 无论你是程序员.团队负责人,还是项目经理,如果你对这些主题中的任何一个感兴趣,或者你对如何采用不同工作方式将度量应用到软件开发团队中感兴趣,那么本书很适合你.本书的思路和过去在软件开发中使用度量的方式有很大不同.本书中提出

《程序员度量:改善软件团队的分析学》一第1章

第1章概述让我们不要太确信,我们没有错过一些重要的东西.--比尔·詹姆斯(棒球统计学家和作者),摘自"Underestimating the Fog"这是一本关于程序员.软件开发团队的度量和模式的书.本书的一些想法源于我在多年前开始的对软件开发团队构成的思考:无论好坏,所有细微贡献以及无名英雄的辛勤汗水都是项目成功的关键组成部分.近二十年里,我一直在负责设计师.程序员和测试团队的组建与管理工作.这些年,我意识到一个软件开发团队就像一支球队一样,需要有各种角色的球员和不同的技能的专业人员

《程序员度量:改善软件团队的分析学》一连接活动与目标

连接活动与目标 程序员是软件开发团队中的球员,这个软件开发团队是某个商业活动或者组织的一部分.至少这个组织的一些目标同样也是这个软件开发团队的目标(因此,那些目标也同样是程序员的目标).最有意义和有用的度量允许将程序员和团队关联到组织目标上. 为了做到这一点,需要定义那些软件团队所共享的组织目标,并且这些目标可以精确地或近似地测量出.然后,需要确定程序员和团队的哪些技能是可以测量的,最终,必须建立一个模型或者度量将技能与目标关联在一起. 你可能说,运动团队有一个清晰的目标,那就是赢得比赛(并且最

《程序员度量:改善软件团队的分析学》一数据获取

数据获取 很多系统都能帮助收集数据元素.有些可以提供易于访问的有用数据,特别是那些直接打交道的或控制的并且与开发相关的系统.对度量而言最有用的系统之一可能就是实际产品本身,一些适当的手段和监控可以提供关于客户采用.使用或特定特性和产品改变的成功的大量数据.有些系统可能不容易访问,通常是你无法授权使用其他业务部门的数据.我的经验是,如果你向系统所有者或管理员解释数据的有用性和使用目的,而且说明你并不需要保密和敏感的数据,你应该能得到授权.有时我们可以直接从系统中得到数据,而有时数据是从常规报告或者

《程序员度量:改善软件团队的分析学》一关于软件采用、问题以及竞争的数据

关于软件采用.问题以及竞争的数据 除了测量程序员技能,目标受众以及那些通过不同方式和软件打交道的人员(外部用户.内部用户.销售和支持人员或者上述所有人员)对软件的接受情况也是关键的测度.收集那些可以指示软件的成功以及人们对工作的响应的质量数据,包括收集关于采用.效益和问题的数据,还可以相对于已知的竞争对手来评估成功. 关注与采用 作为度量系统的基础,确定一个软件产品.项目或者特性是否可以积极或者消极地接受,以及尝试度量这种响应的程度,非常关键.可用来对响应进行跟踪的最基础的指标是使用情况.但是使

《程序员度量:改善软件团队的分析学》一模式、异常点和离群点

模式.异常点和离群点 一般来说,我们收集和保持度量数据持续的时间越久,它们就会变得越有用.度量分析是一个模式识别的过程,意味着寻找一个重复的.可提供洞察力的模式.从单个时间段里收集到的一组度量或许会揭示出一些有趣的信息,并且我们可能会因此而得出一些有趣的假设,然而,从多个时间段里收集多个度量将可以改进我们的推测,或者把推测转化为知识. 我们在寻找模式的时候,很重要的一点是,必须认识到并不是所有的模式都是简单化的.我们必须仔细地寻找,而不仅仅只是关注于表面,因为从一些度量的组合中发现一些模式和解释

《程序员度量:改善软件团队的分析学》一软件团队是成功还是失败

软件团队是成功还是失败 在体育运动中,每个团队都为胜利而战,而成功的定义也很清晰.精确.软件开发与此不同,我们缺乏对成功的恰当测度.我所发现的最佳策略是软件开发团队的成功三角形,它基于三方面的因素:客户响应.质量指标和效率.这些都能按发布版.特性来测量,并且可以相对于先前的水平.团队目标和组织目标加以评估. 用户对每个软件发布版的响应是什么 开始时,你可以考虑以三个月为周期测量用户对新发布版的采用率是否达到了20%.你能够同设定的目标相比较.为客户响应.质量指标和效率进行这种检测,为团队提供了一

《程序员度量:改善软件团队的分析学》一假设检验

假设检验 真理并不总是赤裸裸的.基于这个原因,当自己的某些假设成为成功的关键因素时,常常询问一下自己,在这些假设中真正重要的是什么,不重要的又是什么,这样做很有裨益.在寻找有用度量的过程中,你应该目光长远一点,不只是蜻蜓点水,并且考虑所有的可能性.有时,某个地方不能看得很清楚,新的数据可能会帮助你找到隐藏在后面的真相.你可以收集并使用度量来挑战你的假设,并且即使推翻了你的假设,也同样有帮助,因为你真正掌握了知识.美式橄榄球有将近100年的历史,公认的一个教练理念是如果你的团队在3次进攻之后未能达

《程序员度量:改善软件团队的分析学》一数据选择

数据选择 为度量寻找合适的数据,有点像科学,有点像艺术,但更多的是试错.当决定使用哪些数据时,我们会面对很多选择.显然,你可以提出多种多样的测度,能获得相同的结果,或者发生几乎等同的一件事.例如,要决定一个程序员的质量测试有多好,我们可以选择去测量编写的测试用例数.代码的测试覆盖率,或者发现的bug数量和严重性.我们也可以测量所有这些.一般来说,当我不得不在多个可能使用的测度中去选择时,我基于以下经验法则来决定最优方案:选择最容易获得的数据.选择最容易让非程序员解释和理解的数据.第一条经验法则或

《程序员度量:改善软件团队的分析学》一可重复的成功

可重复的成功 虽然度量可以提升我们的理解力,并且我们可以在许多方面因此而受益.但我们追寻的第一要务是可重复的成功模式.如果找到,这些模式可以指出哪些是我们团队所需要的,以帮助我们最大化成功的概率和最小化失败的概率.常言说"人算不如天算",就眼前来说,这或许是对的.但是,幸运并不是保持稳定绩效的内因(虽然很多赌徒渴望它是).高度熟练的个体或团队看起来是幸运的,但是他们始终如一的成功缘于他们的努力工作和计划.某些人或许得到了"机遇"或有个"好运气".