敏捷开发需要学习。敏捷开发就是将项目拆分为多个子项目，独立开发、分别实现，尽快的产出交付给用户，收集用户反馈后立即调整优化，一直迭代到用户满意，最后集成为一个完整的极具用户价值的产品。
一、什么是敏捷开发
敏捷开发就是将项目拆分为多个子项目，独立开发、分别实现，尽快的产出交付给用户，收集用户反馈后立即调整优化，一直迭代到用户满意，最后集成为一个完整的极具用户价值的产品，且在此过程中产品一直处于可用状态。
传统的开发模式，像瀑布模型、喷泉模型、螺旋模型等等，虽然有不断的进化与创新，但始终没有一款能快速、灵活地适应市场变化；进而发展了很多轻量化的软件开发方法，比如Scrum、水晶清透法、极限编程法等等，它们都起源于敏捷开发宣言之前，但都统称为敏捷软件开发法，因为他们都是迭代和增量式的开发。
各种敏捷开发方法的差异在于理念、过程、术语不同，但相较于“非敏捷”，它们都更强调团队间的紧密协作、面对面的沟通、频繁的交付新版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发过程中人的作用。
二、为什么要用敏捷开发
对外：跟不上业务发展，错失市场机遇
20世纪50年代，计算机刚投入实际使用时，软件开发大多是为了特定的应用在指定的计算机编制设计，供小范围使用，简单、规模小且没有文档资料，更不用谈系统化开发。
随着技术发展（70年代-90年代），计算机应用范围的扩展，出现了数据量大、复杂程度高、软件稳定可靠的需求，催生了一些系统化的开发方法，其中以瀑布模型为代表（后面会说）。
系统化解决了过去的部分问题，但面对互联网时代（90年代-2007年）更大型、更复杂、陌生领域的项目，会产生更大且难以预测的问题；随着移动互联网时代兴起（2007年-现在），这些问题愈发凸显，面对日益激烈的市场竞争，企业的反应能力成为关键商业因素。
对内：团队耗能高、成本大、紧密度低
传统模式往往是线性流程，强调结构化、标准化，若有发生需求变更或问题出现，则涉及多个模块的调整，需要投入大量的时间、精力与金钱；团队成员只和上下游互动，缺乏信息共享意识，容易导致不透明、不信任，最直观的表现就是明明有沟通协配，但也很难形成团队共识；在规模较大的企业，人员众多、部门复杂、分工细化，跨部门协作经常出现信息不一致、沟通成本高、反馈不及时、紧密程度低等问题。
三、Scrum敏捷开发流程
众多敏捷开发方法中，有的专注于实践，如极限编程、敏捷建模；有的专注于管理工作流程，如Scrum；有的支持需求规范和开发（如FDD）的活动；而另一些则试图涵盖整个开发生命周期，如动态系统开发。
我们这里简单介绍一下较为流行的Scrum开发流程：
Scrum原意指的是英式橄榄球运动中，次要犯规时在犯规地点对阵争球，两队各以一个整体的方式，队员间紧密相拥、协作争球。
1995年美国计算机协会的OOPSLA’95会议上，在Jeff Sutherlan和Ken Schwaber联合发表的论文中首次提出Scrum概念：以跨职能团队的形式，像橄榄球队般紧密协作，围绕随着统一的目标前进，以此提高工作与交付效率。
延伸阅读：
四、发车模式
在产品的发布模式上，很多新型企业、成熟企业会采用一种发车模式：即限定时间和质量，通常2周发布一个新版本，用以规范发布、提升发布速率、规范系统之间的集成。
每个公司都会有自己的黑话，有的叫“火车模式”，有的叫“班车模式”，有的叫“高铁模式”等等，为方便大家理解咱们就统称发车模式。
跟企业的具体情况以及团队能力，发布周期会有所不同，不必纠结于2周这个频率；总之就像发车一样，每间隔一段时就发布一次新版本，有计划、有规律。
以上就是关于敏捷开发的内容希望对大家有帮助。
