Daniel Markham 是一个实干的技术派人士,也是敏捷教练,他在上周写了一篇文章,试图回答这样一个问题:为什么有些人对敏捷如此不爽?他常常会收到一些反应消极的邮件,其中对于敏捷的言论大加贬损。如今,敏捷实践和在业界的大规模应用已经超过十年了,也许是时候停下来,像 Amr Elssamadisy 今年早些时候那样提出来一些问题了。成功和失败之间常常只有一线之隔,更不用说成功常常难以衡量了。
下面是他看到和听到的一些问题。
- 虚假的成功故事
- 没有能力完成工作的培训师
- 支持者不够灵活
- 魔力子弹综合症
- 团队支配权逆转
- 货物教敏捷
- 对于问题“拒绝回答”
- 彼此冲突的建议
- 欺诈
- 本质上一样,只是形式不同
- 小金五星综合症
这些评论反映出我们行业中的一个常见模式:如果把敏捷换成当今其他的热门词汇,可能会听到同样的话。 这些常常是怀疑的根源所在,Daniel 这么解释:
敏捷没有定义。没有标准委员会,没有考试,没有审批通过的工作步骤,没有检查列表。敏捷与 Scrum 完全不同。我个人觉得这是一件好事。敏捷是一系列最佳实践,围绕着采取迭代和增量式开发的敏捷团队为中心。[敏捷本身]只是一个市场词汇而已。
然而,有足够的证据证明:敏捷团队常常更开心,而且工作效率更高。虽然人们仍在争辩成功的要素,在 Daniel 看来,敏捷团队成功的关键在于实践、反思和调整:
这真的是一种艺术,而不是科学。光指望读上一本书或是上一次课就突然能敏捷起来,这是不可能的。就像光靠看电影或是看别人弹奏,看一本相关的书或是参加相关集会,自己无法学会弹钢琴是一样的道理。
毫无意外,有很多人跟贴:
[ Techneilogy ] 一些优秀实践(比如敏捷结对)得到恶评,是因为中层管理者的“神秘配方”心态不断传染。
[Alan Franzoni] 敏捷在实施时也要灵活,在刚开始时就想马上实施所有的“敏捷技术”,这非常难。而且实施敏捷应该来自开发人员的要求,而不是管理层的意愿。如果有些东西运转得很好,那也许就没有理由改变它。
[Rui Curado] 注重实效的模型驱动开发(也就不是 UML/MDA)和代码生成结合在一起,是迈向未来更好的开发方法的重要一步。这确实需要一些思维方式的转变,但是注重实效的方法仅仅存在于少数开发人员脑海之中。
[Ben]“敏捷人士”提出弹力球、俳句等等还有其他遥不可及的想法,我能指出的很多人都不喜欢,我能指出为什么我也不喜欢,而且只用一个简单的句子:这些跟软件开发有 tm 什么关系?!我认为敏捷社区应该认识到:很多像我这样的人不需要“解药”、“教练”和“故事”,而是技巧、清晰的结构和度量方法。
[匿名人士] 我们公司最近切换到了 Scrum,在我的职业生涯中这是第二次陷入如此境地了。所有这些迭代对于开发人员来说太累人了。两个星期的周期,一次又一次进行,完成细小的任务,这让你觉得像是一个“码农”而不是真正的开发人员。[对于 Daniel 的回应] 如果我是你(或是身处你所在的团队),我要是觉得这些所谓的敏捷对我是无尽的折磨,那该怎么办?我会在每天的站立会议上都提出这个想法,这是一个障碍,妨害了团队的表现。问题必须解决。
如果你觉得应该保留敏捷,你会如何说服怀疑人士?敏捷足够成熟了么?是否关于它的玫瑰色幻想正在破灭?它是否适于移动应用和云计算主宰的世界?还是我们的行业需要超越敏捷的流程,去寻找新的更有效的方法?
评论