什么是敏捷开发？

快速迭代

就个人而言，好处之一是可以快速发现定位解决问题

精髓是尽早发现偷懒的
达到剥削最大化

老板最喜欢，作为写代码的，我不喜欢。。

目的是把事情分配给靠谱的人干。

不但能及时发现偷懒的，还能发现谁是水货，谁在拖后腿。

加班

精髓是：在保证软件质量的情况下，可以随时改需求和改代码。为了实现这种效果，测试先行、需求拆分、微服务、团队拆分等各种管理模型就都出来了，但目前并没有形成通用的敏捷开发过程模型。
从表面上看，跟国内盛行的“随叫随改”没区别。

比起传统工程来好玩儿

持续集成，持续部署，持续交付。

什么是不敏捷开发

就是快速迭代

就是开发的时候思路跟动作都敏捷一点，然后多加点班，快点把结果弄出来！

大概是指：在 8 小时工作制的情况下，尽可能完成 16 小时或以上的工作量吧
「瞎掰的」

就是经常改需求

规定冲刺时长，固定需求，分配任务，每日站会，冲刺完后总结会。
持续集成测试和持续部署，快速迭代。

边写边改

大概是指：老板觉得要做个东西不知道具体想做什么的时候看你闲着让你做出来他看着改吧。
「瞎掰的」

大概是指：闲开发任务不够重吧。
「瞎掰的」

站会 + 加班，哈哈

先上线，后面慢慢修 bug

我理解的敏捷开发就是分组，快速迭代。将整个项目分成不同模块，不同团队去开发维护，每个月都发布版本，月初分配好不同功能特性对应的开发和测试人员，月末发布版本，每个月都是一个冲刺。确实比百人团队开发一个大项目快多了。

win7 和 win10 的区别

加班开发

@choulinlin 貌似很多小公司学成了这样

@zjsxwc 感觉然并卵啊

@kisnows 我们就这样

@BQsummer 我们做的是需求很稳定的产品，并非互联网产品，感觉成了加班开发

其实是个相对概念，传统的瀑布流是需求分析，概要设计详细设计的流程一步步来的。需求开始就定好了，不能随便改，否则重新走流程。

对于一些传统的项目开发也是能适用的，但是现在互联网开发，产品自己都不知道自己要做什么或者也只是试错，肯定是不合适的。

敏捷开发应时而生，比如对于文档要求上做了简化，但要求即时沟通，互相讨论，比如流程上减少了大的周期，分成小的迭代周期等。

理论是好的，实践也还不错，但是国内很多公司流程不正规，并且以产品为向导等，造成实际敏捷并没有得到很好的实施。

@Drifter 就怕遇到根本都没搞明白，然后就开始模仿的。。。

互联网产品的玩法，发现新需求之后，低成本试错，做了一堆“又不是不能用”的东西出来之后，达到“嘿，还真能用”的地步，就可以融资梭哈了。

传统软件开发这么玩基本就是等死吧您呐。

敏捷开发就是利用一系列方法论和工具，由一个或几个熟悉团队的人带头，把整个团队的效率发挥到最大。
用最有效的方式互通进展，快速协调资源并处理遇到的特殊状况。

加班

这个东西你们先做出来试试，好的话我在用。
目前已做了好几个类似的需求。

刚好今天明天，咨询机构给集团 60 名高管做敏捷思维的培训。学习+练习的方式。虽然我 20 年开发+企业 IT 实践，带过无数个敏捷团队及项目，依然有新的感受。所以，敏捷思维是什么，敏捷开发是什么，绝对不是能简单概括的事。

@netlxl 和随叫随改完全不一样，好么。 每个迭代承诺的 story points 是固定的，要在当前迭代加新任务 /修改，就必须移除多于的部分。而且，如果上一个迭代有遗留（没做完承诺的 story points ），这个迭代最大能承诺的是上个迭代完成的 story ponits。
当然，国内加班加到死那种模式算特例（其实，正常敏捷的话，就算不停加班，承诺的 Story points 也应该遵守这个规则）。
敏捷的前提是团队是自制的（不是没有 PM 或者其它管理者），团队要积极主动，因为任务正常模式下，是开发自己做完了，自己领的。
还有就是，完整的敏捷，是可以自我修复过程中还有流程中存在的问题的。

@daniellu 我特意加了引号。
看楼上那么多回答，那才是真当成了“随叫随改”。敏捷开发因为没有成熟通用的过程还管理模型，所以特别用意被扭曲成“随叫随改”。

我特意去看了 scrum，他是要求主管需求的产品负责人甚至是客户都要跟开发团队一起工作的。我见过的大部分产品经理（尤其是互联网挂口头上的）都是只有人脉和想法，并且完全不懂编码技术。而客户，必定是大爷。这种情况下谈敏捷开发就是耍流氓。

国内谈敏捷的扯蛋的居多, 又没有一个标准的实现, 基本都是处于一个概念, 各自表述的阶段

就是瞎改需求，多加班

敏捷开发在创业公司 多数成为了老板频繁在项目开发周期修改需求,和压缩工期的借口.完全变味了.