为什么软件开发方法论会失灵?

　　作者简介：Jez Humble是ThoughtWorks公司首席咨询顾问，《持续交付》一书的作者，致力于帮助企业快速、可靠地交付高质量软件，经常在各种敏捷技术大会上发表演讲，拥有牛津大学物理学学士学位和伦敦大学民族音乐学的 硕士学位。2000年至今，他曾在各行业和不同技术领域担任系统管理员、开发人员、培训人员、咨询师和经理人员。《持续交付》是第21届Jolt大奖获奖作品，被誉为2010年最重要的技术书。

　　译者简介：苏光荣，现一淘网广告技术部高级测试开发工程师。2004年～2009年在多家软件公司担当测试工作师，各种类型的测试都有所涉及。2009年进入淘宝，从事搜索引擎的测试工作。

　　译者序：软件工程没有银弹。相对于流程、方法，人仍然是制胜武器;凿子到处都是，米开朗基罗只有一个。追风、盲目照搬和套用、流于形式的实践某种软件开发方法，并不能给你带来任何好处。只有理解方法的精髓和真正实质并实践之，才能达到预期效果。是软件开发方法失灵了吗?不是，是我们没有用好;我们还应该相信软件的各种模型、定律吗?是的，但不是盲信和盲从(cargo-cult)。Jez Humble在这篇文章里从独特的角度提出了他对敏捷方法、乃至各种软件开发方法的精髓的见解，很有启发性。

　　围绕软件开发实践和方法论，有很多教条式的争论。阶段性检查方法在软件开发风险管理方面是真的有效，还是只不过一些花拳绣腿罢了?TDD真的能带来更高质量的软件吗?结对编程是比代码评审更有效的替代品吗?或者只是为了提高咨询费而已?

　　我将要阐释的观点是，尽管缺乏科学论据，但是有两个原则可以帮助我们选择好的实践来提高我们所交付软件的价值：缩短周转时间和增加反馈。

　　Michael Feathers有如下观点：

　　我认为，我们最终不得不接受这样的事实：相对于语言的选择或者方法论的不同，开发者的技能差别是更加决定性的因素1。坦白的说，我认为我们都明白这一点，但是看起来被某种错觉欺骗，认为语言或者方法论才是问题的关键。也许这是一种根深蒂固的思想的延伸：从经济学的角度看，劳动力可以随意替换是一种完美的现代化生产场景。

　　问题是，如何找到熟练的开发人员?由于IT领域个人生产力的概念从来没有被满意地定义出来，所以，这是一个非常难以解决的问题。代码行——仍然是一个流行的度量标准——有重大的缺陷，因为一行代码是债务，非人们通常认为的资产。衡量工作时数会鼓励英雄主义行为，但是经验表明，这些“英雄”通常也是那些在早期冒了不可接受的风险而导致项目延期的人，而且，长时间的工作会使人疲劳，产生低质量的软件。目前还没有一套能让人们普遍接受的，适用于评判IT专业人士专业技能的专业标准或招聘系统，招聘优秀的IT员工更多的是一种艺术而不是科学。

　　至少，心理学家们解释了IT技能难以习得和评估的原因。Daniel Kahneman在《思考，快与慢》中指出，获取一项技能需要两个基本条件：一个有规律性足以预期的环境，以及通过长期实践来学习这些规律的机会。

　　但是传统的软件项目恰好是无规律，不可预期的。项目成功的唯一的好的标准——项目结果(产品或服务)在其生命周期中是不是创造出了预期的价值——距离那些导致成功或者失败的重大决策是如此的遥远，以至于项目团队成员甚至很少能在项目带来收益的现场得到反馈。实践上几乎不可能判定哪些决策导致了成功或者失败(在人工智能领域，这被叫做功劳分配问题)。

　　这些因素造成了IT专业人员很难掌握引导产品和服务走向成功所需的能力。取而代之的是，开发者们都学会了那些能最快达成组织规定的目标的能力——通常是尽可能快地宣称他们的开发工作已经完成，而不去考虑功能是否能被集成，是否可以上线——其他领域也是如此。

　　事实上，软件项目是复杂系统的集合体，而不是有规律的环境。这还会带来另外一个问题：证明技术、实践、方法真正有效的数据非常难以采集，将之应用到其它项目几无可能。

　　在Laurent Bossavit的著作《软件工程的妖精》中，他对一些软件开发传说进行了猛烈的抨击，例如：“变更的成本”(或者说“缺陷的成本”)、“曲线”、开发人员的生产率水平差异达一个数量级、不确定性模型、以及许多其他软件开发方法论的基石级的观点。他表示，这些理论，还有许多其他的理论，都只有非常小的数据集支持，这些数据集是从计算机学科的非正式的学生实验、或是一些不能有效控制的项目中收集而来的。形成这些理论的研究常常在方法论上是不牢靠的，在数据上是缺乏分析的，更过分的是，对这些调查结果的一般化大大超越了它们的适用领域2。

　　因此，不要拿一些泛泛的比较太当一回事：是否敏捷开发比瀑布模型更好，或者更差。“思想领袖”的直觉也没有多大参考价值。就像Kahneman说的，“人们在直觉上的信心并不可靠...在评估专家直觉的时候，你应该考虑是否有足够的机会去发现更多的线索，即使是在有规律的环境里也是如此”。Ben Butler-Cole在一篇帖子“why software development methodologies rock”中指出，引进一种新的方法论的行为可以产生一些引进者预期达到的结果。

　　你可能认为，这将使我们手足无措，不知道如何来运转团队。但是想想为什么软件开发不是一个有规律的环境?为什么开展实验、学习技能、衡量哪些实践和决策带来成功或者导致失败是如此的困难?所有这些情况的根本原因——造成环境缺乏规律性的原因——在于发生变更和理解变更结果之间的反馈环过长。这里的“变更”应该被广义地理解为需求的变更、方法的变更、开发实践的变更、商业计划的变更、代码的或配置的变更等。

　　缩短循环时间有很多好处，这是当我们将精益思想应用到软件开发中时最重要的一个原则。短周期对于创造伟大的产品是非常重要的，正如Bret Victor(译者注：苹果公司的UI交互设计师)在他精彩的“ Inventing on Principle”视频(译者注：关于这个视频，这里有一篇中文评论文章)中说的那样，许多的创造只是发现，如果你不知道自己在做什么(产生了什么结果)，你就不能发现任何东西。

原文转自：http://www.ltesting.net