有的公司的研发总监或经理就是有那么个 title，跟傻逼一样，就不知道怎么管理，为了舔领导天天搞什么敏捷，开发出一堆 bug，测试要时间不给，经常倒排期，越快上线越好，最后线上出问题都埋怨测试。

假敏捷是没有办法的事情，假敏捷的普遍现象是：持续集成、转测质量差、开发无自测、团队整体无质量保证思想、质量是测试的事情、测试无话语权、软件只为本次不为未来...
本现象更多的体现在做项目的公司或团队内，开发思想只为交付不为迭代，凑合能用就行，质量是个什么东西

我以前公司搞敏捷开发。对质量的要求就是主要的功能流程没问题就好。细节问题上线慢慢修~

做 B 端产品的各大公司的确广泛存在这种情况，C 端倒还好一点

大部分团队压根没有对敏捷做深刻理解，把敏捷的快速交付目的当成了手段，闭口不提研发质量。你和他说要产品文档，要开发自测，他们会说：咱们不是提倡敏捷吗，统统省了，结果可想而知

敏捷开发各个阶段的 DOD 要做好！完成标准要明确！

产品的 DOD
研发的 DOD
测试的 DOD

各个阶段的准入准出要按照规则来，这样才是真敏捷！！

要是把控不住，就找敏捷教练！！

敏捷就允许 bug 存在啊，边做边上线，发现 bug 就修

先学会甩锅，再学会背锅

测试除了已知测试场景的漏测，其它情况下都不太应该被认定为线上故障的第一责任人，第一责任人应该是 PO、TL，敏捷项目下面主 PO 或者 TL 需要对项目整体交付负责，而不是靠测试兜底，有些公司确实会有这种情况，如果没法纠正过来，选择离开其实也挺好。

拒绝假敏捷，是兄弟就来砍我。

真敏捷了，生产事故第一责任人就不可能只是测试。

你们这种如果恶性循环了，是团队的问题。意识和认知的问题不解决，会一直这样的。

我感觉已经出现的生产问题还是要复盘下，出现原因不同 应对措施也不一样。
举个例子，因为时间压缩导致有一半的测试点没有时间执行：测试前先确认好必须要过的主流程测试点，测试解阶段重点测核心场景。交付之前要拉齐多方对齐，说明哪些测试点没有测到，其可能造成的影响范围。暗示要么给多点时间，要么接受带问题上线。
如果产研坚持要上，我会在测试报告里一一列出这些风险点，也说明多方对齐的结论（产品要上的啊，出问题找他 ）及上线后的注意事项。

正如楼上所说，这整个流程问题都太多了，如果氛围很难改变就跑吧

敏捷研发模式表示不背这个锅。。因为敏捷本身没有问题，有问题的是落地过程中，大家只关注了 “快”，而忽略了人。

“给到业务测试的时间，根本就不够” 可以尝试引入部分的自动化测试手段来提升效率，或者加入一些小工具。时间一直都是不够的。

“又加上开发不自测”，这事吧，做好测试准入条件的设置。敏捷中不也有 DOD 的理念么。

“经常背锅，挨骂，背低绩效” 这个没啥好说的，不同团队对质量的关注度不一样，所以可能的话，还是远离这类团队吧，因为三观不同，你做啥都是错的。

综上，换个环境吧，可能对你会更好些。测试人也需要有选择团队的能力。

背锅肯定是很常见的，但只背 该背的锅；