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

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).

原文：Why Software Development Methodologies Suck

       在围绕软件开发实践和方法论中有很多教条式的战争。阶段式方法在管理软件开发风险方面是有效的还是仅仅是风险管理？TDD真的能为高质量的软件做出贡献吗？配对编程是代码评审的一种更好的替代方法，还是仅仅是一种夸大咨询率的方法？我想说的是，虽然缺乏科学证据来确定这些说法，但有两个一般原则可以帮助我们选择好的实践，同时提高我们交付的软件的价值：缩短周期时间和增加反馈。

Michael Feathers给出了以下观点：

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

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

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

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

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

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

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

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

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

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

感想

          出发点很好，由于软件开发受到各种因素的制约，典型的软件项目往往会面临一个平凡而不可预知的环境，反馈间隔应尽可能短。这样，通过多功能团队，才能了解关系，找出原因和结果，建立一个能够很好学习和适应的组织。这样可以追踪的工作模式有助于员工有序地执行任务。但是，实际上，这并不是大家所希望的方法论的深化和脱离现实的全部。因此，我们不能制定理想的计划和方法。我们需要对变化做出反应和可以有效学习的团队。否则结果是，我们必须再次依赖工程师的个人技能。