浅谈敏捷开发的思维

什么是敏捷

Agile（敏捷）来源于敏捷宣言，宣言明确指出，“敏捷”：

• 不是一种方法论
• 也不是开发软件的具体方法
• 更不是一个框架或者过程

“敏捷”是一套价值观（理念）和原则，帮助团队在软件开发过程中更好地做出决策。

---

 什么是敏捷开发

        简而言之，就是遵循了“敏捷”这一开发原则的开发方法。

        “敏捷并不意味着一味强调速度，而是轻量和高效。”

「百度百科」是这样说的：敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。

思考：对于一个项目工程，多人团队合作分工提交代码，按照敏捷开发思维，每个人员的代码应该相对独立可提测发板，而没有互相强依赖关系。不能应该一个人代码报风险阻塞就影响其他人，造成团队效率降低。举一反三，小到每一个产品需求，涉及到多个业务模块，也应该把需求拆分独立，抓住核心要点即可。大到团队管理，也是一样道理，不能一个部门delay其他部门都进入阻塞状态（停工等待）。

敏捷开发流程如下：

 

敏捷宣言

• 个体和互动   高于    流程和工具
• 工作的软件   高于    详尽的文档
• 客户合作       高于    合同谈判
• 响应变化       高于    遵循计划

注：这并不意味摒弃了右边的原则，而是应该更加注重左边的原则。

比如就“简单”和“尽早交付”而言：
当我们在构建某个功能时，发现其可能会需要数据库支持，一般情况下我们会去构建数据库并为其编码，然而敏捷认为：为这个功能构建数据库就意味着要浪费很多时间，软件就不得不延迟交付给客户，如果能找到一种替代的简单方法完成该功能，那就更符合我的敏捷原则。

敏捷开发的核心价值是“轻量、高效”，但不要形而上学，为了追求高效而删繁就简，应该保持在架构背景和长远规范的合理范围内去做敏捷开发。

---

瀑布模型开发

        瀑布型是最常见的结构开发方法。规定了计划、需求分析、设计、编码、测试的自上而下相互衔接的结构化开发方法，

各阶段介绍
需求分析

入口条件：项目计划书已通过评审

出口条件：软件需求规格说明书通过评审

操作过程：根据项目经理或者开发代表提出或者了解的用户需求，进行分析确认，由项目经理和系统分析人员共同指定需求规格说明书，主要说明软件的运行环境、开发工具以及详细的功能和性能需求。

设计

入口条件：软件需求规格说明书已通过评审

出口条件：软件设计说明书通过评审（可分为概要设计和详细设计）

操作过程：根据软件的需求规格说明书，将软件分解到功能模块一级，并定义好全局变量和全局数据以及各个模块之间的接口描述（一般可以将此整理成为概要说明书）。并根据模块划分，定义好实现每一个模块功能所需的结构、变量以及函数，并对每一个函数提供基于伪代码的实现（这些可拆分为详细设计说明书）。将这些形成软件设计说明书。

编码实现

入口条件：设计说明书已通过评审

出口条件：代码通过评审和编译检查，并通过运行测试

操作过程：开发人员根据详细设计说明书定义的函数实现过程，依照一定的编码规则，编写出软件的实现代码，然后使用编译检查工具对其进行编译检查

测试

入口条件：代码通过评审和编译检查，并通过运行的冒烟测试

出口条件：软件的功能和性能通过验证

操作过程：测试人员编写系统测试用例，并根据测试用例，在实际的系统运行环境中，验证软件的功能和性能（可分为单元测试、集成测试和系统测试）

优缺点
优点：结构清晰

缺点：测试在项目生命周期的最后阶段进行，当系统出现严重 Bug 并且修改代价很大时，就会无可避免的推迟项目提交日期。而且瀑布模型使得开发中的很多关键成员例如开发、测试处于长期空闲状态。测试人员由于最后才开始介入测试，会因为没有充分的准备而导致测试的缺失和不够深入

---

 
总结：在理解了“敏捷”的价值和原则后，将其带入到软件开发过程中做出正确的决策，就是所谓的敏捷开发了。