敏捷软件开发及devops思想

敏捷软件开发

在目前新形势下，企业面对多重挑战：第一交付频率高，研发周期短，小特性一天交付一次，版本两周交付一次。第二跨地域合作多，部署发布复杂，跨地域沟通协作多、效率低；研发环境、类生产环境、生产环境不一致；还有急需一站式开发、测试、部署、运维平台的。第三可靠性与安全要求高，要求7*24小时运行，可靠性要求高；核心研发数据在传输与存储上存在风险。这些诸多挑战急需一种新的开发运维模式来解决，于是敏捷开发应运而生。

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

根据2019年的第13届VersionOne版年度敏捷行业状态报告，以scrum为基础的方法论（包括Scrum、scrum/xp混合等）体系仍然居于主流地位，使用率最高。其他的工程方法还有：kanban方法，精益编程，极限编程等等。

XP（极限编程）

以xp为例，xp既极限编程，Extreme Programming的缩写。极限编程是一种强调团队工作的工作方式，它是多种敏捷方式的一种，与Scrum不同的是，scrum是一种工作方式的框架，从组织到团队的设计，而XP更多关注的是具体的工程技术实践。XP旨在通过工程实践的合理搭配使用，使开发者们能够自信地响应客户需求。xp强调反馈环机制，客户与研发团队之间的反馈环，测试与开发的反馈环，具体代码实现跟单元测试之间的反馈环，结对之间的反馈环。极限编程认为在软件研发过程中，变化是无所不在的，人们不应回避变化，而应该适应变化，通过对反馈去适应变化。

极限编程方法往往有以下基本特征：

\1. 增量和反复式的开发，连续的小的改进

\2. 反复性，通常是自动重复的单元测试，回归测试

\3. 结对的程序设计

\4. 在程序设计团队中的用户交互

\5. 软件重构

\6. 共享的代码所有权

\7. 简单与反馈

\8. 用隐喻来组织系统

\9. 可以忍受的速度

极限编程中有四个核心价值是我们在开发中必须注意的：

沟通（Communication）、简单（Simplicity）、反馈（Feedback）、勇气（Courage）、此外还扩展了第五个价值观：尊重（Respect）。

XP用“沟通、简单、反馈、勇气和尊重”来减轻开发压力和包袱；无论是术语命名、专著叙述内容和方式、过程要求，都可以从中感受到轻松愉快和主动奋发的态度和气氛。这是一种帮助理解和更容易激发人的潜力的手段。XP用自己的实践，在一定范围内成功地打破了软件工程“必须重量”才能成功的传统观念。

XP精神可以启发我们如何学习和对待快速变化、多样的开发技术。成功学习XP的关键，是用“沟通、简单、反馈、勇气和尊重”的态度来对待XP；轻松愉快地来感受XP的实践思想；自己认真实践后，通过对真实反馈的分析，来决定XP对自己的价值；有勇气接受它，或改进它。一个严格实施的XP的项目，其开发过程应该是平稳的、高效的和快速的，能够做到一周40小时工作制而不拖延项目进度。

Devops

Devops，dev- development，ops- operation，devops是一种重视软件开发人员与IT运维技术人员之间沟通合作的软件开发模式，而传统的软件组织将开发、IT运营和质量保障设为各自分离的部门，各部门之间的沟通与协作少而困难，devops则打破了开发与运维之间的孤岛，由于团队间协作关系的改善，整个组织的效率因此得以提升，伴随频繁变化而来的生产环境的风险也能得到降低。相较于传统的美国式管理风格，例如斯隆模型或丰田模型，将会导致烟囱式自动化，每个业务线之间由不同的开发团队独立建设，技术栈不同，互不联系。大多数的架构会被打包被部署到容器中，整个结构趋于传统的单体架构，业务逻辑耦合在一个项目中。而这样的架构有几个主要的弊端：

\1. 重复开发。每个业务线中间同样的模块会被重复开发，比如商品销售模块，A业务线要搭建一个商品销售系统，B业务线也要搭建一个商品销售系统，这就造成了很多大的开发资源浪费；

\2. 技术栈不统一。A业务使用Linux，apache， mysql，php，python开发，而B业务使用mongoDB，express，node开发，这会造成内部架构无法统一规划，且技术能力难以积累的问题。

\3. 数据分布广，格式不统一，导致数据难以打通。A系统的商品信息存在A系统的MySql数据库中，B 系统的商品信息存在B系统的Oracle库中，如果要识别A系统中的0001商品和B系统中的0002商品是同一个商品，只能在数据仓库中实现。

而在具备devops能力的组织中，应用程序发布的风险变的很低，原因有

\1. 减少了变更范围

与传统的瀑布式开发相比，采用敏捷开发或者迭代开发的团队能更频繁的发布，每次发布内容所包含的变化更少，更多次的部署带来更小的对生产系统的影响，整个开发的过程增长将是一个较为平缓的过程。

\2. 加强发布协调

靠强有力的发布协调人（产品经理等）来弥合开发与运营之间的技能鸿沟和沟通鸿沟；可以利用线上会议，即时消息，或者面对面的会谈等方式来确保所有相关的开发和运维人员理解每次变更的内容并全力创造。

Devops能高效协调的重要组成之一，就是将开发和运营联系起来的发布协调人，传统意义上的发布管理往往只关注软件变更的计划与管理，发布协调则需要控制“将特定软件变更发布至生产环境”的整个过程，这个角色与航空交通管制有些类似，需要实时协调不同团队的行动，有效利用共享而有限的资源（如跑道，空域，航站门），而达到组织的总体目标（如航班的顺利起降）