【软件工程】对于Why Software Development Methodologies Suck(为什么软件开发方法论让你觉得糟糕)问题的探讨

Why Software Development Methodologies Suck?

 

通过系统化对软件工程的学习，我们初步了解了软件开发的方法论。但这被认作可以在开发的时候给我们提供很大用处的方法论在很多方面却让我们感到非常糟糕，这其中包括不少原因，不少学家也在这方面做出了探讨。

方法论本身方面

方法论的英文为Methodology，编程的方法论应该是指软件开发的一整套方法、过程、规则、实践、技术。不过我们一般提到的方法论都偏重于项目、过程和人员的管理。

《Agile Software Development》的作者Alistair Cockburn提出方法论具有以下要素：角色、个性、技能、团队、技术、活动、过程、产品、里程碑、标准、质量、工具、团队价值，它们的关系可以用一幅图来表示：

正如这幅图所演示的，方法论实际上是一个比较复杂的过程，想要达到要求需要一个漫长的过程，且过程灵活性不高。

就拿方法论中的重型方法来说。

有的方法论规定了大量的中间文档和复杂的过程管理。那些中间文档被称为artifact，或工件。需要大量artifact和软件开发方法被称作重型（Heavy Weight）方法。

这些复杂的方法来源于恐惧。

在中大型的项目中，项目经理往往远离代码，他们无法有效的了解目前的工程的进度、质量、成本等因素。为了克服未知的恐惧感，项目经理制定了大量的中间管理方法，希望能够控制整个项目，最典型的莫过于要求开发人员频繁地递交各种报告。重型方法中的基本假设是过程（及各种artifact）比个人可靠。

虽然很多轻型方法都将重型方法作为反面例子，但对于大多数大型项目，重型方法是管理所必需的。

为了解决重型方法的问题产生了轻型方法。

为了解决重型方法存在的问题，业界出现了很多轻型（Light Weight）方法论。提出这些方法论的部分作者结成了一个联盟：敏捷软件开发。他们还有一个宣言：

• Individuals and interactions over processes and tools.
• Working software over comprehensive documentation.
• Customer collaboration over contract negotiation.
• Responding to change over following a plan.

在这些宣言后面还有很多原则。概括起来主要是：尊重个人，强调沟通和反馈，与客户紧密合作，保持设计的简单性等等。敏捷方法在重型方法论和无管理状态之间寻求一个平衡点，希望用低成本的管理活动带来最大的产出。

正如上面的内容提到的，方法论是在不断的进步发展的，虽然它能有效的减轻我们的负担以及减少周期时间，提高我们交付软件的价值，增加反馈，但时至今日，它仍然是一个复杂的方法。

开发人员方面

大多数的开发者常常比较目光短浅，看到的只有自己所熟知的方法，在一个企业中即使是“雇佣一群优秀的人，让他们自组织”的方法论－－也很糟糕，因为它们经常导致货物崇拜的行为：我们在做站立式的工作，我们有优先的待办事项，我们甚至在实践持续集成－－是因为你忘记了最重要的事情：建造一个组织它能尽可能快地学习和适应。

在这方面外国文章也有所提及

 

Why Software Development Methodologies Suck

Published 01 August 2012

Translations: 中文 | 한국말
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).

These factors make it very hard for IT professionals to acquire the skills that lead to successful products and services. Instead, developers acquire the skills that allow them to most efficiently reach the goals they are incentivized by - usually declaring their work “dev complete” as rapidly as possible irrespective of whether the functionality is integrated and production-ready - and similar problems arise in other functional areas too.

The fact that software projects are complex systems rather than regular environments leads to another problem - the extreme difficulty of gathering data on which techniques, practices, and methodologies are actually effective, and the near impossibility of generalizing this data outside the context in which it was gathered.

In his excellent book The Leprechauns of Software Engineering Laurent Bossavit executes a devastating attack on software development folklore such as the "cost of change" (or "cost of defects") "curve", the claim that the variance in developer productivity is an order of magnitude, the idea of the cone of certainty, and many other cornerstones of methodological lore in software development. He shows that these theories - and many others - depend on very small sets of data that are gathered either from informal experiments run on computer science students, or projects which cannot possibly have been effectively controlled. The organization of the studies that form the basis of these claims is often methodologically unsound, the data poorly analyzed, and - most egregiously - the findings generalized well beyond their domain of applicability2.

As a result, it’s not possible to take seriously any of the general claims as to whether agile development practices are better than waterfall ones, or vice-versa. The intuitions of “thought leaders” are also a poor guide. As Kahneman says, “The confidence that people have in their intuitions is not a reliable guide to their validity... when evaluating expert intuition you should always consider whether there was an adequate opportunity to learn the cues, even in a regular environment.” As Ben Butler-Cole points out in his companion post, "why software development methodologies rock", the very act of introducing a new methodology can generate some of the results the adopters of the methodology intend to bring about.

You might think that puts us in an impossible position when it comes to deciding how to run teams. But consider why software development is not a regular environment, and why it is so hard to run experiments, to acquire skills, and to measure which practices and decisions lead to success, and which to failure. The root cause in all these cases - the reason the environment is not regular - is that the feedback loop between making a change and understanding the result of that change is too long. The word “change” here should be understood very generally to mean change in requirements, change in methodology, change in development practices, change in business plan, or code or configuration change.

There are many benefits to reducing cycle time - it’s one of the most important principles that emerges when we apply Lean Thinking to software development. Short cycle times are certainly essential for creating great products: as Bret Victor says in his mind-blowing video Inventing on Principle, "so much of creation is discovery, and you can’t discover anything if you can’t see what you’re doing."

But for me this is the clincher: It’s virtually impossible for us to practice continuous improvement, to learn how to get better as teams or as individuals, and to acquire the skills that enable the successful creation of great products and services - unless we focus on getting that feedback loop as short as possible so we can actually detect correlations, and discern cause and effect.

In fact, the benefits of having a short cycle time from idea to feedback are so important that they should form one of the most important criteria for your business model. If you have to decide between creating your product as a user-installed package or software-as-a-service, this consideration should push you strongly in the direction of software-as-a-service (I speak from experience here). If you’re building a system which involves hardware, work out how you can get prototypes out as quickly as possible, and how you can modularize both the hardware and the software so you can update them fast and independently. 3D printing is likely to make a huge impact in this area since it allows for the application of software development practices to the evolution of hardware systems. Working in cross-functional teams is more or less a requirement if you want to achieve a sufficiently short cycle time.

Software methodologies - even the “hire a bunch of awesome people and let them self-organize” methodology - suck because they so often lead to cargo-cult behaviour: we’re doing stand-ups, we have a prioritized backlog, we’re even practicing continuous integration for goodness’ sake - why is the stuff we make still shitty and late? Because you forgot the most important thing: building an organization which learns and adapts as fast as possible.

---

1 Although as Laurent Bossavit points out (private communication) "A developer's skill is in part the method he/she knows and his/her reasons for preferring one language over another."

2 I am not suggesting that we give up on running experiments to learn more about what works and what doesn’t in software development, and the contexts in which such claims are valid - quite the contrary, I’m saying we’re not trying nearly hard enough.

翻译

在围绕软件开发实践和方法论的宗教战争中有很多教条。阶段门方法在管理软件开发风险方面是有效的，还是仅仅是风险管理歌舞伎？TDD真的能制造出更高质量的软件吗？结对编程是代码审查的优越替代品，还是只是一种提高咨询率的方法？由于缺乏科学证据来判定这些说法，有两个一般原则可以帮助我们选择良好的做法。同时提高我们交付的软件的价值：减少周期时间，增加反馈。

Michael Feathers作了如下观察：

我认为，最后，我们必须承认开发人员技能是比语言选择或方法上的细微差别更重要的变量1坦率地说，我想我们都知道这一点，但我们似乎有一种错觉，认为它们是调整的主要旋钮。也许这是一种根深蒂固的观点的延伸，即从经济学的角度来看，如果人们是可以互换的，那将是理想的。

 

问题是，我们如何获得熟练的开发人员呢？由于it中的个体生产力概念从来没有得到令人满意的定义，所以这是一个特别难解决的问题。代码行－仍然是一个流行的措施－遭受毁灭性的缺陷，一行代码是一种负担，而不是通常认为的资产。测量工作小时数会鼓励英雄行为，但经验表明“英雄”通常是那些在早期就冒不可接受的风险导致项目延迟的人而且长时间工作会让人变得愚蠢，导致软件质量低劣。对于it专业人士，目前还没有一套普遍接受的专业标准或特许体系，招聘优秀人才在很大程度上是一门艺术而非科学。

心理学家们至少已经解决了这个问题：为什么在it领域获取和衡量技能如此困难。就像丹尼尔·卡尼曼在思考时快时慢获得一项技能有两个基本条件：一个是有足够规律的环境，可以预测；一个是有机会通过长期练习学习这些规律

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

这些因素使得it专业人员很难获得导致成功产品和服务的技能。相反，开发人员获得的技能，使他们能够最有效地达到他们所激励的目标－通常尽可能快地声明他们的工作“开发完成”，而不管功能是否集成和生产－就绪－类似的问题出现在其他功能区也是。

软件项目是复杂的系统而不是常规的环境，这一事实导致了另一个问题－收集技术、实践和方法实际上有效的数据极其困难，并且几乎不可能在上下文之外泛化这些数据在那里聚集。

在他优秀的书中软件工程中的妖精Laurent Bossavit对软件开发民间传说进行了毁灭性的攻击，如“变更成本”（或“缺陷成本”）“曲线”，开发人员生产力的差异是一个数量级的声明，确定性锥的概念，以及方法学的许多其他基石他展示了这些理论－－以及许多其他理论－－依赖于非常小的数据集，这些数据集这些说法的基础研究的组织方法往往不健全，数据分析也不充分，而且－－最糟糕的是－－－－－－－－E调查结果的普遍性远远超出了其适用范围2.

因此，不可能认真对待任何关于敏捷开发实践是否比瀑布式开发实践更好，或者反之亦然。“思想领袖”的直觉也是一个糟糕的向导。正如卡尼曼所说，“人们对直觉的信心并不能作为判断其有效性的可靠指南……在评估专家直觉时，你应该始终考虑是否有足够的机会学习这些线索，即使是在正常的环境中。”在他的同伴帖子里，“为什么软件开发方法论摇滚”引入新方法的行为本身就可以产生方法采用者想要带来的一些结果。

在决定如何管理团队时，你可能会认为这会让我们处于一个不可能的境地。但是想想为什么软件开发不是一个常规的环境，为什么运行实验、获得技能以及衡量哪些实践和决策会成功，哪些会失败是如此困难。所有这些情况的根本原因－－环境不正常的原因－－是做出改变和理解改变的结果之间的反馈循环太长这里的“变更”一词应该非常笼统地理解为需求的变更、方法的变更、开发实践的变更、业务计划的变更，或者代码或配置的变更。

减少周期时间有很多好处－－这是我们将精益思想应用到软件开发中的最重要原则之一。短周期当然是创造伟大产品的关键：正如Bret Victor在他的令人兴奋的视频中所说原则上的发明很多创造都是发现，如果你看不到自己在做什么，你就什么也发现不了

但对我来说，这是关键：它实际上是不可能的对于我们来说，实践持续改进，学习如何作为团队或个人变得更好，并获得能够成功创造伟大产品和服务的技能－除非我们专注于让反馈循环尽可能短，以便我们能够实际检测相关性，辨明因果。

事实上，从想法到反馈的周期短的好处是非常重要的，它们应该成为你的商业模式最重要的标准之一。如果您必须决定是将产品创建为用户安装的软件包，还是将软件即服务，这个考虑会促使您强烈在软件即服务的方向上（我是根据经验说的）。如果您正在构建一个涉及硬件的系统，那么请制定出如何尽快得到原型以及如何模块化硬件和软件，以便快速独立地更新它们。3d打印可能会在这一领域产生巨大的影响，因为它允许将软件开发实践应用于硬件系统的发展。在…工作跨职能小组如果您想获得足够短的周期时间，或多或少是一个要求。

软件方法论－－即使是“雇佣一群优秀的人，让他们自组织”的方法论－－也很糟糕，因为它们经常导致货物崇拜的行为：我们在做站立式的工作，我们有优先的待办事项，我们甚至在实践持续集成－－为什么stuf是因为你忘记了最重要的事情：建造一个组织它能尽可能快地学习和适应。

尽管正如Laurent Bossavit（私人交流）所指出的，“开发人员的技能部分取决于他／她所知道的方法，以及他／她喜欢一种语言胜过另一种语言的理由。”

我并不是建议我们放弃运行实验，去更多地了解软件开发中什么是可行的，什么是不可行的，以及这些主张在什么环境下是有效的－－恰恰相反，我是说我们还不够努力。

以上便是我对软件开发方法论为什总让人感觉糟糕的看法。

英文源自：http://continuousdelivery.com/2012/08/why-software-development-methodologies-suck/