敏捷测试流程，2 周一迭代，比传统的好太多了。关键是要自动化测试和功能测试配合并进才效果更好。

看项目和资源。给资源，让我做啥就做啥。
说实话，部分项目两者表现并没啥区别。有时候先天条件不行，搞敏捷就是个负担。

三周一个迭代，敏捷，就是有时候需求不明确，开会的时间都没有

小公司哪有那么多人力去搞自动化 维护测试用例，点点点得了

看业务情况，一般 1-2 周一个迭代，最长的不超过 2 周。迭代过程基本也和楼主说的瀑布差不多，不过这个我理解是个软件开发流程都得这么走吧，顺序大部分情况下无法调整，因为相互依赖。

另外，不知道楼主这里提的敏捷，和这里提的传统瀑布有啥差别？
敏捷的具体落地不同公司有很多不同差异的，有的地方小型瀑布（就是需求拆到 1 周内能搞完的粒度）也会认为是敏捷。

产品（项目领导）说让我们先看看敏捷年后考虑搞。我感觉就是产品省得写文档了，因为 “工作软件胜过全面的文档”，产品一句话开发直接开搞。并且 “响应变化胜过遵循计划”，那就开发改完直接上线。
这两种我感觉做起来都是貌似快了，但项目必定会引入混乱，还不如正常瀑布流。

是啊，就那几个人，还想搞各种流程，不是折腾吗

大佬的敏捷流程跟传统瀑布有啥区别呀

是这样，我们现在简单瀑布都搞不明白就搞敏捷，我感觉还不够出问题的

敏捷不是靠开会了解需求吗，不开会怎么定需求啊

如果你们的敏捷=不写文档和开发完直接上线，这是敏捷的典型反面教材。这玩意不叫敏捷，叫乱来。。。

工作软件胜过全面的文档 != 只要软件不要文档
响应变化胜过遵循计划 != 只要响应不要计划

人家说这句话的场景是当时大部分用的都是最传统的瀑布流，文档要写得差不多有代码那么详细（你找个政府类项目的完整文档看看就知道了，需求说明、概要设计、详细设计，每份文档都是几十页甚至过百页的文档，像写论文一样），计划一排就是排好几周而且中间不能随便变，所以才说这两句呼吁大家不要舍本逐末。你上面说的这个明显就是矫枉过正了。

也可以看看这篇文章，里面提及了几个常见的敏捷理解误区：https://www.scrumcn.com/agile/scrum/4074.html

文章看了，受益良多，多谢恒捷大佬~

一周两迭代，saas 看客户时间上线，挺难受的

是传统瀑布（就是需求评审 - 开发（同时写用例）- 接口测试 - 测试），还是敏捷啊？

无论瀑布还是敏捷，都是这个流程，因为确实有先后顺序（难道还能不出需求就开发吗？难道还能没开发出东西就测试吗 ），个人理解核心区别在于每个阶段的时长，以及每个阶段具体包含的要素。

【以下个人理解，可能不对】
瀑布模型相对久远了，现在估计很传统的软件开发（传统 toB）或许还在用，它强调的是单产品单时间只有一个版本或很少的版本分支，后面的阶段要等前面的阶段完全结束，每个阶段要有十分完备的书面文档。在当年硬件资源匮乏，发布难度高，客户关系比较稳固，客户对交付日期要求比较松的大背景下，会有一定的科学价值。

敏捷上，网络资料更多，应该没有 toC 的公司不走敏捷模式，只是标准和不标准的区别。与瀑布最大的区别就是发布时间更短，每次发布带更少的特性，强调快速发布试错、拿到时长反馈、迅速迭代特性，这个方法论与现在公司竞争用户市场的局面下显得很适用，具体理念 11 楼 贴的链接已经说明得很清晰了。

另外，流程建设是要分阶段的，人少产品小的情况下就应该轻量高效，因为人少就不会存在严重沟通 gap，有啥事你在工位吼一声大家都知道，这个场合下强调敏捷，要不就是领导者希望团队提前建设相关氛围方便后面扩张人员，要不就是领导者单纯想实践一下这种模式。case by case，适合才是最好的。

我理解我们的目前属于半敏捷，在研测流程上配合还做不到敏捷，有周更版本和月版本形式