有限的好处 VS 新的复杂性,敏捷框架错在哪里了?

阅读数:3711 2019 年 7 月 5 日

不久前,我学习了一门课程,成为一名认证 Scrum Master。这其实没什么大不了的,因为我本来就已经是团队的 Scrum Master 了。随着时间的流逝,我经历了很多,也看到了敏捷框架所发生的变化。我已经开始使用比敏捷更为精简的方法。另一方面,我开始对敏捷框架进行回顾,并意识到了它的一些缺点。在这篇文章中,我将列出敏捷框架存在的一些问题。

  • 估算!我们该怎么定义它呢?以天、小时、复杂度或者其他一些奇怪的指标来表示?估算其实是有争议的。根据我的经验,估算是不可行的。估算第一次开发一个系统需要多少资源和工作量是不现实的,而且我们从来不会重复开发相同的功能。即使是第二次开发,它们仍然会不一样,因为我们在第一次开发过程中了解了未知的东西。此外,即使你擅长估算,仍然会存在一些干扰因素。
  • 站会!很多时候,你可能会觉得其实你并不真正在乎别人在做什么。而如果你关心别人在做什么,那说明你可能已经到了他们所处的状态,因为你对他们所做的事情感兴趣。所以,开站会可能是在浪费时间。如果你的团队分布在不同的时区,这将成为更大的负担。
  • 产品所有者会阻碍工程师对产品做出贡献,因为他们对产品的大部分关键部份有决策权,留给工程师的空间很少。但要知道,我们今天使用的一些伟大的产品实际上是工程驱动的。
  • 对于每个 Sprint,工程师都被要求完成特定的任务,而业务人员对工程师的要求也越来越高。持续的压力限制了工程师的自由,没有留给他们任何创空间。一些好的项目都是在工程师有空的时候完成的。
  • 从长远来看,在时间上做限制会导致更多的技术债务。任务一个接一个地来,每个人都在创造新的技术债务,因为我们没有时间进行重构,需要快速交付出东西。
  • 敏捷框架关注的是管理。管理层获得了某种可预测性,他们因此对工程师了解更多,在微管理方面获得了更好的透明度。
  • 敏捷框架假定每个工程师的工作方式都是一样的。团队一起做计划,为任务分配做评估。但是,分配到任务的人可能很难按时完成任务,他可能是团队新来的成员,或者在那个领域没有太多经验。如果要他按时交付,他可能需要承受很大的压力。
  • 敏捷软件开发也有一些很死板的东西。为了完成某个功能,你需要创建一个任务,将其添加到 Sprint Backlog 中,然后对其进行评估,并决定是否要完成这个任务。有些团队甚至更为过分,就连修改一个按钮上的标签也需要重复这个过程。
  • 敏捷框架带来了不必要的复杂性。开发人员可能没有感觉到,但敏捷框架实际上是很复杂的。你可以想想看,一方面,团队里有 Scrum Master,有产品所有者,甚至还有推动者这样的角色。另一方面,还有新的流程,新的术语,等等。如果说敏捷框架很简单,为什么我们要针对这个问题开设大量的课程或培训呢?
  • 敏捷框架最大的缺点之一是需要处理依赖关系。试想一下,如果你需要依赖另一个团队,而他们没有采用敏捷框架,那么你该如何对项目做出评估呢?
  • 敏捷框架对突发事故的应对能力很差。想象一下,在周末的时候你因为一个灾难性事件被叫到公司。你该如何为这类事件做好应对准备?怎么看待这样的事件?怎么记录它们呢?
  • 有些方法在理论上很有效,但在实际当中可能并不是最好的方法。你可以有一些度量方法,但这些度量方法本来也就是与敏捷框架兼容的。因此,度量结果在一定程度上是意料之中的。你可以说有一些团队成功地应用了敏捷框架,但你没有看到更多团队没有这样做。如果你谷歌一下,你会发现有很多文章告诉我们如何防止失败。
  • 一个优秀的团队可能不需要敏捷框架。当团队可以遵循敏捷原则,使用哪种方法真的很重要吗?或许,所有与敏捷框架有关的成功案例之所以成功,是因为团队本来就可以取得成功?

总之,我认为敏捷框架不够好有很多原因。它们提供了有限的好处,但也带来了新的复杂性。作为工程师,我们已经经历了其中的一些问题,并深受其苦。或许,是时候做出改变了!

原文链接:
https://www.yusufaytas.com/whats-wrong-with-agile-frameworks/

收藏

评论

微博

发表评论

注册/登录 InfoQ 发表评论

最新评论

JasonP 2019 年 07 月 08 日 11:35 0 回复
原作者对敏捷和Scrum应该有不少误解和不准确的解读。其实这些问题不管在什么产品开发组织中都可能存在也是很多敏捷方法力图解决的吧。 另外,不明白为什么有些专家在谈方法、实践总说那些伟大的产品是怎么样的,所以你的做法不对;实际上有多少产品能成为伟大的产品呢?伟大产品的成功如果事后来看,肯定能总结出若干“科学而优秀”的实践,但不能对其中的独特性视而不见,甚至还有无心插柳。。。对大部分人来说,关注采用一些大家都比较认可的方法和实践来将身边"不伟大”的项目和产品做得更成功,这才是更实在的吧。
neo 2019 年 07 月 05 日 11:21 0 回复
戳破了皇帝的新衣! “持续的压力限制了工程师的自由,没有留给他们任何创空间。一些好的项目都是在工程师有空的时候完成的” -- 在我看来,在大的组织,这样的工程师很少。能适应按部就班的环境的工程师大部分不是兴趣驱动来做这份工作的,只是为了钱。
没有更多了