一篇文章讲清楚 Agile Software Development（敏捷软件开发），以及分享一个完整的敏捷知识库（文末）。
敏捷软件开发是基于敏捷宣言定义的价值观和原则的一系列方法和实践的总称。自组织、跨职能团队运用适合他们自身环境的实践进行演进得出解决方案。
敏捷不是指某一种具体的方法论、过程或框架，而是一组价值观和原则。符合敏捷价值观和原则的开发方法包括：极限编程（XP），Scrum，精益软件开发（Lean Software Development），动态系统开发方法（DSDM），特征驱动开发（Feature Driver Development），水晶开发（Crystal Clear）等等。
20世纪50年代-美国国防部（DOD）和美国航空航天局（NASA）开始采用迭代式的增量方法（IID）。
20世纪60年代-科技的发展，制造业岗位的消减，”知识工人“产生，旧模式不再凑效，生产工具在人的头脑里，旧式的方法被提倡信息共享和劝导的新方法代替。
20世纪60年代-Thomas Gilb提出演化项目管理的概念（EVO方法）。
1970年-Winston Royce发表文章《Managing the development of large systems》阐述瀑布方法的概念，并注解说明：“是危险的的并且可能导致失败”的原因， 因为它将测试放到了最后。
1986年-Tankeuchi和Nonaka发表白皮书《The New New Product Development Game》讨论了Scrum方法。
2001年2月，Martin Fowler，Jim Highsmith等17位著名的软件开发专家齐聚在美国犹他州雪鸟滑雪圣地，举行了一次敏捷方法发起者和实践者的聚会。在这次会议上面，他们正式提出了Agile(敏捷开发)这个概念，并共同签署了《敏捷宣言》。
敏捷是项目管理和软件开发的一种迭代方法，可帮助团队更快地向客户，交付价，减少麻烦。敏捷团队不是把所有事情都押在“大爆炸”的发布上，而是以小的但可消耗的增量交付工作。需求、计划和结果会得到持续评估，因此团队拥有快速响应变化的机制。
敏捷是基于价值驱动交付，项目团队要频繁的且尽快的给客户交付可以使用的产品，并尽早的让让产品投入市场可以尽早的验证其商业模式和商业价值，这是敏捷提倡的核心价值之一。
敏捷提倡优先交付高价值、高风险的需求，然后交付高价值、低风险的需求、再交付低价值、高风险、最后低价值、低风险的需求。这样的好处是把最高风险的需求在项目的初期就开始做，可以最早发现该产品是否可行（通常只要1~4周）。如果因为市场、技术或者其它原因失败了，可以及时停止该项目，降低项目风险。即使这个项目失败了，这个失败的代价相对来说小一些。
在VUCA 迭代开发的后期也接受变更。因为市场在变化，用户的期望和要求在变化，客户的需求也会随着这些因素的变化而变化，只有及时响应这些变化，并尽快予以实施，才能帮助客户在瞬息万变的市场中保证竞争力和吸引力。而敏捷能够帮助团队在小步快跑的过程中能够快速的响应变化。
敏捷提倡高频率的交付有价值的产品。每天的例会、迭代计划会议、迭代评审会、迭代回顾会议都在对可交付成果质量上进行层层把关，因为在这几个会议中会频繁讨论遇到的问题/解决方案，验收标准，DoD等等。同时，也会邀请项目干系人参加迭代评审会并对可交付成果验收和反馈，这样团队可以及时予以调整，以确保质量。
敏捷提倡不断调整和优化，并在每个迭代的迭代回顾会议进行分析、讨论、总结敏捷当前迭代开发过程中需要改进或者要提升的地方，进而在下个迭代中改进、调整和优化。这是整个团队成员不断学习，不断提升自己经验、技能的一个很好的机会。另外，因为敏捷强调客户参与的重要性，对于客户的反馈意见和建议，开发团队也会及时给与相应以及反馈，让双方可以更好的合作，建立更加信任的合作关系。
敏捷提倡尽早和频繁的为客户交付有价值的产品，以确保更高的质量，更高的成功率，为客户尽早带来商业投资回报率的机会。
敏捷提倡仆人式的领导，SM需要给团队工作上的指导、帮助和支持，扫除团队成员工作上遇到的问题和障碍。重视并尊重团队成员的想法和意见，授权团队并引导团队成员自组织和自管理。更重要的是，团队成员可以决定要做什么、怎么做、什么时候做，并自己监控和管理工作进展，对结果负责；团队成员可以一起讨论并确认工作协议，确保考虑并接纳每个人的意见；团队成员可以一起评估故事点；同时，SM要引导团队成员之间相互协作并促进合作。通过这些，团队成员可以更高效的工作，交付的质量也会提高，团队成员的满意度也会大大提高，A happy employee is a productive employee，不是吗？
敏捷基于价值驱动，它的项目范围是可以灵活调整的，这就给项目干系人很多的灵活性来根据市场不断调整需求范围、变更以及优先级等等。另外，敏捷提倡频率与团队和客户沟通交流，并不断根据反馈和意见调整管理方法、需求流程、开发流程以及运维流程等等。还有，验收标准，DoD都可以根据实际情况进行调整。
当然敏捷还有很多其它的优点，比如透明、简洁、高效，更早进入开发等等，在这里就不一一介绍了。
尽管敏捷带来了很多改善，但是再次重申它并不是适合所有人和所有情况的。因此，了解敏捷的不足显得特别重要。知道这点后，你心理上是准备好的并且会根据具体情况来做裁剪和优化来规避或减少负面影响。
由于敏捷团队不是一开始就知道产品“最终的样子”，而是在过程中探索用户的需求逐渐知道产品真正的终局状态，这样一来就给前期的规划（成本，时间，资源）带来了很大的挑战（项目越大越复杂这一点变动更加明细）。
。整个项目用于产品开发的文档不是一开始准备好的（甚至都没有RP原型设计），而是在过程中”及时的“ just-in-time准备出来的。因此，我们看到的是非常简单的且常常被放在最后处理的文档（在项目中涉及到移交或问题分析时这一点显得尤其突出）
增量交付可能有助于更快地将产品推向市场，但这也是敏捷方法论的一大缺点。因为当团队在不同的周期内对各个组件进行开发时，整体的输出往往会变得非常零散，而不是一个内部紧密集合的整体。（当项目对UI和UX有更高的要求时，这个挑战就变得更加明显）。
敏捷在一开始要求最低限度的规划，这使得交付新的、意想不到的功能时很容易偏离方向。此外，这意味着项目没有限定的终点，因为从来没有一个明确的 最终的产品样子。
由于敏捷是以增量的方式交付的，所以跟踪进度需要你跨周期地看。而 边走边看 的特性意味着你不能在项目开始时设置很多KPI。这种长期的游戏使得衡量进度变得相对困难。
瀑布模型式是最典型的预见性的方法，严格遵循预先计划的需求、分析、设计、编码、测试的步骤顺序进行。步骤成果作为衡量进度的方法，例如需求规格，设计文档，测试计划和代码审阅等等。
瀑布式的主要的问题是它的严格分级导致的自由度降低，项目早期即作出承诺导致对后期需求的变化难以调整，代价高昂。瀑布式方法在需求不明并且在项目进行过程中可能变化的情况下基本是不可行的。
目前来说2B的传统企业，包括ERP，MES，WMS，CRM，OA，IBMS等系统当中可以经常见到他们的影子。现在这种模式仍然流行在一些大的项目或者是外包的一些项目当中。
需求隔离：由于各阶段的人员只能接触到自己工作范围内的东西，所以对客户需求的理解程度高低不等，开发人员更像是定义为流水线上的工人。
变更代价大：既然叫做瀑布，就意味着不应该走回头路。否则如果出现返工，付出的代价会很大。需求变更，编码人员会很强的抵触情绪。
束缚创造性：由于强调文档管理，所以管理人员会比较喜欢，但是他束缚了开发人员的创造性。
周期漫长：整个开发持续的生命周期很长，需求和设计的时间会耗费特别多，有时候会占用三分之一甚至更多时间，这样整个周期就会变长，大都在半年到一年左右的时间，所以更适合需求相对稳定的大项目。
两者都有自己适用的范围，而当下这个VUCA的时代，大部分项目可能都适合用敏捷开发，但仍旧有一部分确定性很强的项目会适合适用瀑布开发。
因为移动互联网的飞速发展，基本上所有的行业要想在这个时代保持竞争力并赢得市场，都需要和互联网扯上关系，因此诞生了很多的项目，有项目就需要有人来管理，那项目管理离不开方法，那敏捷无疑是当下最好的选择了（“感觉说敏捷就是为互联网而生的并不为过”）。
敏捷方法论更符合当前这个时代的发展需求, 它可以更好、更快、更简单、更有效的应对VUCA时代，并且可以让SM/PM更加从容、淡定、自信来管理项目，并提高项目交付的成功率。
认为不行，自然是因为尝试过，然后失败了，便觉得敏捷项目管理不行。关于为什么会失败，国外资深敏捷教练在深入调查后在《Scrum在亚洲难以实行》一文中总结了四点原因，个人觉得是比较到位的：
除了以上四点原因，其实还有诸如对开发团队的人员素质要求比较高等很多因素。
不可否认，敏捷在国内的落地过程中有种种阻碍，但这并不表示敏捷思想本身存在问题。
因为敏捷软件开发的核心思想之一就是：通过自组织、跨职能团队运用适合他们自身环境的实践进行演进得出解决方案。这也就意味着敏捷并没有固定的规章制度和流程，团队要根据自身环境的实践演进出属于自己的敏捷项目管理方法。
我们也能看到，近些年敏捷项目管理在国内的热度持续攀升，BAT等诸多一线大厂普遍采用，敏捷项目管理所带来的价值和优点被越来越多的团队发现。
敏捷从国外传入国内，由于滋生土壤不一样，必然有一个适应完善的过程，逐渐发展出适合国内环境的敏捷项目管理模式。
实施Scrum 就一定要用专业的Scrum 管理系统吗？答案当然是不一定。
如果团队在25人以下，由于规模小信息差不大，流程简单，很多事情拉个会议，使用一般的白板或者是在线文档就能满足需求，这个时候上工具有时候反而会给团队的效率造成阻碍。
但是当敏捷成为超过百人团队，或进行大型项目的主流开发方式时，这些自己临时组织起来的技术团队，或者是在跨团队之间，以及日常管理多个团队，如仅靠白板、电子表格和Wiki 等将难以满足需求。
如果大家要选择一款工具来学习敏捷，国内比较推荐的是PingCode（这也是国内最标准敏捷开发管理工具）。
传统的是整个项目我都做完了提交客户，然后有什么意见我再回去改。敏捷是我做出一个相对完整的模块来就给客户看，然后改进。这就是一个迭代周期
Agile是一种套原则和价值观，本身并不是敏捷开发。Agile由几个从事软件开发的大牛于2001年提出，共4个价值观和12条原则，目标是为了提高软件的交付速度。
但Agile本身不是敏捷开发，敏捷开发的几个实施方法只是符合了Agile的价值观，现在主流的敏捷开发方法有：
举个例子，Agile相当于武功高手推崇的原则和价值观：练舞是为了强身健体、锄强扶弱，不能欺负好人.....
如果你还是不明白，可以观看下方的视频，介绍了Agile和敏捷软件开发的关系。
敏捷开发模式是现代软件开发的通用模式，据统计从2018年开始，有90%以上的软件开发都采用敏捷开发模式。先不讨论敏捷开发模式与瀑布开发模式优劣，就当前数据统计以及各大公司的转型结果来说，特别是连SPACEX这种公司连整火箭这种超级硬件都采用敏捷开发，采用敏捷开发肯定是有一定的优势。
作者本人参与软件开发20年，经历过传统的瀑布开发模式，参加过专业的敏捷开发培训，拿过认证的证书，带领团队经历过瀑布转敏捷的整个过程，从小到10个人的Scrum团队，到几百人共同参与的多Scrum团队合作。先分享一段很有意思的经历，最早公司尝试做agile，老板把不同领域的人加上1个QA组成了一个10-12人的Scrum团队（我作为PO兼职PM、QA兼职SM），老板的要求就是这个团队能够完成从需求、设计、研发、测试的所有事情（那时候还没流行DevOps，运维不归我们管）。接到的第一个项目就是跨Web、Server、client以及复杂场景的测试，由于本身项目的领域分工不均衡，这时候要求在项目中一边工作，一边跨领域学习新知识，就这样慢慢的做了3个月，团队在过程中快速成长。后来由于特殊事件，我带着这个团队接了一个新的项目，而这个项目的开发管理流程与整个公司都不一样。 整个团队增加了一个PM（该PM管的事情很多，我们只是一块），而做的事情本身就是End2End的feature，包含客户端（偏多）以及服务器和Web API端（偏少），同时客户端跨多个平台（Win/Mac/iOS/Android）, 没有专门的团队给我们做测试，我们团队必须自己完成发布前的所有测试工作（开发者测试+系统级别的测试）。在整个研发过程中，还需要和美国爱尔兰团队一起协作沟通，那段经历对于团队的每个人成长非常大。当年一个普通的开发人员，现在在微软也在短短几年做到了Senior Manager的位置。这篇文章，聊的不是Agile流程本身该怎么做，而是从个人的经历来谈一谈敏捷开发你必须知道的一些事。
敏捷开发与瀑布开发的根本区别是“迭代开发” + “增量开发”。这里要着重说的是增量开发，如果你的团队开发的项目或产品采用敏捷开发，然而不是通过增量开发的方式，团队会很困惑为啥要敏捷，敏捷带来了什么？笔者所在的项目最早采用瀑布开发模式，通常3-6个月一个release。当转向敏捷时，团队受到最大的鼓舞是客户的肯定，因为6个月的项目，在2个月的时候，客户就可以试用最初级功能的版本，客户对于几个月以后的产品充满了兴趣，即使在使用中遇到了很多问题，但是他们还是很乐意的去使用，并且在使用中提出很多意见和反馈。而这些反馈对于团队来说是巨大的帮助，而在每个月的迭代过程中，客户一步一步看到功能的完善和变化，当产品release之前，客户已经对于即将拿到的产品有了全面的认识和了解，对他们来说，这种产品就是他们想要的，甚至一些产品功能和使用习惯都是他们自己提出来的。这种开发模式所带来的变化是很多团队转向敏捷的根本原因。如果你对团队采用敏捷，然后开发的模式只是把产品开发的6个月的工作划分到每1-2周中，实际上并没有真正理解敏捷，也享受不到敏捷带来的好处，这时候你去转敏捷，可以说意义不大。
我在不同的文章中不止一次说过，产品质量的好坏与开发流程关系不大，至少和敏捷瀑布模式无关。产品的质量需要人+时间。合适的人加上充足的时间，才能提升产品质量。笔者在之前公司是做在线协作产品的（Welink + 视频会议），我们的产品发布模式是每个月一个Feature Release (Deliver Feature)，每周一个Patch Release （Fix Bug）。去年疫情期间，基于疫情状态下的产品需求激增，为了迎合市场，加班加点不说，整个开发出来的功能比平时多出100%不止。在这种情况下，产品的质量可想而知，很多问题都是发布前就已经已知的，由于市场需要，很多时候是在VP批准下，产品带着上百个bug上产线。然后后续通过一个个Patch Release来慢慢fix这些bug。产品质量的好与坏最终决定于你的测试，不管是开发者测试还是QA团队测试，最终你的产品发布之前经过完善的测试才能保证质量。当然开发者测试的重要性咱们这里就不再讨论了。
敏捷开发很重要的一点就是即将做的事情总是在变化的，在变化中决定未来一段时间的做什么。而所要做的事情就是我们常说的backlog，管理好你的backlog是极其重要的。整个敏捷高速运转的基础就是backlog的管理。
未来两年之内，你可能会做的所有事情，并且给每一个事情打上一个预估的优先级（可以是数字，也可以是字母）以及预估的工作量（T恤Size，XS, S, M, L, XL, XXL...）。
backlog有用户需求相关的，也有研发代码重构，架构演进技术相关的。
团队定期坐下来决定未来3-6个月要大致做什么，包含需求及技术的backlog，这时候要平衡技术类与用户类的需求。
当决定要做的东西，架构师要从技术上做到Design Ready（通常用wiki来记录），包含架构设计(Design)以及工作划分（US/Task）都可以确定，这时候才会真正拿到项目迭代中去实施。
每个迭代计划时，再有团队坐下来决定，从Ready的backlog中拎出哪些做。
从backlog的管理上来看，产品经理与架构师是非常重要的角色，2者除了正常的迭代过程外，承担了整个迭代的准备工作。而整个团队更像高速运转的机器一样去一个一个迭代去“生产”出“商品”。说到这你可能就明白为什么那么多企业要转向敏捷开发，除了第一点以外，就是最大化利用人力资源来产生价值。
通常公司会按照一定的规则来划分组织结构，以我之前的公司为例，最早按照地域（上海、合肥、杭州、苏州）划分，后来按照领域（Client、Web、Server）划分。即使在一个领域内，也有不同的细分。但是一般来说，做一个产品功能，会涉及到不同领域，同一个领域的不同子领域。很难做到一个组织结构内部的所有人可以搞定所有事情。特别是大型的项目，如果把每一个Scrum团队按照领域划分，做一个功能需要多个领域团队共同一起完成，这样的项目会遇到很多问题。而我之前的经验是一个大型项目，每个迭代会规划处很多不同的功能，把功能分配到不同的scrum团队里，而每一个scrum团队是根据功能来组合人员，保证每个团队都可以相对独立的完成几乎所有的工作，End2End的来deliver feature。这时候团队的组成有2大特色：1是来着不同的组织（不同的LM），2是团队人员经常变动。这种模式其实极具挑战性，对人的协同工作能力要求很高。
在整个产品迭代过程中，很多事情是非常繁琐的，同时也会受到各种各样的干扰，还有各方面的压力。这时候PO与SM是整个团队的运转核心，对于PO来说，只要能抗的责任，都由他来抗，不要让团队有任何顾虑，通常可以有管理岗位的人来担任PO的角色。SM是帮助团队管理项目的，这里强烈建议由合适的女性担任。对于SM来说，只要她能做的和项目相关的事情，就不要推诿，主动去帮助团队来完成，比如会议的组织，状态的更新，团建等各种事物，让团队的精力更Focus，动力更足。PO + SM的共同任务就是保障团队的在迭代周期内的全部精力都是在做事。
我们在说3、4、5的时候，你会发现我们讲到了PM、Architect、PO、SM以及Team，我们在讲人，而不是讲流程。Agile流程给了整个团队更多的自主性，要求团队每个人从意思到能力都要比较强。说到这你会发现，这种团队很像一个小的创业团队，没错这也就是为什么创业团队效率高的原因。而实际上在大公司，很多时候由于各种各样的原因无法做到这种团队，那么就需要根据自身人的情况来调整流程本身。
如果你去不同的公司，每一个公司的团队在进行敏捷开发过程中，都会有不同，而且其自身也是在不断演化之中。原因在于不同的公司有不同的文化，以及人员的组成各不相同，一个团队即使全是牛人，未必可以把敏捷搞好。敏捷团队本身也是在运转过程中，根据自身的成长，以及人员的变更，甚至是组织结构的调整，像架构一样不断地去演进。以我之前的团队为例，我们的Scrum团队没有PO的定义，而其职责由Product Manager， Deliver Manager，以及Architect共同来完成，加上SM，这四个人会形成固定搭配，然后根据项目来带领多个团队，组成多个scrum团队。这就与传统意义上的敏捷团队有很大不同，也未必有可复制性。所以这篇文章，我无法告诉你如何如何从瀑布成功转型敏捷，也无法告诉你具体方法来提升团队的敏捷效率。但是你可以明白，人是敏捷团队的基础，一个Team（PO+Architect+SM+PM+Members）每个人都是成功的关键。而合理的组合你的团队，让这些团队服务于一个产品。当这些团队在一起，能够一个迭代一个迭代去实现产品的各种功能来满足用户的需求，对企业产生价值，从而证明了他们的价值所在！！！
敏捷和速度是两个不同的属性。要理解敏捷的概念可以看看凌波微步是什么样的。CQ9电子平台 CQ9传奇CQ9电子平台 CQ9传奇
