敏捷软件开发:原则-web开发敏捷之道应用rails进行敏捷web开发

关联：

敏捷开发的定义

敏捷软件开发是基于敏捷宣言《敏捷软件开发宣言》和原则《敏捷软件十二原则》定义的价值观的一系列方法和实践的总称。 自组织的跨职能团队使用适合其自身环境的实践来发展解决方案。 换句话说，敏捷开发是一种响应快速变化的需求的软件开发能力。 只要开发团队具备基于价值观和原则对快速变化的需求做出响应的能力，就叫敏捷开发。

敏捷开发宣言

解释：

以人为本，没有比面对面交流更有效的沟通渠道了。 基于相互信任的前提，敏捷提倡自治的全功能团队。 在工作形式上，整个团队通常坐在一起工作，从物理空间创造更方便的面对面交流机会。 在团队职责方面，团队具有完成软件交付的角色（能力），团队负责人对软件质量负责，开发过程由团队控制，业务价值团队在团队内部快速流动，在任何一个环节都能得到及时的反馈。 同时，每个角色更容易站在全局的角度思考软件，避免了传统部门墙模式中的视角分离和协作障碍。

向客户交付可工作的软件是我们的核心目标。 我们应该尽早交付可以进行端到端测试的代码。 这个目标决定了我们不应该在综合文档上花费过多的精力，但这并不意味着我们应该抵制任何文档。 实践证明，轻量级文档策略有助于团队交付高质量、可工作的软件。

积极拥抱变化，及时响应，持续交付。

通过高效协作，获得快速反馈，从而尽快做出调整，减少浪费。

敏捷开发的十二条原则

为什么使用敏捷？

在敏捷开发出来之前，大部分公司的开发模式基本都是采用瀑布式开发。 瀑布式开发往往具有以下特点：

根据传统瀑布式开发的上述特点，我们发现，在互联网时代，面对用户不断变化的需求，如果按照瀑布式开发，几乎很难快速响应需求变化和快速交付新版本的产品。 这并不意味着瀑布式开发一定行不通。 仍然是传统行业的主流发展模式。

敏捷开发由于迭代周期短（一般以周为单位）、人员规模小、随时响应变化，具有更大的灵活性、更少的投入、更高效的开发、更及时的交付，以及更大程度的降低风险。 （及时了解市场需求，降低产品不适用的风险）。 从这个角度来看，敏捷开发完全适用于互联网时代用户不断变化的需求。 针对需求，组织少量人员，借助一定的规范、流程、工具和会议，达到快速交付和上线的目的。

图片

如何实施敏捷？

互联网IT职能团队要想实施敏捷开发，离不开规范、流程、工具、会议四大要素。 敏捷的核心是人。 只有人人参与并遵守约定，敏捷开发才能高效进行。 如下图所示，敏捷开发的流程图。

图片

规格

规范是一种契约精神，要求团队所有成员遵守约定，控制规范细节，最终交付高质量的成果

软件编程规范

编码规范，规定了团队技术人员在编写代码时应遵循的开发规则，如命名规范、日志规范、注释规范、单元测试规范、异常处理规范等。

数据库设计规范

数据库设计规范要求技术人员在设计数据库时要考虑表设计、索引设计、SQL编写等方面的规则。

API设计规范

API规范的一般含义是指前后端分离时服务端网关系统提供的API规范。 另外，在分布式环境中敏捷软件开发:原则，服务器端的各个模块系统都会在接口之间进行通信，接口也需要符合设计要求。 规格。

Git管理规范

GIT管理规范要求技术人员在分支命名、提交注释、代码合并等方面遵守特定规则。

版本管理规范

版本管理规范，软件发布包的版本号管理必须遵守特定的规则，每次版本升级的变化特性列表需要详细编写。

测试规范

测试规范用于约定测试团队的测试范围和测试标准，包括功能测试、接口测试、性能测试和自动化测试。

电子邮件规范

邮件规范规定团队成员必须遵守所发送邮件标题名称的书写规范。 不同类型邮件对应的标题关键词不同，方便通过关键词及时查询历史邮件。 此外，根据团队的不同，有些团队可能会要求团队成员发送每天的日报和每周的周报。 每日报告和每周报告均通过电子邮件发送。

部署规范

部署规范用于约定生产服务的部署方式，具体为金丝雀部署、蓝绿部署或其他部署方式。

结对编程

结对编程一般是指两个人同时负责共同模块功能的开发。 两个人一起商量，很容易产生思想的火花，也不容易误入歧途。 他们可以共同分析设计、编写测试用例和编写代码。 结对编程的另一个好处是，当一个开发人员离职时，不会花费大量的交接时间，不会出现急需开发人员离职而无人负责的现象。

过程

一般的互联网公司的发展过程大致按顺序分为以下几个阶段：

需求整理阶段、调度设计阶段、开发阶段、测试阶段、部署阶段。 整个过程允许必要时返工，在实施过程中随时拒绝需求和调整需求。

需求排序

一般由产品部负责。 产品根据优先级从需求池中选择优先级最高的需求进行详细设计，产生PRD结果给技术部门。

进度设计阶段

需要首先审查计划。 需求评审将由产品负责人发起。 评审会议的所有参与者将讨论这些要求。 计划发送给所有利益相关者。

发展阶段

在发展阶段，每个成员都按照计划有条不紊地发展。 开发过程中如有需求问题，请及时与产品经理沟通。 如果产品经理在开发过程中有紧急的临时需求，可以在小组会议中讨论，优先开发紧急需求； 如有需求变更，可调整排期，重新排期。

测试阶段

开发完成并自测通过后，开发人员通知测试人员开始测试基于测试项目分支的测试环境。 如果出现任何BUG，BUG将提交给缺陷管理系统。 开发者会根据BUG列表修复后更新BUG任务状态，然后测试复测。 可以通知运维部门进行上线操作，直到测试部门完成测试，满足上线要求。

部署阶段

部署阶段分为预发布环境部署和生产环境部署，流程大致类似。 都是基于测试成功的对应环境的项目分支，通过CI工具持续集成部署。 部署时的网关切换机制要考虑到位，用户尽量不要感知部署。 部署完成后，测试人员还需要在生产环境中重新测试一次，以保证上线结果的正确性。

工具

敏捷团队离不开许多高效的协作工具。 在这里我列出了一些非常有用的工具供大家参考。 这些工具的安装步骤超出了本文的范围。

代码管理工具

一般采用基于GIT协议的分布式代码管理工具进行代码管理。 常用的有gitlab、gitee、github。

项目管理工具

项目管理工具的意义在于控制所有迭代中的具体任务，跟进开发进度，控制开发效率。 常用的工具有tower和jira。 每个迭代周期中的任务会在调度过程中由部门负责人分配给每个人。 任务完成后，需要及时拖拽任务状态，方便领导跟进，查看进度。

知识库工具

知识库管理工具的作用在于团队协作的所有资料，方便团队成员在需要时随时查看。 例如，产品组将每个版本的产品PRD文件放入产品组的知识库目录，开发组将开发设计架构图、API接口文档等放入产品组的知识库目录。技术团队。 同样，所有团队用于团队协作的所有资料都可以存放在该团队对应的知识库目录中。

缺陷管理工具

测试团队使用缺陷管理工具在测试阶段向开发人员提交错误任务。 常用的工具有禅道和吉拉。

持续集成工具

持续集成工具的目的是实现自动化构建、测试、打包、部署到各种环境。 推荐使用docker进行部署，保证系统在各个环境下运行不会出现环境问题。 目前主流的持续集成工具有 Jenkins 和 Bamboo。

SQL审计工具

生产系统上线后，如果出现BUG，需要修复生产数据，开发者将修复后的SQL提交给审计系统，提交申请。 team leader负责第一次review，DBA负责第二次review。 二次审核通过后，SQL会自动执行。 所有在SQL审计工具上提交的SQL操作日志都会被保留，方便您在负责时随时查看。 常见的 SQL 审计工具包括 Yearning。

容器管理工具

用于编排和管理docker，比如常用的docker动态扩容和升级。 目前主流的容器编排工具是K8S。

运维安全管理工具

主要用于管理机房或云端的所有服务器资源，控制开发者的权限。 如果所有开发者都需要登录目标服务器，必须先登录安全管理机，才有访问权限。 常用的安全管理工具是jumpserver。

会议

敏捷开发宣言强调个体沟通的重要性，所以会议的形式可以加强沟通，及时发现和改正问题。 下面列出敏捷开发过程中常见的会议类型。

每日站立会议

站会分为两种，早上站会或晚上站会（不同团队只需要其中一种）。 站会要求大家在每天固定的时间放下手中的工作，全部站起来。 每个团队成员一一发言。 全体成员分享前一天完成的任务，遇到的问题，下一步计划。 如果存在阻碍开发进度的问题，可以提出，但不能讨论。 会后，相关各方将进行详细沟通。 站会的时候，有的团队会用看板的形式（其实就是一个多道的白色画板）自己拖任务状态。

迭代总结会议

迭代总结会议一般在某个迭代完成后尽快召开。 这次会议的目的是回顾上次迭代过程中的整体情况，包括好的和不好的，好的继续改进敏捷软件开发:原则，不好的需要反思和改正。

代码审查会议

代码检查会根据团队实际情况不定期召开。 目的是规范团队开发人员的编码标准，要求关注代码质量。

每周总结会议

每周总结会议一般安排在每周五举行。 目的是总结本周团队的整体工作进度和遇到的问题； 会议中的问题要及时总结，并要求问题负责人在会后及时间节点及时给出解决方案。