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

假设检验

真理并不总是赤裸裸的。基于这个原因,当自己的某些假设成为成功的关键因素时,常常询问一下自己,在这些假设中真正重要的是什么,不重要的又是什么,这样做很有裨益。在寻找有用度量的过程中,你应该目光长远一点,不只是蜻蜓点水,并且考虑所有的可能性。有时,某个地方不能看得很清楚,新的数据可能会帮助你找到隐藏在后面的真相。你可以收集并使用度量来挑战你的假设,并且即使推翻了你的假设,也同样有帮助,因为你真正掌握了知识。
美式橄榄球有将近100年的历史,公认的一个教练理念是如果你的团队在3次进攻之后未能达成首攻(将球推进10码),并且由于距离目标太远而不能踢任意球得分,因此你们应该选择弃踢译注3。这样,成功弃踢后,双方交换球权,攻防转换。如果首攻失败译注4,对方将在易于得分的位置得到球权, 因此,弃踢看起来是更安全的方法。
但在大约10年前,一些统计人员开始分析一些数据,如第4次进攻获得达到10码目标所需的码数或达阵得分、弃踢,以及在球场不同地点首攻控球最终得分的可能性。他们所发现的是,从统计方面来讲,如果一个球队拥有小的码数剩余,并且他们在中场附近拥有球权,根据在第4次进攻成功得分的可能性,他们会优先选择第4次进攻而不是弃踢。一些思想开明的教练,如新英格兰爱国者队的Bell Belichick开始将这些想法付诸实践,并且现在这已经成为球员在某些情形下尝试第4次进攻并获得达到10码目标所需的码数或达阵得分的一个完美标准,因为它直接地提高了胜算。如果没有人花时间基于从之前的成果中收集数据然后检验这个假设的话,那么弃踢就永远都是最佳选择,这种老的教学理念或许永远都无法获得改变。
你又有多少关于如何交付成功软件的假设最后同样被证明是错误的呢? 举例来说,你或许考虑过以下关于程序员和软件开发的陈述:

  • 增加开发时间可以提高软件质量和客户满意度。
  • 越庞大的团队越效率低下。
  • 更有经验的程序员可以把困难的任务完成得更好。

不论上面的假设是对还是错,如果没有好的数据来证明,你永远都不知道。度量给出了数据来检验你的假设。
确定你想更严密地调查关键假设,特别是那些驱动你每天工作中关键决策的关键假设,同样是一个用来确定你应该收集和使用什么样的度量的好方法。例如,如果你想检验“更有经验的程序员可以把困难的任务完成得更好”,你需要收集关于任务复杂度的度量,程序员经验级别的度量,以及完成的工作的相对质量的度量。

时间: 2024-12-25 15:14:31

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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