BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

回顾《敏捷宣言》发布以来的10年

| 作者 Mike Cohn 关注 1 他的粉丝 ,译者 郑柯 关注 3 他的粉丝 发布于 2011年3月5日. 估计阅读时间: 7 分钟 | CNUTCon 了解国内外一线大厂50+智能运维最新实践案例。

本文是《敏捷宣言》10年系列纪念文章之一,该系列文章将陆续在InfoQ上发布。

自打《敏捷宣言》发布以来,发生了很多变化。回看当时,宣言涉及的各种流程,包括极限编程、Scrum、动态系统开发方法(DSDM)、特性驱动开发以及其他流程等等,仅仅处于软件开发世界的边缘地带。因此,当时很容易认为这些流程不适于开发真实世界的应用。

我知道这一点,因为我当时工作的公司就是这么想的。在宣言出现前几年,我正在为一个大型企业集团某个分部的软件开发组主持Scrum开发。当时所有分部与开发相关的VP聚在一起,讨论在所有的分部中共同采纳一种通用的开发流程,我无法说服其他VP认真考虑Scrum。尽管我所在的分部取得的成果最为显著,而且我们将之归功于我们在数十个项目中使用的Scrum方法,我还是无法让其他人产生即使是尝试Scrum的想法。

即使是在我所在的分部中,我们也在质疑使用Scrum的决策。毕竟,当时统一过程(Unified Process)才是最热门的话题。人们都觉得:如果你没有使用统一过程,也许你应该用用看。我们用Scrum取得了巨大的成功,但是大家还是充满怀疑——如果使用一种完整的方法论,而不是这种称为Scrum的玩具式过程,我们是不是能够更加成功?毕竟,我们不知道还有谁也在用Scrum,而“敏捷软件开发”这个词汇当时还不存在。当整个世界似乎都在转向“统一过程”的时候,如果你是唯一没有使用的,很难不产生疑问。

在此后一个二月的早晨,我收到一封来自Ward Cunningham的邮件,其中提到:“看看我是如何度过前几天的。”他提供了一个网站链接:agilemanifesto.org,还有一张粗糙的照片,画面上是一些人围着一个白板。但是那个网站像一道闪电击中了我——说到底,我们并不孤独。突然,我知道至少有17个人跟我们有同样的感觉。后来,日复一日,越来越多,每个人都签上了各自的名字,并在agilemanifesto.org上添加了一个团结一致的简短宣言。

我们所做的事情起了一个名字——敏捷,随之像我们这样的人从各处跳了出来。“没错,我们也是那么做的。”这句话成为了早期敏捷人士的标志性语句,我们都发现自己并不孤独。

现在,十年过去了,事情发生了180度的转变。如果你现在没有使用敏捷,或是没有转向敏捷,你可能会觉得自己应该这么做。十年以来最大的变化,是人们在讨论应该使用哪种流程时,敏捷现在也有其一席之地。如果今天我是某个大型企业集团负责软件开发的VP,并且提议其他分部的VP采纳敏捷,他们不会摆手拒绝。敏捷,虽然有多种形式,现在已经成为可行的、可信赖的另一种方案。它也许不适合所有的公司或是项目,但是大家不会对其一笑置之。

十年之间,敏捷从被一笑置之到成为可信的解决方案。敏捷接下来会走向哪里?也许会发生两件事情。首先,我希望所有的“品牌”都消失。不再有Scrum,不再有XP,不再有看板或是精益,没有动态系统开发方法,也不再有水晶开发,只剩下敏捷。在二十年前面对对象的发展过程中,我们看到了这个过程。我们曾有很多种建模方法和途径,它们来自Rumbaugh、Booch、Meyer、Jacobson等人。这些差异最终被放在一遍,现在我们只有对象和UML。

下一个变化,我希望看到(而且预测必将发生)的是:在接下来的10年,面向对象世界中发生的事情会再次出现:我们不再讨论敏捷。不久前我们不再讨论对象了,因为它们已经胜出。没有人再会参加针对面向对象的大型辩论。当然,还有有些应用我们不使用对象,比如有严格性能要求的应用。也有些项目是用非OO语言开发的。但即使在这些案例中,我也怀疑开发的代码仍然收到对象的影响。我希望敏捷也能达到这一点,我们不再讨论敏捷。不再说“敏捷软件开发”,我们仅仅说“软件开发”,当然一定是敏捷的。没有人会问我我编写的Ruby代码是否面向对象。毋庸置疑。我希望某一天没有人问我项目中是否使用了敏捷,毋庸置疑。

再过十年,我希望有人让我回顾《敏捷宣言》发布后的二十年。我希望:到时候它已经称为被人遗忘的文件,就像《大宪章》【译注】一样。没错,那份落满灰尘的东西。我的生活仍然被《大宪章》影响,而且我最近被召唤作为陪审团成员,正提醒了我这一点,但是我基本上不会想到它。我希望《敏捷宣言》有类似的命运。当我十年后回顾敏捷软件开发时,我希望我们不再称其为敏捷。我希望我们不再给其赋予任何特殊的名字,而是成为日常的实践。

关于作者

Mike CohnMountain Goat Software的创始人,他在其中教授并指导Scrum和敏捷开发。他是《Succeeding with Agile: Software Development with Scrum》、《敏捷估算和规划》以及《用户故事与敏捷方法》的作者。Mike拥有25年经验,曾是多家公司的技术高管,公司规模包括初创公司和财富40。Mike常常为杂志写文章,而且频繁在各种会议上演讲,Mike还是Scrum  Alliance和Agile Alliance的创始成员。可以通过该网址联系到他。

【译注】:大宪章(拉丁文Magna Carta,英文GreatCharter)是英国于1215年订立的宪法,用来限制英国国王(主要是当时的约翰)的绝对权力。订立大宪章的主要原因是因为教皇、英王约翰及封建贵族对皇室权力出现不同的意见。大宪章要求皇室放弃部分权力,及尊重司法过程,接受王权受法律的限制。大宪章是英国在建立宪法政治这长远历史过程的开始英国是一个没有成文宪法的国家。他们的宪法是由一系列的文件和法案组成,其中具有奠基意义的一份,就是在1215年6月15日,由英国国王与贵族们签订的《大宪章》。这张书写在羊皮纸卷上的文件在历史上第一次限制了封建君主的权力,日后成为了英国君主立宪制的法律基石。

查看英文原文:Reflections on the 10 Years Since the Agile Manifesto

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

无病呻吟 by Deng Hui

呵呵,无病呻吟,正确的软件开发方式一致都存在,也一致都有懂行的人在用,也开发出了很多优秀的软件。到是一些咨询公司没事就整新名词忽悠来、忽悠去。。。无聊呀

敏捷不错。 by xue gang

新生事物,从无到有不容易。敏捷确实给软件工程提供了实践基础。研究过就喜欢了。

Re: 无病呻吟 by Li Tao

大师,你暴露啦,哈哈。

大师不作为,人家只好花钱请咨询咯,外来和尚好念经嘛。

我认为敏捷和面向对象一样,都是更符合客观实际的一种思维方式的转变,是理想主义(瀑布式)向现实主义(敏捷)的一种转变 by compass compass

我认为敏捷和面向对象一样,都是更符合客观实际的一种思维方式的转变,是理想主义(瀑布式)向现实主义(敏捷)的一种转变。

呵呵 by yulong chen

到现在我公司还有人认为敏捷这套就是拿来忽悠人的,拒绝TDD,拒绝敏捷相关的任何东西

Re: 呵呵 by wu Geckor

到现在我们公司上层还是不知道敏捷是什么。而且当我提议时,几乎断然拒绝。理由是,这样没规划的做法,风险太大

Re: 呵呵 by Zou Hao

其实引进敏捷的初期还是很痛苦的,太多不习惯
而且,“没有银弹”,所以不要为了敏捷而敏捷

Re: 呵呵 by 东喆 王

在小范围尝试,拿出切实效果就有说服力了。不用和领导上来说敏捷这样的名词,肯定会以为忽悠他们,就做一些实际的事情,之后争得他们仍可就行。就像本文作者说的,让这种做法成为习惯,开发软件就应该这么做。

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

8 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT