观点：敏捷框架存在很多问题
极客时间编辑部
讲述：闫云龙大小：4.35M时长：04:45
敏捷框架有诸多优点，其敏捷原则也被许多企业推崇与追随，但也有一部分人不太看好敏捷框架。此前，软件工程师、敏捷教练 Yusuf Aytas 发文列出了敏捷框架存在的一些问题，具体如下。
1. 估算。我们该怎么定义它呢？以天、小时、复杂度或者其他一些奇怪的指标来表示？估算其实是有争议的。根据我的经验，估算是不可行的。估算第一次开发一个系统需要多少资源和工作量是不现实的，而且我们从来不会重复开发相同的功能。即使是第二次开发，它们仍然会不一样，因为我们在第一次开发过程中了解了未知的东西。此外，即使你擅长估算，仍然会存在一些干扰因素。
2. 站会。很多时候，你可能对别人在做什么并不感兴趣，所以，开站会可能是在浪费时间。如果你的团队分布在不同的时区，这将成为更大的负担。
3. 产品所有者会阻碍工程师对产品做出贡献，因为他们对产品的关键部分有决策权，留给工程师的空间很少。但要知道，我们今天使用的一些伟大的产品实际上是工程驱动的。
4. 对于每个 Sprint，工程师都被要求完成特定的任务，而业务人员对工程师的要求也越来越高。持续的压力限制了工程师的自由，没有留给他们任何创造空间。一些好的项目都是在工程师有空的时候完成的。
5. 从长远来看，在时间上做限制会导致更多的技术债务。任务一个接一个地来，每个人都在创造新的技术债务，因为我们没有时间进行重构，需要快速交付出东西。
6. 敏捷框架关注的是管理。管理层获得了某种可预测性，他们因此对工程师了解更多，在微管理方面获得了更好的透明度。
7. 敏捷框架假定每个工程师的工作方式都是一样的。团队一起做计划，为任务分配做评估。但是，分配到任务的人可能很难按时完成任务，他可能是团队新来的成员，或者在那个领域没有太多经验。如果要他按时交付，他可能需要承受很大的压力。
8. 敏捷软件开发也有一些很死板的东西。为了完成某个功能，你需要创建一个任务，将其添加到 Sprint Backlog 中，然后对其进行评估，并决定是否要完成这个任务。有些团队甚至更为过分，就连修改一个按钮上的标签也需要重复这个过程。
9. 敏捷框架带来了不必要的复杂性。开发人员可能没有感觉到，但敏捷框架实际上是很复杂的。你可以想想看，一方面，团队里有 Scrum Master，有产品所有者，甚至还有推动者这样的角色。另一方面，还有新的流程，新的术语，等等。如果说敏捷框架很简单，为什么我们要针对这个问题开设大量的课程或培训呢？
10. 敏捷框架最大的缺点之一是需要处理依赖关系。试想一下，如果你需要依赖另一个团队，而他们没有采用敏捷框架，那么你该如何对项目做出评估呢？
11. 敏捷框架对突发事故的应对能力很差。想象一下，在周末的时候你因为一个灾难性事件被叫到公司。你该如何为这类事件做好应对准备？怎么看待这样的事件？怎么记录它们呢？
12. 有些方法在理论上很有效，但在实际当中可能并不是最好的方法。你可以有一些度量方法，但这些度量方法本来也就是与敏捷框架兼容的。因此，度量结果在一定程度上是意料之中的。你可以说有一些团队成功地应用了敏捷框架，但你没有看到更多团队其实没有成功。
13. 一个优秀的团队可能不需要敏捷框架。当团队可以遵循敏捷原则，使用哪种方法真的很重要吗？或许，所有与敏捷框架有关的成功案例之所以成功，是因为团队本来就可以取得成功?
总之，我认为敏捷框架不够好有很多原因。它们提供了有限的好处，但也带来了新的复杂性。作为工程师，我们已经经历了其中的一些问题，并深受其苦。或许，是时候做出改变了。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
该免费文章来自《极客视点》，如需阅读全部文章，
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(2)
- 最新
- 精选
大象
任何一种技术，模式或者框架都必然有其优缺点，不要将某一种东西奉为圣经。2
刘隐林估算，确实是个大问题
收起评论