James Shore 声称敏捷正在走向衰落。他说,很多团队在用“sprints”和每日例会,但是却不采用那些可以在长期内产出高质量软件的技术实践。在他的估计中,已有无数个Scrum 团队将敏捷用的如此之烂,不仅失败已成必然,而且会将敏捷的发展跟他们一起拖入泥潭。
James 的文章中,大部分都是在指责 Scrum 和 Scrum 的误用。他将 Scrum 和 XP 进行对比,指出 Scrum 故意把 XP 中包含的技术实践抛 在一边。在一些技术话题上——例如结对编程、测试驱动开发、持续集成、自动化测试——Scrum 保持了缄默。但是如果没有这些实践,团队很快就会造出一个 庞大且蠢,问题多多难以维护的代码库。然后这就会变成他们身上重重的禁锢,使他们无法像敏捷团队一样快速应对变化。
James 认为,这也不能说是全都是 Scrum 的错,因为团队必须要为自己的成败负责。很多团队都只选用 Scrum 中浅显简单的部分应用,例如短迭 代和每日例会,更困难而且也是更重要的实践——如回顾和改进——就不管不顾了。在这个过程中,团队本应有能力识别并且采用一些工程实践,帮助他们在每个迭 代中交付可用软件,但不幸的是,很多团队都没能做到这一点。
很多人评论说,这个问题不是源于 Scrum 本身,而是那些把 Scrum 用的惨不忍睹的人造成的。例如,Dustin Whitney 说道,“我觉得你因为那些庸人失败了就来指责 Scrum,这相当不公平。”
James 的观点是,无论失败的原因是什么,这些失败都有可能把敏捷变成一种风潮,随风而逝。
不幸的是,有很多自称敏捷的项目在走向失败。他们正在失败。最后 Agile 将承受这后果,它会离我们而去,正如一切流行时尚一样。
Simon Kirk 的回应则十分乐观:
我赞同作者的这个前提,很多冠以“敏捷”之名所行之事的确名不副实。不过我也相信,这是普及敏捷(我是说真正的做好敏捷)的过程中无可避免的一步。
敏捷是时尚么?它真的难度很大,大多数团队都没法有效实施?或者它只是正在经受成长的烦恼,即将迎来更广泛更加成功的应用?请留下你的看法,与其他读者共享。
查看英文原文: James Shore: The Decline and Fall of Agile
译者注:
在 InfoQ 英文站上,James 也留下了评论:
很多人都把我的这篇文章视作对 Scrum 的责难,但这不是我的本意。我只是想着重指出我所见的失败案例,还有导致失败的成因。最大的问题不在于 Scrum 或是 CSM,是那些买椟还珠的人。
Bob 大叔则以诙谐辛辣的笔吻写道:
现在我们总算找到答案了。我们知道是谁的问题了。是 SCRUM!SCRUM 是敏捷运动失败的原因。SCRUM 是敏捷团队把事情搞糟的原因。SCRUM 是一切问题和罪恶的根源。SCRUM 带来了“敏捷衰落”。 你被我玩了。
Scrum 不是问题,它过去从来不曾成为问题,将来也永远不会成为问题。亲爱的工匠们,这个问题是我们自己的懒惰啊。
既然我们不写测试,不能保证代码的干净,那埋怨 SCRUM 做什么呢?我们不能将技术债归咎于 Scrum。在 Scrum 出现之前,技术债就存在已久了,而且它还将继续存在下去。不,Scrum 不应该被骂。罪魁祸首还是跟从前一样:我们自己。
当然,两天的认证课程不足以构成一个优秀软件领导的充要条件。而且在参加完 CSM 课程以后得到的证书,除了能够说明你花钱参加了两天的 CSM 课以外,也没有别的用途。而且在工程实践方面,Scrum 也有很多欠缺。但无论是 Scrum 还是 CSM,它们的目的都不是从我们中间培养出工程师,或是给我们灌输工匠守则。那是我们自己该干的活!
有些人还说要是那些 Scrum 团队都用的是 XP,而不是 Scrum,那就不会有那些技术债了。扯淡!
让俺说的更明白一些: ASININE, INANE, ABSURDITY. BALONEY. DINGOES KIDNEYS. (荒谬!扯屁!蠢驴!XX……)
让俺告诉你们,在这,从现在到以后,不管到什么时候,你永远都有可能把 XP 搞烂。用 TDD 想留下技术债真他妈的容易。没脑子的家伙跟人结对也会把代码搞成荒地。而且,我告诉你,你会在做出简单设计以后,不再维护它。
你想知道写出优秀软件的秘诀么?你想知道怎样保证代码干净吗?你想要银弹吗?私家汤料?万事万物间那唯一的真相?
好,我现在就给你。你准备好了吗?秘诀就是……
秘诀就是……
干好自己的活。
够了,别再埋怨一切,你自己别那么懒就行了。
评论