敏捷软件开发是基于敏捷宣言定义的价值观《敏捷软件开发宣言》和原则《敏捷软件的十二条原则》的一系列方法和实践的总称。自组织、跨职能团队运用适合他们自身环境的实践进行演进得出解决方案。换句话说敏捷开发是一种应对快速变化的需求的一种软件开发能力，只要在符合价值观和原则的基础上能让开发团队拥有应对快速变化需求的能力，这就叫做敏捷开发。
解读：
在敏捷开发还没有出来之前，大部分公司的开发模式基本都采取瀑布式开发。而瀑布式开发往往具有如下几个特点：
根据传统瀑布式开发的以上特性，我们发现，面对互联网时代用户多变的需求，如果按照瀑布式开发进行，那么几乎很难响应需求的变更，难以做到快速交付新版本的产品。而并不是说瀑布式开发就一定不行，在传统行业依然是主流开发模式。
而敏捷开发由于迭代周期短（一般周为单位）、人员规模少、随时响应变化，具有更大的灵活性、更少的投入、更高效的开发、更及时的交付、更大程度的降低风险（及时了解市场需求，降低产品不适用风险）。从这个方面来讲敏捷开发是完全可以适应互联网时代下用户多变的需求，也就是我们常说的小步快跑，将一个大的需求拆分成各个小的需求，针对某个阶段的小需求，组织少量的人员，借助于一定的规范、流程、工具、会议，从而达到快速交付上线的目的。
互联网IT职能团队，如果要实施敏捷开发离不开四要素：规范、流程、工具、会议。敏捷的核心是人，只有人人参与遵守约定，那么敏捷开发才能高效进行。如下图，敏捷开发流程图。
规范是一种契约精神，要求团队所有成员都要遵守约定，把控规范细节，最终高质量交付成果
软件编码规范
编码规范，规定团队技术人员在编写代码时应该遵守的开发规则，比如命名规范、日志规范、注释规范、单元测试规范、异常处理规范等等。
数据库设计规范
数据库设计规范，要求技术人员在设计数据库时要考虑表设计、索引设计、SQL编写等方面的规则。
API设计规范
API规范一般意义指的是前后端分离时服务端网关系统对外提供的API规范，除此之外，在分布式环境中，服务端各模块系统会进行接口间通信，写接口时也要求遵守设计规范。
GIT管理规范
GIT管理规范，要求技术人员在分支命名、提交注释、代码合并等方面要遵守特定的规则。
版本管理规范
版本管理规范，软件发布包的版本号管理要遵守特定的规则，每次版本升级的变更特性列表要求详细编写。
测试规范
测试规范，用于约定测试团队的测试范围和测试标准，具体包括功能测试、接口测试、性能测试、自动化测试。
邮件规范
邮件规范，约定团队成员要遵守发送邮件的标题名编写规范，不同类型的邮件对应的标题关键字各不相同，方便及时通过关键词搜索历史邮件。另外根据团队不同，有的团队可能会要求团队成员发送每日日报、每周周报，日报和周报都是通过邮件的形式进行发送。
部署规范
部署规范，用于约定生产服务的部署方式，具体采用金丝雀部署、蓝绿部署、还是其他部署方式
结对编程
结对编程，一般指的是2个人同时负责共同模块功能的开发。两个人在一起探讨很容易产生思想的火花，不容易走上偏路，可以共同分析设计、写测试用例、编写代码。结对编程还有个好处就是，当一方开发人员离职时，不至于花费很多的交接时间，不会出现因为紧急需求来临时由于某开发人员离职造成无人可以负责的现象。
一般互联网公司的开发流程按照顺序大致分为如下几个阶段：
需求整理阶段、排期设计阶段、开发阶段、测试阶段、部署阶段。整个流程在实施的过程中必要时允许返工，允许驳回需求并且可随时调整需求。
需求整理阶段
一般是产品部门负责，产品从需求池中根据优先级筛选出优先级最高的需求进行详细设计，并产出PRD成果给到技术部门。
排期设计阶段
排期先要先进行需求评审，需求评审会由产品负责人发起，评审会中所有参与人就需求的问题进行讨论，需求敲定后，技术部门负责人或本次迭代负责人将详细的项目开发计划发送至所有干系人。
特殊说明的是，如经验证出现不合理需求问题，开发团队可打回需求拒绝排期开发。
开发阶段
开发阶段各成员按照计划有序进行开发，开发过程有任何需求疑问及时找产品经理沟通，产品经理如在开发过程中有紧急临时需求，可组会讨论后，优先紧急需求的开发；如有需求变动，可调整排期后重新发出排期计划。
注意强调单元测试的必要性，开发人员必须为自己编写的代码质量负责，自测完毕后才可提交给测试人员。
测试阶段
开发完毕自测通过后，开发人员通知测试人员基于测试项目分支开始进行测试环境的测试，如果出现任何BUG则将BUG提交到缺陷管理系统，开发人员根据BUG列表修复后更新BUG任务状态，然后测试复测。直到测试部门测试完毕后，符合上线要求后，方可通知运维部门进行上线操作。
特殊说明的是，如出现提测的功能部署后系统不能正常运行影响测试，测试团队可打回给开发拒绝本次测试，直到开发提测的代码没问题为止。
部署阶段
部署阶段，可分为预发环境部署和生产环境部署，流程大致相似。都是基于完成测试成功的对应环境的项目分支通过CI工具进行持续集成和部署。部署时的网关开关切换机制应考虑到位，尽量做到部署时对用户无感知，部署完毕后测试人员在生产环境仍需复测一次，确保上线成果的正确性。
一定要保证如果部署过程出现问题要有完善的回滚机制。
敏捷团队若要执行落地离不开很多高效的协作工具，这里我列举一些非常实用的工具供大家参考，工具的安装步骤不在本文的讲解范围内。
代码管理工具
一般选用基于GIT协议的分布式代码管理工具进行代码管理，常用的有gitlab、gitee、github。
项目管理工具
项目管理工具的意义在于管控所有迭代过程中的具体任务，用于跟进开发进度、管控开发效率。常用的工具有tower、jira。每个迭代周期内的任务会在排期过程中由部门负责人分配给每个人员，任务完毕后要求及时拖动任务状态，方便领导跟进查看进展。
知识库工具
知识库管理工具的作用在于团队协作的所有资料，方便团队成员有需要时随时进行查看。比如产品团队会将每个版本的产品PRD文件放入产品团队的知识库目录下，开发团队会将开发设计架构图、API接口文档等放入技术团队的知识库目录下，类似的，所有团队都可将用于团队协作的资料存入本团队对应的知识库目录中。
缺陷管理工具
缺陷管理工具用于测试团队在测试阶段提交BUG任务给开发人员，常见的工具有禅道、jira。
持续集成工具
持续集成工具目的在于实现自动构建、测试、打包、部署到各个环境中，建议使用docker进行进行部署，保证各个环境中系统运行不会出现环境问题。目前主流的持续集成工具有Jenkins、Bamboo。
SQL审核工具
生产系统上线后，如果出现BUG要修复生产数据，应由开发人员提交修复的SQL到审计系统中并提交申请，团队负责人负责一审，DBA负责二审，二审通过后SQL会自动执行。SQL审计工具上所有提交的SQL操作日志全部都会保留下来，方便追责时随时查看。常见的SQL审核工具有Yearning。
容器管理工具
用于对docker进行编排管理，比如常用的docker动态扩容、升级等。目前主流的的容器编排工具是K8S。
运维安全管理工具
主要用于管理机房或者云端所有服务器资源，控制开发人员权限，所有开发人员如需登录目标服务器，必须登录安全管理机后才有权限访问。常用的安全管理工具是jumpserver。
敏捷开发宣言强调个体沟通的重要性，所以会议的形式能增强沟通及时发现并修正问题，如下列举了敏捷开发过程中常见的会议类型
每日站立会议
站会有两种，早晨站立会或晚间站立会（不同的团队只要求其中一种即可），站立会在每天固定的时间要求大家放下手中的活全体起立，每个团队成员挨个发言，向所有成员分享上一日或今日完成的任务、遇到的问题、接下来的计划，如有阻碍开发进展的问题可提出但不展开讨论，会后关联人再详细沟通。站会期间，有的团队会采用看板形式（实际就是一个白画板多泳道）自己拖动任务状态。
迭代总结会议
迭代总结会议一般在某个迭代完成后尽快召开，此会议的目的在于复盘上次迭代过程中的整体情况，包括好的和不好的，好的继续精进，不好的要反思改正。
代码Review会议
代码检查会议，会根团队实际情况不定期的召开，目的在于规范团队开发人员的编码规范，要求注重代码质量。
每周总结会议
每周总结会议，一般定在每周五进行召开，目的在于总结本周团队的整体的工作进展，遇到的问题；会上有问题要及时汇总，要求问题负责人会后及时给出解决方案和时间节点。
技术分享会议
技术分享会，会根据团队情况不定期召开，目的在于让有经验的团队成员分享实战经验，提升团队整体水平。
如上，你大概花费10分钟就基本了解了敏捷开发团队的样貌，结果你发现传说中的敏捷开发也并没有那么的神奇。如果你的团队中出现了我文章提到的敏捷实施离不开的规范、流程、工具、会议这四要素的内容，那么你的团队就是一支敏捷开发的团队。
关注微信