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

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

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

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

创作场景

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