自组织、跨职能团队运用适合他们自身环境的实践进行演进得出解决方案。
换句话说敏捷开发是一种应对快速变化的需求的一种软件开发能力，只要在符合价值观和原则的基础上能让开发团队拥有应对快速变化需求的能力，这就叫做敏捷开发。
敏捷开发宣言个体和互动高于流程和工具工作的软件高于详尽的文档客户合作高于合同谈判响应变化高于遵循计划解读：以人为本，没有比面对面交流更高效的沟通渠道了，基于互相信任的前提，敏捷提倡自治的全功能团队。
在工作形式上，整个团队平时坐在一起工作，从物理空间上创造了更加便捷面对面的沟通机会。
在团队职责上，团队内部具备完成软件交付的角色（能力），团队所有人对软件的质量负责，开发过程由团队内部把控，业务价值团队内部快速流动，在任何环节都能及时获得反馈。
同时，每个角色都更容易从全局视角去思考软件，避免了传统部门墙模式下的视角割裂和协作障碍。
为客户交付可工作的软件是我们的核心目标，我们应该尽早交付可进行端到端测试的代码，该目标决定了我们不应该花过多精力在面面俱到的文档上，但这不代表我们要抵制任何文档。
实践证明，轻量级的文档策略有助于团队高质量交付可工作的软件。
主动拥抱变化，及时响应，持续交付通过高效的协作，获取快速的反馈，从而尽早做出调整，减少浪费敏捷开发十二原则我们最重要的目标，是通过及早和持续不断地交付有价值的软件使客户满意欣然面对需求变化，即使在开发后期也一样。
为了客户的竞争优势，敏捷过程掌控变化经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期业务人员和开发人员必须相互合作，项目中的每一天都不例外激发个体的斗志，以他们为核心搭建项目。
提供所需的环境和支援，辅以信任，从而达成目标不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈可工作的软件是进度的首要度量标准敏捷过程倡导可持续开发。
责任人、开发人员和用户要能够共同维持其步调稳定延续坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强以简洁为本，它是极力减少不必要工作量的艺术最好的架构、需求和设计出自自组织团队团队定期地反思如何能提高成效，并依此调整自身的行为表现WHY? 为何使用敏捷在敏捷开发还没有出来之前，大部分公司的开发模式基本都采取瀑布式开发。
而瀑布式开发往往具有如下几个特点：文档：尤其看重文档，项目初期就要求文档设计的非常完善，一切以详细的文档为导向开发周期：固定且漫长，至少以数月为单位，团队成员严格按照项目排期进行开发人员规模：人数众多，一般都是整个技术部门全员一起参与某一开发周期的项目开发需求变动：定好的需求，一般不会变动，所以需求一开始就要设计的非常完善返工：由于软件生命周期严格按顺序划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。
那么一旦开始进入开发，那么不可能返工，因为返工会带来巨大的成本开销版本变更：每个项目项目开发阶段都会有明确的目标，目标如果未完成不会进入下一阶段，也就意味着版本变更不会太频繁根据传统瀑布式开发的以上特性，我们发现，面对互联网时代用户多变的需求，如果按照瀑布式开发进行，那么几乎很难响应需求的变更，难以做到快速交付新版本的产品。
而并不是说瀑布式开发就一定不行，在传统行业依然是主流开发模式。
而敏捷开发由于迭代周期短（一般周为单位）、人员规模少、随时响应变化，具有更大的灵活性、更少的投入、更高效的开发、更及时的交付、更大程度的降低风险（及时了解市场需求，降低产品不适用风险）。
从这个方面来讲敏捷开发是完全可以适应互联网时代下用户多变的需求，也就是我们常说的小步快跑，将一个大的需求拆分成各个小的需求，针对某个阶段的小需求，组织少量的人员，借助于一定的规范、流程、工具、会议，从而达到快速交付上线的目的。
HOW? 如何实施敏捷互联网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分钟就基本了解了敏捷开发团队的样貌，结果你发现传说中的敏捷开发也并没有那么的神奇。
如果你的团队中出现了我文章提到的敏捷实施离不开的规范、流程、工具、会议这四要素的内容，那么你的团队就是一支敏捷开发的团队。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）