对于企业而言DevOps在企业中的落地不光是CI/CD的工具使用，更是一套整体的开发流程和团队协作的改造，对于非互联网行业的企业来说可能本身没有研发团队，但考虑到DevOps对应用快速迭代带来的优势会考虑在企业中落地DevOps的标准，实际上单纯的定义工具和基础架构的使用规则还是没法有效的提升应用交付的效率，这种情况下交付时间的瓶颈可能会在第三方的应用开发商身上，他们本身可能使用传统的开发管理流程，导致应用开发的流程和架构进展缓慢。所以对于DevOps来说除了选择成熟的工具和现在流程的容器技术作为应用载体以外，更应该关注整个开发流程的效率提升。
传统开发流程和敏捷开发的对比
我们一般把瀑布流式的开发流程和敏捷开发做对比，其实本质上这两种开发流程的不同是交付方式的不同所导致的。
举个例子：现在有一个需求，某人需要从A地快速省力的到达B地，如果需要解决这个问题，对于瀑布流式的交付方式来说会先给个轮子，再给个底盘，最后给一辆整车，满足用户需求，但对于这个快节奏的互联网时代来说明显是脱节得很厉害。
而增量交付的方式则是为用户提供最小可用产品（MVP – Most Variable Product），在每一次的增量迭代中逐步发现并满足用户更具体的需求，除了能应对业务的快速增长以外，也可以通过用户的反馈及时做出调整，说实话往往大家可能并不知道自己最终的产品长什么样，与用户一同找寻最终的产品是个艰辛而美好的过程。
也不能说瀑布流式的开发模式完全不好，敏捷开发简化了很多瀑布流开发模式的过程，两者有不同的适应场景，而对于敏捷开发来说最大的两个优势是在于能够拥抱变化并且进度可视，这两点无论在应对快速发展的业务层面还是团队协作层面相较于瀑布流式开发过程有着极大的改进。
当然，增量式交付的方式也有它的问题，当你沉浸在无休止的细分需求中时，你会无法看清产品的全貌，无法了解系统提供的功能的完整性，只着眼于面前亟待完成的需求，除了会导致产品走向发生偏离正轨的情况，相信团队在开发工程中也会力不从心，无处使劲。这个时候，我们可以使用影响地图和用户故事来帮助团队梳理产品的发展路线。
影响地图和用户故事
对于产品从极度抽象到极度明确，需要对业务目标、功能场景、功能实践都有明确的定义，在这个过程中可以使用影响地图和用户故事两个工具去梳理产品最终的形态。
在影响地图中我们需要搞清楚这样一个简单的思维逻辑和组织结构：为什么（Why）–>谁（Who）–>怎样（How）–>什么（What），也就是：我们的目标是什么（Why），为了达成目标需要哪些人（Who）去怎样（How）影响，为此我们需要做什么（What）。影响地图通过构建产品和交付项目来产生实质影响，从而达到业务目标。
还是拿出行的需求来举例，我们目标是从A地到B地，用户可能是通勤的上班族，可能是出去旅游的游客，还有我们的产品研发人员，服务管理人员，为此我们需要让我们的服务管理人员快速的为用户提供更便捷更高效的出行方式，为上班族提供汽车，为旅行者提供飞机。基于这样抽象的影响地图我们可以细分在这个过程中需要完成的功能，通过影响地图建立产品目标和功能之间的关系。
有了产品目标和抽象的功能就需要将这些功能细化至可落地的开发工作项，根据决定好的技术栈和展现形式规划产品的形态。根据之前出行需求的影响地图，我们将整个出行的过程分为用户注册、出行方式预约、增值服务等，每个功能模块里会有很多细分的功能细项，例如用户注册：好友推荐、短信邮箱验证、个人信息填写等，出行方式预约：选择出行方式、预约时间、地图服务等，增值服务：选座服务、订餐服务、接车服务等。区分完后再根据功能项的优先级进行排序，整理出每个阶段需要完成的内容。用户故事带来的好处是让业务人员更容易与技术团队沟通，能够将产品的功能项原汁原味的传递给开发团队，用户故事的内容转换为开发功能点，识别与其他功能点的依赖，形成详细的产品规格。
敏捷开发Scrum和DevOps
梳理完业务层面接下来考虑的问题就是如何快速高效的进行开发和测试了。敏捷开发中的Scrum方法相信大家都很熟悉，通过三个角色（ScrumMaster, Product Owner, Team），五个会议（计划会议，迭代评审会议，每日立会，回顾会议，迭代开发），五个工具（Product Backlog, Sprint Backlog, Burndown Chart, Cumulative Flow Chart, Velocity Chart）形成一套敏捷开发的有效管理机制，结合用户故事完成每个sprint中需要交付的功能点。结合DevOps的技术可以将每个开发完的sprint backlog进行快速发布到测试环境，进行UAT测试，省却了冗余的底层代码和兼容性的测试，这些工作将会在DevOps中自动化完成，当有代码进行Pull Request时自动触发DevOps的pipeline完成从编译、测试到打包、部署的全过程，另外运维人员也可以将基础环境通过公有云或第三方的IaaC工具转化成代码，并结合进pipeline中从而节省资源使用的时长，按需开启test和staging的环境。有很多可以实现Scrum看板功能的工具，DevOps可以使用GIT+Jenkins的方式完成，结合AWS、Azure等公有云的IaaC工具自动启动环境部署环境。
从100天发布1次到1天发布百次，可以看到不仅是工具的使用，更是流程和团队的改造，希望大家在DevOps的改造和产品设计流程优化的过程中明确自己的业务目标，由上而下推动整体项目的落地，加速产品的开发效率和质量。谢谢大家！
