在人们谈到敏捷开发实践的效果时,常常会听到有人这样引用说“在名校 Y 任职的 X 教授,曾经做过一个实验,证明了敏捷实践 Z 比传统的软件开发实践的效率要高 出 20%”。然后我们就会信以为真——因为——它确实是真实的。不幸的是,大多数进行并公布的试验,其结果都不应该被当作是真实世界中的开发项目的产出。 而幸运的是,要判断出你对实验性的结果(不)应该抱有多大的信心还不算太难。
下面是一些有效性标准,你可以用它来快速的判断一下你是否应该期待会得到和实验同样的结果:
外部有效性——也被称作
普遍性—— 可以帮助你判断实验结果是否可以适用于其他的条件。用学生来做结对编程,其结果适用于专业开发人员么?可以干净利落地回答一个字——不。如果你是在商业环 境中,那么用学生作的实验就不能当作参考,因为其应用环境,所构建的软件以及开发人员的经验是截然不同的。实验环境应该和真实世界的应用非常接近。
内部有效性—— 在条件变化的时候,其成因和结果还会是真实的么?例如,结对编程会提高代码质量么?如果一个团队在做结对编程,他们首先编写测试用例,然后用更长的时间来 构建应用——那么我们可以顺理成章的猜想是结对编程提高了质量么?还是会有其他的解释?比如他们花了更长的时间来构建应用这一事实会不会造成质量的差别?
结构有效性——你的度量方式和所研究的概念(结构)是否相一致。你所使用的度量方法,以环路复杂性(Cyclomatic Complexity)为例,它是不是确实能够表示出所评估的概念的质量?如果这里被评估的是设计的话,又会是什么结果呢?
统计有效性—— 样本的范围够不够大?其结果是不是做过大规模的统计分析?如果你看到一个调查报告,上面写着一些真正的开发人员用一星期的时间做了一个实验,结果表明使用 TDD 可以提高设计质量,我们真的能把它当真么?单从这个例子来看,肯定是不能的。一个星期所产出的数据是没法衡量在长达数月或是数年的项目中TDD 的效 用的。
在这里可 以找到一个有关评估TDD 效用(在开发速度和设计质量方面)的实验,这个实验实际上就是一些资深开发人员编写了200 多行代码。如果读者意识到了不同类型 的有效性标准,那么这里就可以很容易的看出,如果我们想把实验结果照搬到成千上万(乃至百万)行代码的项目中,那可就彻头彻尾的错了。 在 hacknot 上还有一个非常严谨的实验报告,它对结对编程进行了研究,得出了结对编程比传统的开发方式要快上 15% 的结论。
实际上,如果想要让一个实验结果可以应用于真实世界的项目中,那代价势必是非常昂贵的。用学生做的实验,其结果就只能应用于其他学生身上。用专业 开发人员在有限的时间内做的实验,就不能照搬到长期的开发项目中。如果你从前引用过某些实验结果,请带着新的视角,重新迅速翻一遍那些文章,然后回来跟我 们分享一下你的想法。
查看英文原文: Analyzing Experimental Data Concerning Agile Practices
评论