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