BT

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

所谓“主流”敏捷

| 作者 Dan Mezick 关注 0 他的粉丝 ,译者 顾全 关注 0 他的粉丝 发布于 2010年4月20日. 估计阅读时间: 6 分钟 | Google、Facebook、Pinterest、阿里、腾讯 等顶尖技术团队的上百个可供参考的架构实例!

主流敏捷这一想法的时代似乎已经到来。大型咨询服务商现在以“敏捷性”招徕顾客,诸如IBM Global Business Services和Cap Gemini之类的公司都在大肆推销其敏捷相关的服务产品。Cognizant和ITC Infotech这样的离岸服务商也在敏捷软件和服务领域十分活跃。

主流的趋势

对在线招聘网站的一项快速扫描显示,工作描述中对“敏捷”这一术语的使用量显著增长。这里有招聘网站Dice.com和Monster.com上大约一年中数据变化的样本:

招聘广告中出现的术语 Dice, 2009年7月 Dice, 2010年4月 增长率
敏捷 2084 4088 96%
Scrum 755 1222 61%

 

招聘广告中出现的术语 Monster, 2009年7月 Monster, 2010年4月 增长率
敏捷 1756 3031 72%
Scrum 379 755 99%

这种在主流层面突然出现的受欢迎程度,对于敏捷总体上意味着什么呢?“主流”敏捷貌似如何呢?主流敏捷里又包含什么呢?Scrum是最流行的敏捷框架。因此,它也是讨论主流敏捷时一个好的关注点。那么,主流Scrum是什么样子?

根据ThoughtWorks的Martin Fowler所言,松软Scrum是新的流行病。其模式有三个步骤,模样如下:

  • 他们想使用一种敏捷过程,于是选择了Scrum
  • 他们采用了Scrum的实践,甚或是原则
  • 过了一阵子,由于代码基底乱七八糟,进展十分缓慢

据Fowler说:

...由于一直以来糟糕的内部质量,项目陷入困境。在Scrum的旗帜下出现的大量问题,可能更多是由于Scrum现时的流行,而不是Scrum自身的任何特性。

接下来就变得更有趣了,Fowler说:

我总是喜欢指出,成败不在于方法论,而在于团队。采纳一种流程可能帮助团队提升,但最终团队才是关键因素,他们负责去做对其有效的事。我确信很多正在进行的松软Scrum项目不仅会令Scrum、也会令更更广泛的敏捷蒙羞。

主流的含义

敏捷的“主流化”究竟意味着什么? 它意味着,Scrum作为一个术语,可能逐渐变得毫无意义,因为声称从事“Scrum”的组织实际上做的是另外一套,而将其称做“Scrum”。 Jeff Sutherland和Ken Schwaber对其有个命名:叫做Scrum-butt

Fowler对于这种将已有的完善定义“注水搀假”的做法也有个名词——他将其称为语义扩散

语义扩散发生在这样的时候:当你有了对应一个人或者一个团体的词汇,该词汇经常也已定义完善,但是它在更广泛的群体中传播的方式造成该定义的弱化。这种弱化的风险是:其定义完全丧失——该术语的用处也随之丧失。

因应这一趋势,Scrum的共同创造者Ken Schwaber和Jeff Sutherland建立了一个决定性、权威性的Scrum定义,称为Scrum指南。这份可免费下载的资源描述了Scrum。该文档意欲强化和保持Scrum的定义。据Ken Schwaber说:

Scrum自上世纪90年代早期开始应用于复杂产品的开发。 本文件描述了如何使用Scrum来构建产品。

对Scrum定义的一个极佳探讨,可以在Dominique Stender针对Ken Schwaber“关于Scrum的迷惑”一文所写的博客上找到。在那篇博文中,他附和了Martin Fowler对语义扩散的立场:

我也同意Ken,有一份(!) Scrum是什么的正规描述很有必要。像[Ken]指出的那样,Scrum与诸如看版、XP和其他敏捷方法是混在一起应用的。这就让一份(!) 关于什么是Scrum什么不是Scrum的“原版”文件的存在变得非常重要。需要有一个基准。

主流敏捷之于产品和产品负责人

敏捷的“主流化”可能意味着,Ken Schwaber和Jeff Sutherland定义的Scrum比任何时候都更极端。尽管敏捷步入主流领域,Scrum的共同创造者们实际上正在固化Scrum的定义。这是怎么了?

明证之一:现有的Scrum指南申明:产品负责人“永远是一个单独的人,而不是一个委员会。”而博客界的其他人现在对Scrum实施中的产品负责人问题也言之凿凿。比如,InformIT的Roman Pichler在关于产品负责人相关问题的文章中写道:

产品负责人委员会就是一帮产品负责人,而无人对整体产品负责。没有一个单独的个人来引导团体、帮助设置共同目标和促进决策。产品负责人委员会的危险是,陷入无穷无尽的会议和利益冲突、政治争斗——又被称做“委员会死刑宣判”。不能达成任何真正的进展,人们停止协作,开始互斗。

永远保证有一个人对产品负责,一个总/主产品负责人来引导其他产品负责人并促进决策,包括产品待办事项优先级排序和发布计划。

“敏捷的主流化”好像对非常清晰的术语定义提出了要求。术语‘Scrum’正在由Scrum的创立者们通过决定性的Scrum指南积极地加以定义和维护。在敏捷步入主流并更易受到语义扩散影响的同时,术语“敏捷”的实际含义正变得越来越重要。

英文原文Agile in the Mainstream

评价本文

专业度
风格

您好,朋友!

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

获得来自InfoQ的更多体验。

告诉我们您的想法

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

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

标准的CMM又如何呢?看起来诸位大师是要区分是真敏捷和假敏捷。避免假敏捷影响敏捷的推广。 by Wang Carl

我们公司内部推行敏捷时,有人问我,敏捷后是不是可以少加班或者不加班?
我回答,以前加班不是因为CMM,以后不加班也不会仅仅因为敏捷……

敏捷的成功与否,应该没有一个较为明确的度的概念。
CMM/CMMI给出一个评级制度,那有如何?这种评价和衡量对于项目和产品本身似乎没有本质帮助。
对于讲究“按需而动”(我的个人言论)敏捷本身,这种抽象模型似乎更为难以建立。拭目以待各位大师的讨论。
很难想象,哪天PO拿着一个度量表格,大声对项目组宣布,哦,我们真正的敏捷了!

允许的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通知我

1 讨论

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


找回密码....

Follow

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

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

Like

内容自由定制

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

Notifications

获取更新

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

BT