《程序员度量:改善软件团队的分析学》一公平和一致性

公平和一致性

当使用度量时,对度量是否公平的担心是合理的,因此度量需要尽可能精确和一致。需要的不是完美,需要的是数字能够对真相有一个公平的呈现。如果一个篮球运动员得了16分,而你只告诉他只得了6分,这显然是不公平的,并且球员或其他人会很快忽视掉这样不精确的统计数据。但是,在两个球员同时夹击导致对手失球的情况下,需有主观判决来决定哪位球员获得了抢断,这时已经足够公平,并且这样的小问题就不会影响统计的整体有效性。
一般而言,数据的精确性取决于系统的可靠性以及观测员对所记录的东西的理解。保持精确的产品bug数目的跟踪,例如,跟踪完成某些任务的时间不是一个困难的工作。至于“主观判决”的运作,我们可以定义一个决策指南,并且在需要时进行调整。
相对于公平而言,在很多情况下,度量数据的一致性更难于确保。导致数据不一致的原因是多样的,包括随时间而产生的共同的范围胀缩,或者团队对严重性和复杂度评定在主观上的不同。例如,完成复杂任务的时间可能随着开发工具的改进或者更高级的编程语言的使用而下降。一个人认为是中等复杂度的问题而在另一个人眼里可能具有高的复杂度。
标准化和校准是提高数据一致性的两项技术。校准是移除那些由于人们在评定时引入的“主观的”不一致性的过程;标准化是移除那些由于在不同分组和时间里出现的“非主观的”不一致性的过程。
拥有1000个用户的产品相对于拥有上百万用户的产品来说,自然应该更少接到来自客户的支持电话。如果想要分析跨多个产品的客户支持事件的度量,那么我们需要以“每1000个用户的电话支持数”来标准化那些数据,而不只是使用原始的客户电话数。另一个可以使用户标准化的例子是,试想一个开发团队,由于开发库的演进和成熟,生产力获得了巨大的提高。由于使用了更好的开发库和代码重用,一个新的产品特性的开发相对之前的工作来说,只花了一个季度的时间。如果想比较整个时期生产力的度量,我们需要对每个时间周期的平均生产力进行标准化。表2-2给出了这个例子的数据。

这有点类似于在体育比赛中统计学家在不同时代间进行比较的方法。在20世纪早期棒球的“死球”时代,相比今天,很少球员打出全垒打。其中的原因很多,例如,非常多的磨损球的使用、球场的大小和比赛规则已经改变等。知道这一点,以及了解在一个赛季里打出30个全垒打是一件罕见的事(Babe Ruth在1919年创造了29个全垒打的联盟纪录),统计学家可以通过标准化数据来比较不同时间的全垒打。例如,不是看原始的全垒打数目,而是可以看他们在同辈中的排名,或者他们或许可以把在“死球”时代的一个全垒打等价于现在的两个全垒打。
校准可以用于纠正那些在数据中由于主观评定的要素导致的不一致性。很多组织在绩效考核(包含了很多主观内容)时使用校准流程,这里可以使用类似的流程。最典型的方法是进行一个现场会议,所有评分人员被召集在一起,对彼此的打分进行复查,并且决定是否有一些评分应该调整,以使不同的分组之间更公平和更一致。其目标并不是复查个体的打分,而是复查每个分组所采取的标准和评定量表,最终“校正”到一个共同的标度。
例如,你有3个敏捷软件开发团队,并且每个团队使用T恤衫的尺寸(小、中、大或加大)来评估任务的复杂度,你或许需要scrum主管和团队主管一起来复查当前的和即将到来的任务评级。如果有人或者团队有倾向使用相对简单或复杂的度量指标进行任务分类的话,比如,对某个任务,如果其他团队一般将复杂度评为“大”,而这个团队将其评为“加大”,这些会议应该把这些差异识别出来。小组可以讨论这些差异并且决定如何调整,这样每一个人可以尝试使用相同的标准和标度。即使一个校准的会议或许就足以确立共同的度量指标。

时间: 2024-09-03 03:21:58

《程序员度量:改善软件团队的分析学》一公平和一致性的相关文章

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

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

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

有价值的数据 本书后续章节将讨论一些特定的程序员度量.某些度量相当简单,基于产品bug这类原子数据:而有些度量相对更复杂一些,它们需要利用公式以及多个数据元素的组合. 无论如何,在深入探究特定的度量之前,我们都应考虑各种可用于程序员度量的数据类型,并思考这些数据是否有用处.我们需要广泛而深入地思考那些令人关注的.新的数据元素,因为它们能够带来更有意义的度量.同样,程序员和软件团队的工作需要关联到团队和组织的目标.我们也同样需要认真地思考如何确定这些数据. 下面的列表是我发现的一些有用的数据示例,

《程序员度量:改善软件团队的分析学》一观测员和统计表

观测员和统计表 当无法从现有系统中获得数据时,最好的办法是用现行职业球队的方法--也就是观测员和统计表.职业球队利用特定的统计分析管理者,也就是观测员,去观看比赛,为球员个体和球队填写统计表格.在一些运动(如棒球比赛)中,可能有官方的记录员来跟踪统计数值,并且在必要的时候负责主观判决(judgment call),如决定某个回合是安打还是失误.但即使在这样的例子中,记录员常常也需要观测员来协助他们,另外,球队拥有自己的观测员来跟踪那些并没有被记录员记录的统计数据.技术可以自动化一些统计收集的过程

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

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

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

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

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

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

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

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

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

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

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

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

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

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