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

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

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

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