自9月份转到新部门后，几个月下来，发现公司核心部门的软件研发质量确实比产品部门的要高一个档次。不仅涉及代码设计模式，而且软件开发过程中使用了相应的软件开发模式进行管理。
关于软件开发模式和代码设计模式，在这之前都未去了解。从现在来看，这方面知识的缺乏确实影响了自己能力的提高。出于这点，打算利用空闲时间来补充这方面知识。本节就介绍下敏捷开发模式。
前言
以前经常访问CSDN网站，经常看到网友谈论敏捷开发模式，因此印象深刻。据说，小米的MIUI就是采用敏捷开发模式进行开发的。
概念
敏捷开发（agile develolment），是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
特点
2001年，17名编程大师分别代表极限编程、Scrum(“棒球”团队开发模式)、特征驱动开发、动态系统开发方法、自适应软件开发、水晶方法、实用编程等开发流派，发表“敏捷软件开发”宣言。敏捷开发模式是一个软件开发管理新模式，用来替代以文件驱动开发的瀑布开发模式。敏捷方式也称轻量级开发方法。
敏捷软件开发宣言内容：
- 个体和交互胜过过程和工具
- 可以工作的软件胜过面面具到的文档
- 可户合作胜过合同谈判
- 响应变化胜过遵循计划
敏捷开发集成了新型开发模式的共同特点，它重点强调：
1. 以人为本，注重编程中人的自我特长发挥。
2. 强调软件开发的产品是软件，而不是文档。文档是为软件开发服务的，而不是开发的主体。
3. 客户与开发者的关系是协作，不是合约。开发者不是客户业务的“专家”，要适应客户的需求，是要客户合作来阐述实际的需求细节，而不是为了开发软件，把开发人员变成客户业务的专家，这是传统开发模式或行业软件开发企业的最大面临问题。
4. 设计周密是为了最终软件的质量，但不表明设计比实现更重要，要适应客户需求的不断变化，设计也要不断跟进，所以设计不能是“闭门造车”、“自我良好”，能不断根据环境的变化，修改自己的设计，指导开发的方向是敏捷开发的目标。
项目的敏捷开发
敏捷开发小组主要的工作方式可以归纳为：
- 作为一个整体工作；
- 按短迭代周期工作；
- 每次迭代交付一些成果；
- 关注业务优先级；
- 检查与调整。
- 最重要的因素恐怕是项目的规模。规模增长，面对面的沟通就愈加困难，因此敏捷方法更适用于较小的队伍，40、30、20、10人或者更少。
因此在敏捷开发模式中，一个项目被分解为多个部分或多个步骤。在每个阶段完成后，项目都可以拿出一定程度可交付的产品。这样做便于实现产品交付目标，降低整个项目的复杂度，同时在项目早期就能拿出初具雏形的产品。
以MIUI为例，早在2010年，MIUI就已经出现，并逐步培养起了一批用户。然而，最初版本的MIUI仅仅只是Android系统的一个界面。当前MIUI中用户熟悉的语音助手、应用超市、防打扰功能，甚至手电筒应用，都没有被包括在其中，而是在过去3年的开发过程中逐渐加入。每周的更新中，有相当一部分是为了修复bug所做的更新，这也是分用户觉得它“为了更新而更新”的原因。
开发过程
与迭代开发的区别
敏捷开发相比迭代式开发，两者都强调在较短的开发周期提交软件，但是，敏捷开发的周期可能更短，并且更加强调队伍中的高度协作。
敏捷方法有时候被误认为是无计划性和纪律性的方法，实际上更确切的说法是敏捷方法强调适应性而非预见性。适应性的方法集中在快速适应现实的变化。当项目的需求起了变化，团队应该迅速适应。这个团队可能很难确切描述未来将会如何变化。
与瀑布模式的区别
敏捷开发与瀑布模式的不同，主要是下面几个“敏捷”的关注点：
1. 迭代。软件的功能是客户的需求，界面的操作是客户的“感觉”，对迭代的强调是缩短了软件版本的周期
2. 客户参与。以人为本，客户是软件的使用者，是业务理解的专家，没有客户的参与，开发者很难理解客户的真实需求
3. 小版本。快速功能的展现，看似简单，但对于复杂的客户需求，合理地分割与总体上的统一，要很好地二者兼顾是不容易的。
总结
敏捷就是“快”，快才可以适应目前社会的快节奏；要快就要发挥个人的个性思维多一些，个性思维的增多，虽然通过结队编程、代码共有、团队替补等方式减少个人对软件的影响力，但也会造成软件开发继承性的下降，因此敏捷开发是一个新的思路，但不是软件开发的终极选择。
对于长时间、人数众多的大型软件应用的开发，文档的管理与衔接作用还是不可替代的。如何把敏捷的开发思路与传统的“流水线工厂式”管理有机地结合，是软件开发组织者面临的新课题。
Wshell在线终端