极客观点
项目管理
HarmonyOS
能否根据你用敏捷开发的经验简要的说下敏捷开发。
谈谈你自己的理解即可。几句话，几段话，都可。
我知道这不是编程语言，我只是想了解大家在项目中用到敏捷开发时候，对其的理解。
敏捷是针对项目而言的， 而不是编程。所以在这里问没有意义
另外想补充的是，segmentfault这里基本都是轻语言，新语言技术流派，敏捷恐怕是彻底融在代码魂中的。浸淫其中的人更需要的是戒骄戒躁的提议。
而对敏捷特别有感悟的应该是win流派里做传统软件项目的传统程序员。从他们的缓慢的工作流程，庞大的工作团队，还有古老的编码习惯。最需要敏捷的就是这群人了。从毛孔里会怒喊，但是因为确实是太庞大了，喊了也没用。。被压制死了成习惯了。
只有过体验这两方面差异比较的人才会对敏捷有更多感触。也只有在那群老派的人群中敏捷才有被放大的意义，仅供参考
有人说这是某种思想，有人说这是某名字和古董OS一样的实践，又有人说这是另一些实践
我讨厌这种暧昧不清的词
我只认为并相信
a)高效的团队开发有必要遵循某种方法/流程
b)方法/流程是随时都可以优化而且应该不断优化的
- 敏捷是适合自己团队开发的一套管理办法，拥有每个团队独特的开发风格和管理理念（比如：咖啡馆工作，娱乐式办公／休闲式解决讨论问题),切记不能一概而论，复制别人的（那些***未必适合你），我们只能吸收和借鉴。
- 敏捷开发是流程的标准化，有章有序且高效简捷
- 敏捷开发是迭代开发，并且要求迭代周期不要太长（1周／2周最佳）
- 敏捷开发是思想，要求我们模块化集成开发项目，高度可用
- 敏捷是团队，协调和高效是我们追求的极致
- 敏捷是开放的，自由的，每个人随时随地可以把自己想到的／疑问的写在白板上或说给大家听
if it 's pain ,do it often 。再困难的事，放到每一天进步，就会更加容易搞定。对于管理者来说，痛苦在于进度的把控。而每日例会和Demo，让这样的感受不那么难过。
前段时间看到了敏捷宣言的作者写的一篇文章，中心思想是说敏捷从来都不应该是一个名词，而应该是形容词。文中还提到，那些把敏捷变成一个名词，变成一种方法论的人从一开始就搞错了敏捷的意思，但是可以理解他们，因为他们从心底只是想把这个概念炒作成可以用来赚钱的工具，也就是那些所谓的“敏捷咨询师”们。
这是什么意思呢？
核心的思想就是四个字：拥抱变化。所谓拥抱变化就是不要墨守成规，不要用一种方法／模式来处理所有的项目／工作，套用一句中国老话来形容敏捷的特色就是：兵无常势，水无常形——你看，这不是什么新鲜玩意，我们的老祖宗早就总结的很精妙了。
一个团队是否敏捷，不在于他们是否使用了特定的工具／流程／语言／方法／甚至……姿势（=_=），而在于他们是否有能力快速的适应和应对变化，只要能够做到很好的完成既定的目标并且还能留有余地，随时能够游刃有余的应对可能发生的变化，那么无论他们用什么方法，都可以说是敏捷的。
一些特定的工具／技巧总是被打上敏捷的标签，并非因为它们只为敏捷而生，而是因为它们的好处有利于达到敏捷的目的，也就是快速的适应和应对变化。比如说 TDD，它的终极意义和价值在于为你的代码逻辑建立了一个“保护边界”，并且可以按照你的需要调整这个边界的弹性。于是，一旦初始的代码逻辑发生了变化，或者需要用另外一种方法进行重构，你不必担心由此引发的 Bug 或者是和其他代码交互产生的无法预期的行为。因为无论代码如何实现，它应该做什么已经是有了测试的；当然，这个测试够不够健壮，有没有漏洞等等就要看编写的人的水平以及他自身对应有逻辑的理解程度了。从另外一个角度来说，维护测试本身就是一种代价，这个代价是否值得？基本上取决于项目的性质。一般来说，稍微上点规模的项目，测试绝对是值得的。但是很多团队和公司经常做的都是以一锤子买卖（你懂的），所以没有测试也是可以接受的。从这个角度来看，测试或者不测试完全和敏捷无关，但是选择本身却可以秉持敏捷的观念。
在某些情形下，TDD 也不是万能灵药，甚至会显得多余。那么，能够因此说敏捷是不好的甚至是错误的吗？当然不能！因为敏捷从来都不是什么方法论，它并非崇尚一套“放之四海而皆准”的万能方法。如果你惯用的工具和方法忽然不管用了，而你对此毫无准备，也没有其他的解决方案。这就是一个信号：说明你（在这方面）已经不怎么敏捷了，你得赶紧随机应变。
我还可以举出很多实际的例子来对比敏捷和非敏捷的人／团队／思想，但是我想改掉啰嗦的习惯，这背后真实的原因是：有些人天生就是敏捷的，你根本就不需要教；反之另外一种人，你无论如何跟他讲都是徒劳。这一点恰恰体现了我一开始想要表达的意思：决定敏捷的不是方法，而是人。如果你能，那么你看完第一段话就足够明白了；如果你不能，讲再多还是一样，大家都省省心，自己觉得怎么舒服就怎么来吧。