在某个问答平台看到一个问题：国内敏捷开发是否是变相压榨劳动力？ 回答里大多对敏捷开发是支持的，只不过在国内的很多企业在只是一味跟风，并没有深入思考过自己是否适合敏捷开发，因而在践行敏捷的过程中，便会出现“伪敏捷”的情况，惹得程序员小哥们怨声载道。
不得不承认，敏捷开发已经成为一种趋势，快速变化的市场环境和严峻的竞争压力，对企业的产品和研发提出新的要求，而敏捷开发恰好可以解决一部分问题（不是全部，没有万能药）。
敏捷作为一种软件开发方法，或者项目管理方法，很容易被说的玄乎，好像不敏捷，就无法搞研发一样，可是，软件开发一定要敏捷才行吗？答案显然是否定的。
传统的软件开发采用的是瀑布式的开发流程，把整个过程分成了业务调研，需求收集，需求分析，方案设计，编码开发、测试、上线发布等阶段，每个阶段都有设定明确的目标和标准，完成之后才能进入下一个阶段，整个过程沿着开始设定的需求文档中的目标方向前进。
瀑布式开发，一来，可以避免资源的无效投入，二来，有效地保证开发质量。
那敏捷是怎样的呢？
敏捷是指一种应对快速变化的需求的软件开发模式，核心是快速迭代，包括Scrum、Kanban、Lean、XP等等一系列的方法。在Scrum Alliance发表的《2018 Scrum行业调查报告》中可以详细了解到，94%的受访者在敏捷实践中采用Scrum，可见Scrum是实践敏捷的主流方式。
Scrum是一个用于开发和维护复杂产品的框架，是一个增量的，迭代的开发过程，目的是让开发人员像打橄榄球一样迅猛并充满激情（……），通过团队合作，提高工作效率，为企业创造价值。
Scrum开发工作包含一个或多个Scrum团队，每个团队由三个Scrum角色组成：产品负责人、Scrum Master和开发团队。产品负责人负责敲定要开发什么、以什么顺序开发。Scrum master人负责指导团队在通用的Scrum框架上建立并遵循自己的过程。开发团队负责确定如何交付产品负责人要求的产品。
在这里着重讲一下PBI的估算，因为在规划和管理产品开发过程中，我们需要回答一些重要的问题，例如，“将要完成多少个故事？”“我们什么时候做完?”，在使用Scrum时，如果在迭代之前，我们不能回答这些我呢提，无法估算产品的工作量大小并测算工作速率，将会出现两种情况，第一，团队成员无法推算产品开发的持续周期有多长，第二，无法按期保质保量的完成交付产品。
第二种情况下，为了顺利按期完成产品交付，只能挤压时间，出现团队成员最不开心的熬夜加班的情况。
可是，在实际实践中，敏捷开发就变成了只有迅猛和激情，一些创业公司或者小团队的“伪敏捷”的开发方式，实际上，这种状况是既不“敏捷”又不“瀑布”，是一种混款或者无序的开发模式。用CMMI成熟度来判断还存在于“初始级”，其软件开发过程是无序的，只管闷头搞开发，不管需求是否正确，前进的方向是否在正确的道路上。
而研发人员感觉敏捷开发是变相压榨劳动力也是源于“伪敏捷”。
