什么是 Agile Software Development（敏捷软件开发）？
他们是怎样的呢？他们认为10个人怀孕一个月就能生出小宝宝。
他们甚至有些连打代码都没做过。但是确实时间、项目管理的砖家。
这就是所谓的敏捷开发的本质：多快好省建设。。。。（水表已拆。
我反正觉得敏捷开发无非就是个概念。
我现在看到的东西是：敏捷开发是项目经理的一种“方法(approach)”。然后下面有各种各样防止你延误工程。时间安排。以及各种各样的“技能(skills)”。（听英文学的不知道有没有错误）
然后我表示。其实就是把经验总结成了知识。但这个有没有灵感，编程快不快不是知识能解决的问题。所以这玩意儿某种程度上就是玄学。反正我学我蛋疼。
人和交互 重于 过程和工具
可以工作的软件 重于 求全责备的文档
客户协作 重于 合同谈判
随时应对变化 重于 循规蹈矩
=================分割线====================
其中位于右边的内容虽然也有其价值，但是左边的内容更为重要。
传统：你想清楚你具体要个啥？敏捷：你再看看还有啥要改的。
当你把属性点加到速度上时你单位时间里可以写更多的代码。
当你把属性点加到敏捷上时你可以更快的转变方向。天朝的软件工程教育只教给大家一种软件生命周期模型，就是大家所熟知的瀑布模型。
真相是，当初提出这个模型，只是为了做个靶子，由此建立了对软件工程的研究。实际上，美利坚国的长期开发实践早已抛弃了瀑布模型。有各种各样的模型，他们都有一个共同特征：迭代。区别，只是不同的迭代规则，不同的迭代周期，不同的驱动力，不同的决策过程而已。
可是他们之中，在天朝流行起来的只有三种。
第一种，叫做极限编程。
第二种，叫做敏捷开发。
第三种，叫做精益开发。
为什么？
因为名字起得好！迎合了天朝老板的心理需求：最大限度压榨员工。加班到极限，释放出你的生理潜能！我心浮气躁，马上就要，你快点给我出东西！不仅要发挥你的潜能，不仅要快，而且要做精品！
精益开发流行比较晚，而且也没有形成气候，因为它本质上缺乏对压榨员工的想象，缺乏对管理者浮躁心态的迎合。
所以，要回答这个问题：敏捷是什么？就不能只回答敏捷在理论上是什么，那个可以自行百度；还得回答：在大量低水平管理者心目中，敏捷就是快，就是天天加班赶快把东西做出来，就是快快快不要停，啊，终于出来了！别人把我们做事的方式称作敏捷。传统的是整个项目我都做完了提交客户，然后有什么意见我再回去改。敏捷是我做出一个相对完整的模块来就给客户看，然后改进。这就是一个迭代周期简单的说，敏捷开发就是
1.迭代中持续交付可用软件
2.在迭代中设立短期目标
3.重构概念课上刚讲过，来答一记~
一、概念
敏捷软件开发：又称敏捷开发，是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。
它们的具体名称、理念、过程、术语都不尽相同，相对于“非敏捷”，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发中人的作用。
二、 敏捷联盟
2001年初，由于许多公司的软件团队陷入了不断增长的过程的泥潭，一批业界专家聚集在一起概括出一些可以让软件开发团队具有快速工作、响应变化能力的价值观和原则。他们称自己为敏捷（Agile）联盟。
敏捷联盟宣言：
我们正通过亲身实践以及帮助他人实践，揭示更好的软件开发方法。通过这项工作，我们认为：
? 个体和交互 胜过 过程和工具
人是获得成功最重要的因素。
一个优秀的团队成员能很好地和他人合作，即合作、沟通以及交互能力要比单纯的编程能力更重要。
合适的工具对成功很重要，但不要过分夸大工具的作用。
团队的构建比环境的构建重要得多。
? 可以工作的软件 胜过 面面俱到的文档
没有文档的软件是一种灾难，但过多的文档比过少的文档更糟糕。
对团队而言，需要编写并维护一份系统原理和结构方面的文档。
? 客户合作 胜过 合同谈判
成功的项目需要有序、频繁的客户反馈。不是依赖于合同或者关于工作的陈述，而是让软件的客户和开发团队密切地在一起工作，并尽量经常提供反馈。
那些为开发团队和客户的协同工作方式提供指导的合同才是最好的合同。
? 响应变化 胜过 遵循计划
响应变化的能力常决定一个软件项目的成败。
计划不能考虑过远。
较好的做计划的策略是：为下两周做详细的计划，为下三个月做初略的计划，再以后就做极为初略的计划。
三、敏捷原则（这是敏捷实践区别于重过程的特征所在）
- 最优先要做的是：通过尽早地、持续地交付有价值的软件来使客户满意。（获取有质量软件的理念）
- 即使到了开发后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。 （关于态度的声明）
- 经常交付可工作的软件，其时间间隔可以是几周到几个月。 交付的时间间隔越短越好。（项目规划的理念，涉及如何处理文档和软件项目开发之间的关系）
- 在整个项目开发期间，业务人员和开发人员必须天天在一起工作。（团队组成和精神问题）
- 不断激励开发人员，开展项目的有关工作。给他们提供 所需要的环境和?支持，并信任他们能够完成所承担的工作。（ “领导”的含义-涉及管理功能）
- 在团队内部，最有效果的、最有效率的传递信息的方法，就是面对面的交谈。（获取开发信息（需求、技术信息和项目信息等）的途径）
- 首要的进度度量标准是工作的软件。（进度度量的理念）
- 敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。（项目“持续发展”的能力）
- 不断关注优秀的技能和设计，增强敏捷能力。（提高敏捷能力的一种途径）
- 简单是根本的。（使未完成的工作最小化的艺术）
- 最好的体系结构、需求和设计，出自自己组织的团队。（团队观念----一种软件项目管理的理念）
- 每隔一段时间，团队对如何才能有效的工作进行反省，然后对自己的行为进行适当的调整。（自我调整和适应）
首先说点历史，随着软件行业的迅猛发展，软件系统的规模越来越大，复杂程度越来越高，开发周期与开发成本失控的问题愈发严重，同时软件的可靠性也无法保证。为解决这一系列问题，软件行业很自然的求助于传统的工程学、管理学方法。“软件工程学” 由此因运而生。
以“瀑布模型”为代表的传统软件开发模型针对软件生命周期的各个阶段提供了一套规范, 以期使工程的进展达到预期的目的。核心强调在软件开发活动中, 所有的活动计划, 日程安排, 交付工作都要直接或间接的和需求保持一致, 同时强调软件需求必须形成“ 文档” 。
这种基于计划的生命周期的软件开发方法曾极大地促进了软件行业的发展，但现如今却愈感“有心无力”。为了适应现代的商业环境与之对应的“敏捷编程”的开发方法提了出来。包括诸如“极限编程”、自适应软件开发和功能驱动开发等。
其他答案已从定义上给予了说明，我就结合敏捷软件开发宣言从商业环境探究这一开发方法的本质与起源。
- 个体和交互 胜过 过程和工具
同时，主张面对面交流和客户参与开发, 弥补了缺少文档而产生信息流通不畅问题, 认为开发人员之间、开发人员和客户之间相互协作、相互信任、彼此尊重是保证沟通成功的必要条件。
背后的商业环境现实就是——开发过程中的人力资本的高企。
一个典型的项目花在人力上的金钱是花在硬件上的时间的20 倍, 这意味着一个项目每年要花2 0 万美元在程序员身上, 而仅仅花10 万美元在电脑设备上。很多聪明的程序员说: “ 我们如此聪明, 发现一种方法可以节省20%的硬件开销” , 然后他们使得源程序大且难懂和难以维护, 他们会说: “ 但是我们节省了20%或者2 万美元每年, 很大的节省” 。但财务事实告诉我们，如果程序简单而且容易扩展, 我们将至少节省10%的人力开销，这将是一笔更大的节省。同时，软件开发的职业本身也决定了数量少但精干的团队的效率与产出大于臃肿、混乱的大团队。敏捷开发一般适用于20-40人、甚至更少。
- 可以工作的软件 胜过 面面俱到的文档
背后的商业环境现实就是——“快鱼吃慢鱼”的竞争模式。
区别于工业社会的利用流水线、规模化的生产模式，信息时代更强调对用户需求的快速响应。标准化生产所带来的低成本、高可靠性的特点不能直接保证市场的高份额。相反，对用户需求的细腻把握和快速响应却是以用户为导向的服务型公司的生命线！
- 客户合作 胜过 合同谈判
背后的商业环境现实就是——用户无法对其自身需求进行有效描述
最经典的例子莫过于苹果的iPad、iPhone了。在乔布斯没有推出iPhone之前，用户是不知道他们需要智能机，更准确地来说就是无法对智能机的需求进行有效描述的。这也就是为什么诸如诺基亚、摩托罗拉等公司失败的原因之一。他们不是没有市场部门，不是没有进行市场调研、用户需求分析，问题在于一般用户在缺乏相关知识与指导的情况下是无法对自身需求（特别是潜在需求）进行有效描述。这一缺陷在市场竞争随着节奏的加快显得愈发致命！
- 响应变化 胜过 遵循计划
背后的商业环境现实就是——试错成本低、执行力要求高
现代社会最重要的特点就是多元化，用所谓的“互联网思维”说就是“去中心化”，具体到个人应该就是 Open mind。这一社会现实反应在软件开发上就是 试错成本变得相当较低。但与此同时，快速变化的商业大环境也对执行力提出了高要求，而执行力的关键指标就是对变化的快速响应！敏捷方法和敏捷是不同的，敏捷是一种方法论，而敏捷方法是把这些理论落地的具体实践
这有点像类和对象的关系。
所以在敏捷的框架下有很多方法，比如XP、Scrum、Crystal等，你也可以根据你自己的理解进行改良和优化。比如在响应变化 胜过 遵循计划这条原则下
Scrum的方法是通过短期sprint和 retrospective 两种实践来达到相应变化的目的，当然你也可能觉得retrospective的方式不一定用会议的方式，那么你完全可以改良它。所以敏捷很大程度上取决于你对它的理解，而不只是生搬硬套的使用它。
最后，很多公司陷入了一种奇怪的循环，似乎是为了敏捷而敏捷，总是刻意的追求方法，在我看来任何方法如果对业务生产和目标如果没有任何帮助，那么它都是失败的。敏捷开发的精髓是开发人员时刻保持沟通，以解决问题为驱动力而不是设计系统，把任务细化到极致，保证每一天，每半天，甚至每一个小时的工作量都能用一个确切的标志来描述。另外还包括很多延伸出来的实践准则，比如保证任意一个时间点，代码都是可以编译的。以前听苹果的软件工程师说过，他们系统每两个小时自动在后台编译一次。当然还需要有自动化工具作为辅助，比如编译失败后会通过代码文件、行数等确定是谁的改动导致编译失败，然后自动在ticketing system里生成ticket，并assign给这个人，等等。既然题主问的是“Agile Methodology”,那么便应该比限定在“软件开发”领域要更加宽泛。本回答从“敏捷开发”出发，尝试解读究竟什么才是“敏捷”。
一、从“敏捷开发”说起
“敏捷”概念的引入最先是从软件开发领域引入的。传统的软件开发采用的是瀑布式开发的流程，把整个开发过程分成了收集需求、定义、设计、编码、测试、发布等阶段，每个阶段设定明确的目标和标准，达成后再进入下一个阶段，整个过程沿着可预测性逐步增加的方向前进，可以避免资源的无效投入，并有效地保证开发质量。
但问题在于瀑布式开发这种预定义过程的方法，每个阶段之间都有强烈的依赖关系，前一个阶段被视为后一个阶段的输入，如果输入质量不高，便会严重影响后续阶段的输出质量。同时，如果前一个阶段未能达到标准，也会造成后续阶段的停滞，导致开发周期拉长。并且，项目早期即作出承诺导致对后期需求的变化难以调整，代价高昂。
所以敏捷开发就是在提出这样一个问题的背景下所诞生的。有数据显示有70%采用瀑布式开发方法的软件开发项目均已失败告终。原因便在于，市场的需求瞬息万变，很难实现产品需求的明确且完整地收集；同时，技术的发展也日新月异，对于所定义功能的可实现性也面临着多重不确定性的因素。所以当需求收集和产品定义工作无法得到很好地完成，瀑布式开发方法自然无法摆脱高失败率的命运。
所以从需求的明确性和工程实现的确定性两个纬度出发，当需求的不明确性和工程实现的不确定性均超出一定范围之后，呈现出复杂系统（Complex System）的特征，瀑布式开发这种结构化的开发方法便不再实用。而敏捷开发方法正是在这样的背景下诞生。
敏捷开发的一个核心思维模式的转换便是：从瀑布式开发所代表的“Fix Scope, Flex time”（固定范围，弹性时间）转向“Fix time, Flex Scope”——固定时间，弹性范围。 在市场变化和技术变化的背景之下，既然市场需求和产品定义所代表的“范围”无法实现固化，因而无法确定应该投入多少资源来完成，那不妨固定好已有资源的，以资源为约束，实现“范围”的最大化实现。因此从“计划驱动”转向为“价值驱动”。
而在敏捷开发的思维模式提出后，一方面诞生了“个体与交互胜过过程与工具”、“可以工作的软件胜过面面俱到的文档”、“客户协作胜过合同谈判”、“响应变化胜过遵循计划”这样的代表敏捷价值观的“敏捷宣言”，充分发挥“人”作为代码编写者在软件开发过程中的价值。
同时在敏捷宣言的指引之下也产生了多种多样的敏捷开发方法，如冲刺和迭代式的“Scrum”方法，更进一步通过具体的实施手段展现“敏捷宣言”所代表的敏捷价值观。
从“敏捷开发”可以看出，敏捷不仅仅简单只是一个形容词，更代表了一种方法，那么究竟什么才是“敏捷”呢？
1. Complex System Context 以“复杂系统”为背景
敏捷并不是一个普世的方法，而是具有一定语境和背景的，如同敏捷开发的诞生，也是在市场瞬息万变和技术日新月异的背景之下而产生的。
“敏捷典型”是以“复杂系统”为背景。作为一种方法，最终都是被“人”所采纳并实施。而人对于世界的认知和理解始终朝着减少未知“Unknown”和不确定性“Uncertainty”两个方向前进，对于未知需要逐步理解（Understandable），而对于不确定性，通常是提前预测，通过反馈，来获得判断（Predictable）。因此可理解和可预测也成了人认知世界的两个纬度。
但无论科学技术如何进步，对世界的很多事物已经达到可理解、可预测的地步，但依然还存在非常多的不可理解或不可预测的事物。特别是每个人的认知能力也存在差异，相同的事物对某些具有足够认知能力的人来说是可理解、可预测的，但如果认知能力不足，便会出现既无法理解、也无法预测这样的“混乱系统”（Chaotic）。
而复杂系统（Complex）也是同样，当相对于人的认知而言，对可理解性和可预测性均提出一定高度的要求，便呈现出复杂系统的特征。如同敏捷开发所产生时的背景，市场瞬息万变，需求变得不可预测；技术日新月异，对某些需求的技术可实现性也变得越来越难以理解。但这种不可理解性和不可预测性并没有远远超出人的认知潜能的范围，没有到达彻底混乱的地步；同时，通过过程中不断地反馈和学习，也可以逐渐消除未知和不确定。因此，对于这样的复杂系统，运用敏捷方法，将可以更好地获得对系统的理解和预测。
2. Human-Driven 以人为核心驱动
敏捷的另一个特征是“以人为核心驱动”——Human Driven。
对于适用敏捷方法而言，其最终的目的是为了理解所处的复杂系统，激发复杂系统所具有的能量。更强调“系统”对于“人”的价值，而非单纯地承认其“复杂”的特征。
同时复杂系统又是一个相对的概念，是相对于人的认知能力而言。而对于复杂系统，其认知的过程依然会沿着“可理解”“可预测”两个方向发展，这其中“人”将扮演主要的角色，需要充分挖掘“人”的潜能。
无论对“目的”而言，还是“过程”而言，在运用“敏捷”方法时，“人”都是认知和运转“复杂系统”过程中的核心驱动力。
所以这也对运用“敏捷”方法的“人”提出要求，需要思维模式和价值观的支撑，才能真正理解并运用“敏捷”方法。在《管理3.0》一书中，作者Jurgen Appelo给出了一个具有六只眼睛的异形生物，并取名为“Martie”，代表了运用“敏捷”方法的人应该所具备的六种思维模式：
- Energize People 有效激励
- Empower Teams 赋能团队
- Align Constraints 调和约束
- Develop Competence 发展能力
- Grow Structure 结构成长
- Improve Everything 全面改善
3. Adaptive Empirical Process Control 具有适应能力的经验性过程控制
“敏捷”的第三个特征便是：“敏捷”实际上是一种经验性的过程控制方法。作为一种方法，通常都具有一定的目的性，而为了达成目的，势必要实施一定的过程控制，才能提升达成目标的几率。而在“复杂系统”的背景之下，“瀑布式开发”所代表的预定义过程控制（Predefined Process Control）已不再适合，而以人为核心驱动的经验性过程控制（Empirical Process Control）将具有更高的适应性和灵活性，同时也能充分发挥“人”的潜能和价值。
人类在进化过程以及认知、改造世界的过程中始终都面临着各种“未知”（Unknown）和“不确定”（Uncertainty），所以人类的历史天然就是一个“敏捷”的过程。
让我们借助一部经典动画片《疯狂原始人》中的人物和场景，来更好地表达“敏捷”这样一个经验性过程控制方法需要遵循哪些原则。
Rule1:适应性原则。Keep Relevant-时刻保持与背景“复杂系统”的关联，适应“复杂系统”的变化。
Rule2: 灵活性原则。Always be optional-拥有多重选项，根据环境的变化进行灵活选择。
Rule3: 利用系统的“原力”——Leverage the Gravity。人的力量毕竟微弱，需要充分挖掘“复杂系统”自有的力量并加以利用。
Rule4: 模式识别——Patterns Recognition。识别“复杂系统”中所呈现出的“模式”，基于“模式”，逐步理解“复杂系统”。
Rule5: “自下而上”原则（Bottom-up）。由于“复杂系统”的未知性和不确定性，在缺乏必要信息的情况下，无法通过“自上而下”（Top-down）的方式来理解系统。因此，从基本的“模式”出发，并在过程中学习和认知，不断地向上发展更高层的“模式”，才能最终实现对“复杂系统”的全面认知。
三、总结
所以，“敏捷”（Agile）代表的是一种方法，是在“以人为核心驱动”（Human-Driven）的“复杂系统”（Complex System）背景下，一个具有适应性的“经验性过程控制方法” （Adaptive Empirical Process Control）。
了解了什么是“敏捷”之后，你对具体什么是“敏捷销售”是否更加期待？
敬请持续关注「敏捷销售」！
http://weixin.qq.com/r/HDkcBNnEnITjrZ1n92wO (二维码自动识别)
作者：Waterwalker
链接：什么是敏捷？ - 敏捷销售 - 知乎专栏
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。人是一种需要持续能看到行动的正反馈的动物，只有持续地有正反馈人才能坚持重复一个过程。嗑瓜子就是持续有正反馈，长期学习计划之所以很难坚持也是因为没有足够快的正反馈
敏捷编程就是想办法制造尽可能快的正反馈给程序员，这样他们不至于很快疲掉，以至于没有人想继续工作在这个项目上了我觉得是，如果你要开发一个软件，软件要实现很多功能，在第一个几周里，你能主要实现第一个功能的开发测试，成功后，第二个几周里，再实现第二个功能的开发测试，再来个集成测试。以此类推。总而言之，就是把一个大的软件开发周期时间分割成很多小份时间，每一个时间段内又是一个完整开发周期。这是我的理解，也许还有错误，请大家多多指正。承认不可能一次设计好 不如一点点改好
什么是敏捷软件开发?
敏捷软件开发是一个概念意义上的框架，用来取代软件工程项目的概念;它强调在项目的整个生命周期中，拥抱并促进由于软件进化式的发展所带来的变化。
在项目的整个生命周期中：这就涉及到了【敏捷项目管理】、【敏捷需求获取】、狭义的【敏捷软件开发】三个主要的领域和过程。要注意的是，上述三个过程并不是互相分开的，而是你中有我，我中有你。
拥抱并促进变化：世界上唯一不变的是变化。不论在任何领域，漠视、甚至否认、抗拒变化，都不是一个理性，严肃的人所应有的态度。学会如何识别变化的大势，并在可能的时候，促使变化向好的方向发展。这才是面对变化的正确应对之法。
软件进化式的发展：虽然上面提到促进变化的发展，但是软件的演化过程，我相信是有其自身内在逻辑的，存在一些根本规律和指导方针;并不是完全以人的主观意识为主导。
老子讲“顺势而为，无为无不为”，我认为是对上述后两点的精确概括与指导。
了解更多详情：ACP敏捷介绍
在做一个来自加拿大的教授的作业的时候搜到了这个问题，敏捷开发更注重代码。
而传统的开发过程更加注重文档，是面向过程的，好像文档写好了说明我这一步确实做好了。基于北美背景，主要是因为程序员会频繁的更换工作，在一个公司待一两年就换地儿，新来的只要看文档就可以了解到这个公司在做什么，做到哪个阶段了。
而敏捷开发废弃了传统的无尽无止的文档，文档写不写都是可以的，唯一的要求就是产品做的好，是面向产品的。而且可调整性很高，不需要等一个产品的所有功能都实现了才能发布，只要把能盈利的功能做完了，通过测试就可以发布第一个版本，后面的功能按照优先顺序接着做，做好了再更新。一个功能可能在预先设想的时候是有的，等前面的几个功能做完了发现这个功能不需要了，Ok,弃掉。或者在开发过程中发现了新的很必要的功能，那做完手头这个就做这个新的。
但是这就要求high skilled 和high motivated的员工。
关于团队管理，要求team leader作为领队人而不是管理者，团队每个人都平等但是项目负责人比重更大，共同做出决定，每个人在自己的领域发声，但是这并不代表这个团队无组织无纪律。
项目负责人需要找到合适的团队成员，阐述产品的愿景，并且鼓励大家，保持大家的积极性。虽然开发过程是可调整的，但是负责人要保证这个产品不能完全跑偏。
Agile是一种套原则和价值观，本身并不是敏捷开发。Agile由几个从事软件开发的大牛于2001年提出，共4个价值观和12条原则，目标是为了提高软件的交付速度。
但Agile本身不是敏捷开发，敏捷开发的几个实施方法只是符合了Agile的价值观，现在主流的敏捷开发方法有：
- Scrum
- 看板
- Lean
- XP
- DSDM
- Crystal
- FDD
举个例子，Agile相当于武功高手推崇的原则和价值观：练舞是为了强身健体、锄强扶弱，不能欺负好人.....
而敏捷开发就是各类门派：武当派、少林派、峨眉派、昆仑派.....
如果你还是不明白，可以观看下方的视频，介绍了Agile和敏捷软件开发的关系。
https://www.zhihu.com/video/967052312400887808另外，欢迎订阅来自明道的更多敏捷开发内容。
成为敏捷开发大师
