BT

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

采用敏捷需要面面俱到

| 作者 Mike Bria 关注 0 他的粉丝 ,译者 张晓庆 关注 0 他的粉丝 发布于 2009年2月9日. 估计阅读时间: 5 分钟 | CNUTCon 了解国内外一线大厂50+智能运维最新实践案例。

两个月以前,InfoQ曾报道过Jim Shore的那篇广受欢迎的文章《The Decline and Fall of Agile》,该文指出在日益增长的敏捷社区中有这样一种倾向,组织只是在名义上采用“敏捷”,而没有采用如何真正成为敏捷的实践。InfoQ和Jim博客中的这篇文章,都引来了无数的评论,如果你还没读过则很值得一读。

但是事情还在继续。敏捷社区领导人比如Martin FowlerJoshua KerievskyRon Jeffries以及其他人在Shore的基础上更进一步,纷纷就这一情况发表了自己的看法。

Flaccid Scrum一 文中,Martin Fowler重复了Shore大部分的观点:许多敏捷实施缺少了极限编程中强调的技术实践,比如结对编程、持续集成、测试驱动开发。和Shore一 样,Fowler也承认组织实施敏捷时普遍会优先选择Scrum,但即使这样,这也不是Scrum本身的错。作为补救措施和对大家的提醒,他强调说那些领 导实施Scrum的人需要特别留心,要找机会推动合适的技术实践:

Scrum社区需要加倍努力,确保大家理解技术实践的重要性。无论何种类型的项目评审,都要检查项目中使用了哪些技术实践。如果你在参与或者接触这样的项目,当技术实践被弃之不管时一定要跳出来。

Fowler发表此文后不久, Industrial LogicIXP的创建者Joshua Kerievsky就在Yahoo极限编程讨论小组中提出这个话题。在他的初帖the Whole Enchilada中,Kerievsky再次提起一个问题,他曾在2006年敏捷大会上提出这个问题并引发热论,问题的主要内容是“做就全做,并且从一开始就全做。”

Scrum毫无生气?敏捷逐渐衰落?
越来越多的证据表明,组织和开发社区需要面面俱到──管理的和技术的敏捷实践,二者缺一不可。

以我之愚见,“他们会逐渐采用技术实践”这种想法极其幼稚。大多数情况下,他们根本就不会采用技术实践,即使采用也是少之又少,就好像根本没采用一样。

拿来即用的Scrum对技术实践毫无提及,就像卖的轿车没有安全带以及其它关键的安全措施。如果有人愿意告诉你技术实践也是必须的(虽然他们深信“后期逐渐采用技术实践”这一想法),你还算走运,总算知道了什么是正确的Scrum。

极限编程(像本讨论组内众所周知,不仅仅是技术实践)、Scrum+极限编程、工业极限编程等等,都是面面俱到的例子。

我们一次又一次地发现,一开始就面面俱到的组织和开发社区要好得多,因为随后他们就会发现自己的敏捷流程缺少了多少东西。

所以我们需要承认好的流程依赖一些关键因素,而技术实践就是软件开发中最关键的因素。把它推迟到敏捷后期实施绝对是一个坏主意。

Kerievsky的帖子引发了激烈的辩论,有大约90篇回帖讨论了Joshua建议的价值和适用性,为什么要面面俱到的各种可能原因,以及是否真的有许多组织这么做了。此帖请务必一读。

Context, My Foot!文章中,Ron Jeffries同意Shore、Fowler和Kerievsky的观点,认为多数敏捷实施失败的本质原因是没有采用那些必需的实践:

要想成功,你得先做正确的事情,然后把事情做好。
...
为了正确实施Scrum、极限编程、或者任何形式的敏捷,你必须重构。很抱歉,这不是可选的,而是必须的。
...
极限编程以及其它地方列出了更多的实践,它们都像重构一样重要。所以要想成功,你毫无选择,必须去实施这些实践。

在重复了“要面面俱到”的观点之后,后面才是Jeffries这篇文章的真正亮点所在。他解释了什么才是组织实施敏捷失败的真正原因:组织本身。直接针对刻意回避真相的事实,Jeffries说道:

极限编程/敏捷/Scrum越来越流行,许多团队和个人都想这么做,或者想“成为”其一。这直接导致了称之为“环境相关”的一些敏捷方法。其意思是任何类型的敏捷都“太死板了”,“不适合我们的环境”。所以我们不得不修改敏捷实践,因为上帝也知道我们没法修改环境。

亲 爱的朋友们,真为你们感到难过。恰恰是你宝贵的环境拖累了你:是中央级别的执行官和高管们不能把职责和权利交给大家;是产品的人总是太忙,以致不能解释真 正要做什么;是管理设施的人不能创建适合工作的环境;是程序员不愿意学习必须的技术;是经理和产品负责人不断施压,直到对项目的质量没有任何关注。

所以这个讨论值得花很大精力关注——敏捷已经到了关键时候。专家们仍在继续讨论这一话题,你也应该一起讨论,其实我们都得讨论。不如就在这里讨论吧。

查看英文原文Adopting The Whole Enchilada

评价本文

专业度
风格

您好,朋友!

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

获得来自InfoQ的更多体验。

告诉我们您的想法

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

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

实施敏捷不需要面面俱到 by Zhang Charlie

企图面面俱到,无所不包,这种想法本身就是不敏捷的,也是不现实的。

我想 Scrum 之所以流行,可能和它的创始人从一开始,就只专注于、聚焦在找到一个最小的迭代式项目管理框架,注重敏捷的计划、跟踪和管理,而没有把它强行绑定在某一种具体的工程技术和做法之上有关,这大概是 Scrum 非常聪明的地方。既然没有明确限定和约束,那么就代表着开放,可以适用于不同类型、不同环境下的项目。

当然,任何事物都是有利有弊。Scrum 的这种开放性,也带来了实施上的一点难度,你需要 bind 具体的工程技术和做法,Scrum + XP,Scrum + UP 等等都是可选项。这时如果实施者对敏捷的本质理解和掌握程度不够,结果就可能事与愿违。

这也是为什么 Scrum 会招致非议的地方。你看 Scrum 这么流行,好像抢了 XP 的风头,有些 XP 的强烈支持者就不干了。对于 Scrum 和 XP 阵营之间的竞争也好,融合也好,张恂相信的还是好猫理论,没必要人为地分出一个绝对的高低。最终会如何演变,还是看事实和数据,让实践来检验吧。

大象的敏捷,与猴子的敏捷,必然是有所区别的,这是两种不同级别(重量级)的敏捷。我们不可能要求大象也像猴子一样能上树(来一段踢踏舞是有可能的)。所以,我们也不可能要求所有的敏捷项目都 XP,颁布诏令说不用 TDD、PP、CI 就不能叫敏捷。这显然是错误的。

敏捷不是某一个具体的做法,是不是敏捷,也不能用是否采用了某种具体的做法来判断,这是敏捷 FAQ 和常识。诸如持续集成、测试驱动开发、结对编程等等,其实都有相对应的替代做法,比方张恂提出的每日集成、UDD、PPoD 等,这方面国外的大师和专家也有不少创造。

当然,如果一个项目真的非常适合采用 XP,全部 XP 做法都能上,那自然很好,我们也没必要犹豫,坚决地用呗。

同时,我觉得也应该允许大家讨论,除 XP 做法之外的,其他可能更有效、更富有创意的敏捷实践。

敏捷实施的成功,关键在于是否真正理解了敏捷软件工程的基本价值观、原则和基本原理(为什么要这么做,不那么做...)。掌握了这些基本原理,就能够有选择、有头脑地采用某些具体的敏捷做法,甚至根据实际情况,创造出自己的敏捷实践方法(进入自主创新的阶段)。从守,到破,再到离,这是一种更高境界的切换,也是敏捷改进的必然之路。

不知道我的太极敏捷辩证思维,有没有把以上这个略显复杂的敏捷改进的方向和关系问题讲明白。

资深敏捷 OO 教练 张恂
www.zhangxun.com

Re: 实施敏捷不需要面面俱到 by 熊 小

看来这篇有500块的潜质……

Re: 实施敏捷不需要面面俱到 by Jacky Li

守、破、离……

Re: 实施敏捷不需要面面俱到 by Jacky Li

算了,大过年的,还没出正月了,先消停消停吧

Re: 实施敏捷不需要面面俱到 by 张 晓庆

此文确是一颗地雷,很容易雷到不少人

确实比较雷人的文章 by 起步 停车

确实比较雷人的文章。我个人认为环境和文化是敏捷实施的时候必须考虑的内容。即使把敏捷实施是公司高层领导亲自抓的一把手工程,也需要注意员工的思想和行为,考虑企业的能力,资源,目的......。一开始就玩的很纯粹(假设他们完全理解敏捷相关内容),遇到的阻力也会很大,敏捷的声音消失得也更快。这种情况在我们这种传统软件开发企业实施的时候很明显。

敏捷方法集虽然一般情况下作用于项目一级,但却需要组织一级的意志去贯彻执行,否则,各项实践活动在平时开发活动的各种“诱惑”中,就像小沈阳的苏格兰长裤一样,非常容易“跑偏”。所以,文章中Jeffries说"组织本身"的原因我也同意,或者说是"人"的作用没到位。高层没有亲历亲为,下面就很容易阳奉阴违。

Re: 实施敏捷不需要面面俱到 by 起步 停车

守----学习
破----突破
离----超越

日本合气道中的概念,《敏捷软件开发》这本书中提到了这个。

首先学习和掌握敏捷的原则和各项实践;其次是在上面的基础上有所突破,根据实际情况对各项规则灵活掌握或者有所突破;然后超越,能进行独立的思考,并有所发展,哈哈,无招胜有招。

我记得好像有个敏捷的大师,提到过敏捷的“成熟度”,跟上面的这个比较相像。好像也是《敏捷软件开发》这本书上说的。

非常赞成!组织环境和文化是成功的关键 by Zhang Charlie

你说的很对,考虑组织的环境、文化、主客观条件的制约,以及实施的策略等因素,是敏捷改进成功的关键。其实技术操作层面的问题往往容易解决,最难的是人的思维、意识、习惯、观念和文化等隐蔽的“人性化”因素的转变。

太极敏捷有一个理论叫 CMT,文化决定管理,管理决定技术,因此太极敏捷认为只有具有先进文化的团队和企业,才能实现真正的敏捷变革,并从中获益。我的这两点也支持你的观点。

如果只是技术人员私下玩敏捷,得不到管理层和高层的支持和投入,这种改进的效果是非常有限的,也不可能持久。

在传统企业中实施敏捷,尤其要讲究实施的策略和艺术,通常渐进和渐变(evolution),不要搞大张旗鼓的革命(revolution),避免极端和极限,是比较好的方式。

2009年2月10日 上午3时50分 发表人 停车 起步

我个人认为环境和文化是敏捷实施的时候必须考虑的内容。即使把敏捷实施是公司高层领导亲自抓的一把手工程,也需要注意员工的思想和行为,考虑企业的能力,资源,目的 ... 一开始就玩的很纯粹(假设他们完全理解敏捷相关内容),遇到的阻力也会很大,敏捷的声音消失得也更快。这种情况在我们这种传统软件开发企业实施的时候很明显。

敏捷方法集虽然一般情况下作用于项目一级,但却需要组织一级的意志去贯彻执行 ... Jeffries说"组织本身"的原因我也同意,或者说是"人"的作用没到位。高层没有亲历亲为,下面就很容易阳奉阴违。

Re: 非常赞成!组织环境和文化是成功的关键 by Jacky Li

掌门最近好像把太极敏捷的东西总结的差不多了哈?正月十五也过得挺好的哈?看看在网站上这些帖子,哪个里面不带个太极敏捷?用的真是pia~~pia~~~的啊

怎么敏捷首席的马甲还穿着? by Zhang Charlie

累不累啊...

2009年2月11日 上午2时44分 发表人 凉粉 小刀

掌门最近好像把太极敏捷的东西总结的差不多了哈?正月十五也过得挺好的哈?看看在网站上这些帖子,哪个里面不带个太极敏捷?用的真是pia~~pia~~~的啊

Re: 怎么敏捷首席的马甲还穿着? by 起步 停车

haha...

CharlieZ,我看了你的网站,说实话,有些观点还是很赞同的,但有些概念还没有看明白。

如果说Agile这个起源于西方软件界的名词或者说它的思想和原则,在被包括你我在内的软件从业人员引进国内的时候,需要做一些本地化的改进/改变,这个我就很容易明白。但是,“太极”这个概念我倒是有些糊涂了,有相关可以共享的,关于你的这个理念的资料吗?

其实讨论里面有逻辑问题 by liu ozzzzzz

比如掌门自称“资深敏捷 OO 教练”,那么我开始分析——这里的资深是说其是资深的敏捷教练吗?还是说资深的oo教练?还是资深教练?如果说是资深又要有什么标准,自然一个标准是有资历,且时间很久。就如这位专业人士自称,他在敏捷这个词被提出前就已经开始敏捷了。但是问题在于,资深这个词更多情况下是应该定义教练的,也就是说这位教练已经从事教练工作很久了。那么到底是多久呢?是不是又是14+的经验?
而这个讨论中都充满了这样可疑的概念问题,比如我不相信有人会不做重构,即便他们自己在无意识的情况下也往往是做了重构。另外我也不相信,有人会觉得加强单元测试等措施是一种不能马上看到投资收益的活动(除非这个开发是非常短暂而简单的)。而持续集成并非是说你必须不断的集成,而是根据具体的情况,加大集成和构造的密度,当然一般情况下做到每日集成是最基本的要求(你不要说你的环境比较nt的构造环境还不支持每日集成)。而pp则要求的是将codeview做到极致,而你的环境如果不能做到那么极致,但是如果你加强总是没有坏处。
实际上scrum真正开始流行,恰恰是XPer开始在操作中实施scrum,并且取得众多成果之后。而现在scrum壮大之后,有了很多人单纯的希望仅仅引入scrum就可以做到敏捷了。然而,不管如何加强测试,加强集成和构造,使用重构技术,加强互审和自审,这些不仅仅是敏捷的要求,而是现在整个软件工程业界都重视并且认同的实践。而不去实施被广泛认同的实践,而去单纯的实施scrum显然不可能取得长久的收益。而最近众多声称自己是在实施敏捷,并且对敏捷没有取得成果的抱怨,多数都是来自这些仅仅实施一些scrum方法,而忽略这些基础的有益实践的结果。
而现在scrum社区的某些人,则在利用一些文字上面的小把戏,在这里纠缠。结果会如何,大家自己考虑吧。我想,即便连硕士这样的人,这次也不会站在他们一边了。

Re: 非常赞成!组织环境和文化是成功的关键 by Li Guanglei

你说的很对,考虑组织的环境、文化、主客观条件的制约,以及实施的策略等因素,是敏捷改进成功的关键。其实技术操作层面的问题往往容易解决,最难的是人的思维、意识、习惯、观念和文化等隐蔽的“人性化”因素的转变。

太极敏捷有一个理论叫 CMT,文化决定管理,管理决定技术,因此太极敏捷认为只有具有先进文化的团队和企业,才能实现真正的敏捷变革,并从中获益。我的这两点也支持你的观点。

如果只是技术人员私下玩敏捷,得不到管理层和高层的支持和投入,这种改进的效果是非常有限的,也不可能持久。

在传统企业中实施敏捷,尤其要讲究实施的策略和艺术,通常渐进和渐变(evolution),不要搞大张旗鼓的革命(revolution),避免极端和极限,是比较好的方式。

蔡旋钟道,“你的话既不可能错,也没有分明的对,根本无对错可言,只听了让人心里舒服,所以是废话。”

你的马甲穿得也不少啊。。。 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通知我

14 讨论

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


找回密码....

Follow

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

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

Like

内容自由定制

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

Notifications

获取更新

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

BT