2008年1月14日,星期一10:45

如果敏捷成为主流

由Michael Mah撰写
" Google已准备好与Microsoft轰动" (2007年12月16日),这是我的同事Ken Orr在时事通讯Cutter Trends Advisor中写的, "速度问题:Google,Microsoft和Hyper-Agility,第1部分" (2007年12月20日)。

这些文章是关于Google使用所谓的Google来追随微软的客户群的"Cloud"计算框架。但是肯·奥尔’对Google与Microsoft对抗的解释强调了Google的软件开发生命周期相对于Microsoft的上市时间优势。显然,谷歌正在实践一种更加敏捷,迭代式的方法(有时每季度一次)来发布软件,而微软则与其产品的大爆炸,多年周期紧密相关。

公众可能会开始感知像Google这样的公司"agile and adaptive,"将Microsoft标记为"heavy and slow?"敏捷方法可能已经找到了马尔科姆·格拉德威尔(Malcolm Gladwell)的版本"sticky message."大多数人都认为这是从臭名昭著的《敏捷宣言》开始的-简洁而优雅。它强调了"个人与互动" in creating "通过客户协作来工作的软件,同时对变化做出响应。"

Simple and Elegant.

但是有些人感觉到"manifesto" carried an interesting connotation because of its perceived arrogance. One 宣言, by a crazed lunatic called the Unabomber, made headlines years ago by decrying the evils of an industrialized society and railing against the establishment. The agilists (who were NOT crazed lunatics) were also railing against an establishment; in this case, the Carnegie Mellon 软件 Engineering Institute (SEI). The agilists' message was that they were "lean and fast,"而遵循SEI的人是"heavy and slow."简而言之,是年轻的一代称他们的乡村长者(或至少他们的软件过程)为FAT。

蔑视已成为个人。他们为项目超支统计感到生气,厌倦了被指责为他们。所有那些Ed Yourdon Death March项目都付出了代价。他们不是疯子,但是出于许多原因他们并不敬业,这是可以理解的。

宣言和呼唤似乎有助于敏捷信息的坚持。而且,如果敏捷赶上Google的热潮,它将使许多软件开发组织考虑跟随Google的领导。

同时,一位久负盛名的国会议员Willard Duncan Vandiver引述了一个有趣的话。他在1899年的演讲中说:"我来自一个种植玉米和棉花,鸟蛤和民主党的国家,而泡沫的口才既不能说服我也不能令我满意。我来自密苏里州,您必须带我看看。"有人说演讲是密苏里州被昵称为的原因,"The Show Me State."

当时的西方人用这句话来暗示密苏里人是缓慢而又不是很聪明。 (这又是个叫名字的事情。)然而,密苏里州的人改变了定义,并声称"show me"意味着他们很精明,不容易上当。 (事实证明,该词在Vandiver之前是最新的,因此认为他的演讲可能只是在普及它。)

现在,这里变得有趣了。宣言和取名对他们可能有一些泡沫的口才,但是他们既没有说服也没有满足许多敏捷者急需的重要选区,以便他们可以练习敏捷的手工艺品。这个选区恰好是签支票的人:高级管理层。高级管理人员必须接受这个想法,并冒险冒险"manifesto"可能影响雇用所有员工的公司的概念。他们已经存在了很长的时间,以至于时时流行时尚,有时会变得愤世嫉俗。管理人员也不喜欢他们的流程’我投资被称为胖子。

敏捷者来到长者那里,他们要钱。他们想要一种叫做敏捷方法的新东西。长老回应说"You have got to 给我看看 some productivity metrics." No metrics, no money. The agilists cringe, because they associate metrics guys as process-heavy people spouting 功能点.

但是您不必费力处理或说"function points"一直都是一个对IT指标了解一点的人。我都不是,这些年来,我一直在数百个项目中收集必要的核心指标。在过去的12个月中,我的许多客户都是运行敏捷项目的公司,主要是XP和Scrum,他们想知道如何与瀑布项目进行比较。

您可以在一个拥有7,400个项目的全球数据库中拥有大量数据,这些项目包括敏捷,瀑布式开发,软件包实施,新开发,遗留,军事,商业,工程等。这些数字非常有趣,以至于我无法将它们全部纳入本文。可以说我最近参加了这个主题的巡回演讲,并为希望让我展示它们的人进行了在线研讨会。

那我发现了什么?这儿是一些精彩片段:
•敏捷团队具有指标。人们可能会认为,敏捷团队是一群没有纪律的程序员,他们只支持代码而不编写任何文档。不对。他们知道自己的时间表(时间),保持团队成员在项目上的工作记录(努力),他们计算需求和称为迭代和故事的内容(大小度量),并跟踪错误(缺陷)。
•我们可以轻松地在白板草图上将其连同速度图表绘制出来。我们需要此配置文件来捕获度量并将其加载到计算机数据库中。
•可以将敏捷趋势绘制在图表上,其中一张图片说出一千个单词(在本例中为度量)。较小的发行版,中等大小的发行版和较大的发行版从左到右绘制。纵向上,我们可以绘制时间表,团队规模以及发现和修复的缺陷。
•作为一个整体,这些项目大多数都比平均速度快。约80%低于行业平均水平。请注意,出于某些原因,其中一些花费了更长的时间(此处解释太久)。一些公司用三分之二甚至一半的时间来开发软件。
•他们使用的队伍比一般队伍大。即使许多较小的发行版都使用了小型团队,但有些(显然是为了响应截止日期的压力)还是使用了大量的人员。一家公司应用了七个并行的Scrum团队,总共有95人,其中标准大约为40人。
•在瀑布项目中,"软件物理学定律"显示了大型团队尝试创建快速计划的可预测结果-高缺陷率(有时是4x-6x)。在敏捷项目中,我们发现某些公司的缺陷数量惊人地少。表现最好的XP团队也很成熟。这些项目团队发现的缺陷比平均水平低30%到50%。其他不成熟的敏捷团队的缺陷率更像瀑布项目。

这些公司的最初结果令人着迷。突出的一件事是实际上存在学习曲线。样本具有一到四年的敏捷经验。您可以轻松地看到绩效最高的团队达到了其他团队无法比拟的绩效水平。敏捷并不是所有公司的万能药,但随着时间的推移,看看其他公司的表现如何会很有趣。

确实有趣的另一个因素是,所有公司都自上而下受到外包/印度选项的挑战。有些人采用敏捷方法作为更好,更快-并且是更便宜-的替代方法,同时节省了在北美的工作。

这也将很有趣,因此随着更多数据的涌入,将看到更多的模式出现。很快,我们将获得一系列敏捷行业趋势线的足够统计数据,我们可以根据这些趋势线进行直接的敏捷到敏捷项目比较。敏捷专家肯定会一直渴望得到一些东西:敏捷指标。村里的长者可能会接受这个想法。


迈克尔·马赫 是Cutter联盟的高级顾问,还是QSM Associates的执行合伙人。他欢迎读者在以下网站发表评论和见解 [email protected].
此类别中的更多内容: «完美项目之路 撰写有效的项目要求»

©BA Times.com 2020

麦格雷戈徽标白色网站