为什么软件开发方法论让你觉得糟糕

Why Software Development Methodologies Suck

There’s a lot of dogma in the religious wars around software development practices and methodologies. Are phase-gate methodologies effective at managing the risk of software development, or just risk management kabuki? Does TDD really make for higher quality software? Is pair programming a superior replacement for code review or just a way to inflate consulting rates? I’m going to argue that while scientific evidence to decide these claims is lacking, there are two general principles which can help us choose good practices while at the same time improving the value of the software we deliver: reduce cycle time and increase feedback.

Michael Feathers makes the following observation:

I think that, in the end, we just have to accept that developer skill is a far more significant variable than language choice or methodological nuances1. Frankly, I think we all know that, but we seem to suffer from the delusion that they are the primary knobs to tweak. Maybe it’s an extension of the deeply held view that from an economic viewpoint, it would be ideal if people were interchangeable.

The problem is, how do we get skilled developers? Since the concept of individual productivity in IT has never been satisfactorily defined, this is a particularly hard problem to solve. Lines of code - still a popular measure - suffers from the devastating flaw that a line of code is a liability, not an asset as is often thought. Measuring number of hours worked encourages heroic behavior - but experience shows that the “heroes” are usually the same people that cause projects to become late through taking unacceptable risks early on, and working long hours makes people stupid and leads to poor quality software. There is still no generally accepted set of professional standards or chartering system for IT professionals, and recruiting good people is very much an art rather than a science.

Psychologists have at least addressed the problem of why it is so difficult to acquire and measure skill in IT. As Daniel Kahneman says in Thinking Fast and Slow, there are “two basic conditions for acquiring a skill: an environment that is sufficiently regular to be predictable; [and] an opportunity to learn these regularities through prolonged practice.”

But traditional software projects are the opposite of a regular, predictable environment. The only good measure of success of a project - did the end result create the expected value over its lifetime? - is so distant from the critical decisions that caused that success or failure that it’s rare for anybody from the original team even to be present to get the feedback. It’s practically impossible to determine which of those decisions led to success or failure (in artificial intelligence, this is known as the credit-assignment problem).

软件开发实践和方法论，
常见的软件开发过程方法有：瀑布模型、迭代增量开发、敏捷开发等。

瀑布模型将软件生命周期划分成计划、需求、设计、实现、测试、运维六个阶段，并规定它们严格自上而下、相互衔接的固定次序，如同瀑布流水一样。由于前一阶段的输出将作为下一阶段的输入，所以瀑布模型要求每一个阶段都做到最好，尤其是项目前期设计。然而在每个项目中需求变更都是无法避免的，瀑布模型的严格分级导致其无法较好应对需求变更且代价高昂。此外瀑布模型十分强调文档的重要性，导致开发人员需要在文档上付出大量的时间和精力。

迭代增量开发弥补了瀑布模型严格分级、缺少阶段间反馈的缺点。在迭代增量开发中，项目被分割成一系列时间较短的迭代，同时整个工程被分成了不同的小部分，每一次迭代后都比上一次增加一些功能。这些小迭代中都会包括需求分析、设计、实现、测试。通过这种方法，开发可在需求被完整定义前启动，并在每次迭代完成后，通过用户反馈来细化进一步需求，并开始新一轮迭代。迭代增量开发是基于瀑布模型的，但它不要求每一次迭代出来完美的结果，而是先把主要功能构建出来，通过反馈不断完善。
迭代增量开发仍然是一种过程模型，只是从瀑布模型的线性关系转变成迭代关系，因此它仍然十分强调文档的重要性
处。

阶段式（phase-gate）方法能够有效管理软件开发过程的风险，还是说只是风险管理中的花哨噱头？TDD真的能够促生出高品质软件？结对编程是代码评审的有效替代抑或只是增加了商议沟通代价？有两条常用的法则能够帮助我们选择好的实践，同时，提升我们所提供软件的价值：划小开发周期以及提升反馈效率。
我认为，我们还是得倚重开发者的能力，这才是个更重要的考量因素，而非选择哪门语言或纠结于方法论间的细微差别[1]。坦诚地说，我们都清楚这点，但我们看起来好像过度纠结于开发能力是关键因素这事儿上。或许这是个经济学里一个被广泛接受的观点的引申，但如果人是可以轻易轮换的（随便找个人都能顶上），那才是堪称理想的。

你可能会认为当我们决定怎样运作一个团队时，我们就陷入了被动。但细想一下为什么软件开发无章可循？为什么在这个环境里很难进行一些试验以及获取技能？什么实践和决定会导致成功或失败？其中的根原因就是：环境是无规律的，做出变更与理解变更带来的结果之间的反馈过程太长了。这里的“变更”一词是指广义上的需求变更、方法变更、开发实践变更、商业计划变更、代码或配置变更等等。

Michael Feathers给出了以下观点：

我认为，我们最终还是得倚重开发者的能力，这才是个更重要的考量因素，而非选择哪门语言或纠结于方法论间的细微差别。坦诚地说，我们都清楚这点，但我们看起来好像过度纠结于开发能力是关键因素这事儿上。或许这是个经济学里一个被广泛接受的观点的引申，要是人人都可以替代（随便找个人都能顶上），那该有多好呀？但事实并非如些。

怎样才能找到有（合适）技能的开发者？

心理学家至少对这个问题进行了研究：为什么IT业的技能很难被掌握和度量？Daniel Kahneman说（Thinking Fast and Slow），掌握技能有两个基本条件：一个环境足够规律以便可预测；有机会通过长时间实践来学习掌握这些规律。

但是典型的软件项目往往是没有规律及可预测环境的。项目成功的唯一正确度量就是：最终的结果通过整个生命周期里的实施达到了预期目标吗？ 很难知道什么关键活动导致了项目成功和失败，很少有人能够通过旧有或现有的项目获得答案。几乎不可能判定哪些决策导致了成功或失败（在人工智能领域，这叫作信度分配问题）。

这些因素造成了IT专业人员很难掌握引导产品和服务走向成功所需的能力。然而，开发者掌握能帮助他们更高效地达到目标的技巧，将使他们更有动力 – 通常称之为“开发完成”，尽可能快的、不考虑是否功能被集成以及生产就绪。类似的场景也常出现在其他功能性实施领域。

实际的软件项目是复杂的，没有规律可循，这会导致另一个问题 – 为了证明某种技术、实践和方法论是实际有效而收集相关数据是极度困难的，几乎不可能在脱离收集环境的情况下归纳出这些数据。

但传统的软件项目与常规的、可预测的环境正好相反。衡量一个项目成功的唯一标准–最终结果是否创造了其生命周期内的预期价值？–与那些导致成功或失败的关键决定相距甚远，即使是原始团队中的任何人，也很少能得到反馈。几乎不可能确定哪一个在那些导致成功或失败的决定中(在人工智能中，这被称为信用分配问题)。

这些因素使得IT专业人员很难获得成功的产品和服务的技能。相反，开发人员获得的技能使他们能够以最有效的方式实现他们受到激励的目标–通常会尽快宣布他们的工作“开发完成”，而不管这些功能是否集成和生产准备就绪，在其他功能领域也会出现类似的问题。

软件项目是复杂的系统而不是常规环境，这一事实导致了另一个问题–收集关于哪些技术、实践和方法实际有效的数据极其困难，以及在收集数据的背景之外几乎不可能概括这些数据。

在他那本好书里软件工程的雏形Laurent Bossavit对软件开发民俗进行了毁灭性的攻击，例如“更改成本”(或“缺陷成本”)“曲线”、关于开发人员生产率的差异是一个数量级的说法、确定锥的概念以及软件开发方法知识的许多其他基石。他指出，这些理论–以及许多其他理论–依赖于非常小的数据集，这些数据要么是从对计算机科学学生进行的非正式实验中收集的，要么是那些不可能得到有效控制的项目。作为这些主张基础的研究的组织结构往往在方法上不健全，数据分析不善，而且–最令人震惊的是–研究结果的普遍性远远超出了它们的适用范围。

因此，我们不可能认真对待任何关于敏捷开发实践是否优于瀑布式开发实践的一般说法–反之亦然。“思想领袖”的直觉也是一个很差的向导。正如卡尼曼所说，“人们对直觉的信心并不是判断其有效性的可靠指南.在评估专家直觉时，你应该始终考虑是否有足够的机会来学习这些线索，即使在一个正常的环境中也是如此。“正如本·巴特勒-科尔在他的同伴职位上指出的，“为什么软件开发方法摇滚乐”采用新方法的行为本身就能产生采用该方法的人打算带来的一些结果。

当我们应用精益软件开发思想 – 一个很重要的方法。缩短开发周期在大型产品开发中是很重要的：在Bret Victor的精彩视频Inventing on Principle中提到，“如此多的创新被发现，只要你真正理解了你在做什么，你就能发现任何事物”。

但对我而言就是这样的：我们几乎不可能实践持续改进、学会怎样使团队或个人变得更好、掌握成功创建大型产品与服务所需的技能。除非我们聚焦于尽可能使反馈间隔时间缩短，以便实际洞察其间关联，以及辨别原因和影响。

事实上，从想法到反馈的周期尽可能短的好处是如此明显和重要，应该把其作为商业模式中要遵循的一个重要原则。如果你纠结于要把你的产品创建成一个用户安装式的软件还是SaaS模式（Software-as-a-Service，软件运营服务模式，软件即服务），这时的想法会自然而然地推动你强烈考虑SaaS模式（有感而发）。如果你要重建你的系统（包含硬件），应该考虑怎样尽快实现原型（how you can get prototypes out as quickly as possible），以及模块化硬件和软件，以便你可以快速和独立地整合。3D printing（三维打印成型技术）技术看起来在这方面有着巨大的用武之地，因为它可以满足软件开发应用实践朝硬件系统（原型呈现）的演进。如果你想如愿以偿地缩短周期，或多或少按多功能型团队（cross-functional teams）方式运作是需要的。

软件方法论，即使雇用一群牛人并让他们自我组织，也是糟糕的，因为他们时常搞得“cargo-cult”（货物崇拜，敏捷开发里的知名小故事，形而上）：我们在做stand-ups（每日站立会议），我们有优先顺序的backlog（优先待办事务），我们甚至看在老天的份上实践了continuous integration（持续集成）。

我们的到头来的结果为什么还这么差呢？因为你忘了最重要的事情：建立一个学习能力和适应能力都很好的组织。
　　　在Laurent Bossavit的好书《The Leprechauns of Software Engineering》中， 他抨击了软件开发的一些惯式，比如“成本变化”（或“缺陷成本”）“曲线”，这些惯式是许多其它的软件开发方法论知识基础，称开发人员生产率的变化是一个数量级（参照确定性金字塔原理）。Laurent Bossavit说明了相关依据 – 很多人依赖从计算机科学专业学生进行的非正式试验或是从无法被有效控制的项目中收集小量数据。这些研究组织的给出的论调基础往往是不健全的，数据缺乏分析，而且，最过分的是调查结果普遍远远超出了他们的适用领域。

因此，不太可能轻易下论断敏捷开发实践就比瀑布模式之流合适，反之亦然。“方法大师”的见解其实也没太大指导意义，就像Kahneman说的，“人们在想法方面的信心，并非是有效行事可倚重的因素…当评估专家的想法，即使在有规律可循的情况下，你也一定要想清楚是否有合适时机可以引入其想法的可能性”。就像Ben Butler-Cole指出的（why software development methodologies rock），引入一种新方法往往会带来一些影响。
　　问题是，我们如何获得熟练的开发人员？由于资讯科技中个人生产力的概念从未得到令人满意的界定，这是一个特别难以解决的问题。代码行–仍然是一项流行的措施测量工作小时数会鼓励英雄行为，但经验表明“英雄”通常是那些通过早期冒不可接受的风险而导致项目延迟的人。长时间工作使人愚蠢，导致软件质量差。目前还没有一套普遍接受的IT专业人士专业标准或特许制度，招聘优秀人员在很大程度上是一门艺术，而不是一门科学。

心理学家至少已经解决了为什么获取和衡量IT技能如此困难的问题。正如丹尼尔·卡尼曼在思考速度慢“获得一项技能有两个基本条件：一是有足够规律、可预测的环境；二是通过长期练习学习这些规律的机会”。

虽然像Laurent Bossavit说的（私下交流），“一个开发者掌握的技能，受限于他/她所掌握的方法及他/她偏好一种语言甚于其它语言”。
我并非建议放弃在软件开发中的可行性试验，在这里的上下文中，我这么阐述是对的。恰恰相反的是，我说的是我们并没有努力去做好，做得还远远不够。
原文链接：https://continuousdelivery.com/2012/08/why-software-development-methodologies-suck/