关于devops:研发效能谈敏捷开发团队转型中的协作化与自动化

作者：

杨凌宇（现就职中国电信研究院）

研发效力（DevOps）工程师认证学员

前言

在现在软件开发流程和工具愈发成熟的现状下，麻利仿佛是所有软件产品团队后退的指标。很多团队都声称本人是麻利团队，但实际上，他们更多是在肯定水平上达到了麻利。咱们在麻利实际的过程中，总会与现实中的状况存在差距，所以咱们更多要思考的不是怎么彻底的达到麻利，而是在以后的理论状况下，怎么更好的使用麻利的思维去改良。麻利涵盖的范畴十分广，从需要收集，到产品设计、开发交付、测试平安、运维保障等一系列流程，都能够使用麻利的思维。其中开发交付的过程，是真正建设出一个产品的过程，我作为一名一线的开发人员，也更想谈一谈在开发过程中，以及对于开发团队来说，如何进行麻利的转型。

何为麻利开发

麻利开发是以用户的需要为外围，把大的需要进行拆分，采纳迭代式的办法进行开发，使软件始终处于可公布状态。麻利开发离不开团队单干。在任何模式的团队中，大家都会强调“teamwork”这个词，麻利开发团队的一个重要思维其实也是“teamwork”，咱们称为“协同”。

在一个 Scrum 团队中，有产品设计人员、开发人员、测试人员等，大家协同工作，以此形成了产品的残缺生命周期。在大团队内有大团队的协同，在小团队也要有小团队的协同。对于开发团队来说，当其内的开发成员可能在麻利上达成共识，劲往一处使，这样造成的合力才是最大的，这个团队才算是开始走向麻利。在这之后，团队独特抉择适合的麻利开发工具，定义麻利开发的流程和标准，使得麻利思维可能真正落入到麻利实际中，从而实现团队的麻利转型，并可能继续低成本高效的交付价值。

麻利开发团队的核心思想

早在 2009 年，Flickr 在演讲中提出了一个十分重要的理念：“一个核心，两个基本点”。其中两个基本点一个是保持合作化，一个是保持自动化，那么在麻利开发中，这两个理念也同样实用。合作化是进步生产力，自动化是进步生产效率，其指标都是为了继续低成本高效交付价值。那么一个开发团队在向麻利转型的时候，重点思考的就是这两个点：进步合作化、进步自动化。

进步合作化进步合作化，须要团队成员造成协同的理念，达成协同的共识。在传统 DevOps（开发运维一体化）中，把开发和运维的各个阶段串通了起来，强调的是开发人员和运维人员的协同。在开发团队外部，须要各个开发成员之间的协同。间接给团队灌输合作化的思维是难以扭转的，但能够采取以下的一些理论的措施，去促成团队的合作化口头。

1、多沟通和交换。在很多公司中，一个开发团队往往是坐在一起的，甚至是在一个绝对独立的会议室中围成一圈办公，这个就是一个最佳实际。在很多人的传统印象中，开发人员比拟少言寡语，他们喜爱专一在本人的世界里默默开发，不太违心与人交换，而这可能就是妨碍麻利的一个重要起因。在麻利中强调个体与互动，当大家可能坐在一起开发，可能 face to face 的去沟通，就能疾速解决很多问题。例如对以后的开发需要了解是否到位？以后开发遇到的 Bug 如何解决？以后的性能是否曾经有相干的实现能够复用？以后本人手头上的工作实现是否能够给予其余成员帮忙？如果大家都违心这样，就能施展出一个团队最大的价值，补齐了可能因木桶效应存在的短板，所有开发人员作为一个整体来交付代码，大家的常识和能力也失去了共享、晋升。在 Scrum5 个会议中的每日站会，也是为了增强沟通交流，拉齐信息，提出问题，寻求帮忙，其本质思维是一样的。而不足沟通和交换的团队，会造成极大的节约，如期待的节约、寻找信息的节约、移交的节约、尤其是对人才的节约（人的价值没有失去最大的展示和施展），对团队的效率影响是微小的。

2、多帮忙，少埋怨。一个开发团队中成员的技术水平不免参差不齐，作为资深的前辈，要可能在各个方面给予后辈帮忙和反对，而不是对其进行指责或埋怨。只有在团队中营造了一个互帮互助的踊跃的气氛，团队能力更快提高和成长，从而带来效率的晋升。

3、一起探讨选出适合的工作软件，制订适合的标准。开发团队中的每个成员在过往的经验中可能都有本人善于的软件和相熟的标准。然而在新的团队中，为了团队的整体合作，成员须要放下本人的偏好，独特探讨出最适宜整个团队的软件和标准，包含 IDE、编码标准、Git 提交标准、CICD 工具、公布流程标准等。通过统一的工作软件和标准，增强团队的合作程度。

4、依据状况灵便调整计划。在麻利宣言中有这样一句话：响应变动高于遵循打算。在一个开发团队中，不可能百分百的依照打算进行开发，并且每个开发人员都有本人善于的技术局部和不善于的技术局部，这就导致每个开发人员的开发效率都是变动的。如果严格百分百依照打算排期开发工作，那么势必会导致闲忙不平均的情况。而如果要把打算先做到完满，那更是一件不太理论的事并且还要为此付出微小的精力。所以更好的状况是，开发人员对 PBL 有一个初步的工作排期后，便可进行理论的开发，也就是“stop starting, start finishing”。在理论的开发过程中，依据工作的难易水平和本身的状况，灵便应答，并且团队成员之间相互交换帮忙，这样能力最大化团队的开发效率。

所以合作化实际起来并不难，要害还是团队成员是否在协同上达成共识，把团队放在集体之上，有荣辱与共的价值观和使命感。

进步自动化如果说合作化是思维上的转变，那么自动化就是口头上的转变。通常来说软件开发过程也是整个产品的交付周期中最漫长的过程，所以其中能用到哪些自动化工具和伎俩进行辅助，如何进步自动化程度尤为要害。从一百天交付一个版本，到一天交付一百个版本，这是一个质的飞跃。

其实，软件自动化的倒退通过了十分久的工夫和技术积淀。在以前，开发人员在本地编写好代码后，须要手动编译构建，打包成软件制品，而后通过脚本或者命令的形式部署到测试服务器上，有时还会因为服务器环境的问题造成部署过程中的各种异样。尽含辛茹苦部署胜利后，交给测试人员进行专业化测试。期间测试人员测试出的问题，开发人员修复后都要再反复一次上述的流程，耗时耗力，最初发现开发人员只有小局部工夫在真正写代码，更多工夫是在干一些重复性和繁琐性的工作。起初 Jenkins 工具的呈现，将继续集成（CI）和继续部署（CD）都做成了可自动化执行。开发人员在 Jenkins 上配置好后，只须要编写并提交代码即可，其余的步骤 Jenkins 都能帮忙解决。在部署环境上，因为开发人员是在本人的电脑上编写程序并调试运行，而后须要公布到服务器上，因为环境不统一导致的问题也总是让人头疼，起初呈现了 Docker 和 K8S 这些技术，解决了部署运维层面的对立和自动化治理问题。而把这些自动化的工具和技术联合起来，开发人员只须要把精力集中在代码解决上即可，前面的流程都能主动执行。

上述自动化技术更多聚焦于集成和部署层面，但其实，软件的自动化不止如此，在开发层面，其实也有着很多自动化技术。B/ S 架构衰亡后，更多开发人员开始做 Web 开发，然而大家可能要手写很多 Web 底层的代码，这些都是重复性的并且和业务没有关系，所以之后便呈现了许多 Web 框架，如 Java 中的 Spring 框架、C# 中的 ASP.Net 框架。这些框架把 Web 底层的技术进行了封装，通过一些简略的配置即可实现很多底层逻辑的主动实现。此外，当初的 IDE 越来越先进和智能，咱们通过很多插件，在开发的过程中可能主动帮咱们生成代码，主动帮咱们查看代码和纠错等等。

所以这些自动化技术、工具、框架的呈现，让开发人员可能更聚焦于业务的实现，加重各种简单繁琐的工作，从而晋升了交付价值的效率。而且随着大数据、AI 技术的愈发成熟，人们不再满足于自动化，而会向着更高层次的智能化后退。对于开发人员来说，如果可能把一些非核心性能的代码交给 AI 来实现，那无疑是生产效率的进一步飞跃。

合作化和自动化的联合

合作化和自动化是麻利开发团队转型的两大重点，并且不能只看其一，而要将其有机的交融。

我曾有过一段我的项目经验，尽管我的项目团队也是依照 Scrum 的形式进行组建的，每天都会开每日站会来拉齐信息、同步工作进度，开发过程中的各种 CICD 自动化工具也都有应用上，然而整个研发效力还是上不去，其实就是合作化和自动化没有很好的联合起来。每个人都盯着调配给本人的那些工作，遇到困难时不会被动去进行沟通，而是本人闷着解决，这样就拉低了整个团队的进度。代码提交的时候不足评审机制，所有人都想着连忙把本人的代码先提上去，因为晚提代码的人要解决抵触这种烦心事，谁负责的功能模块出问题就谁解决，没有一种相互合作的气氛。外表上看这种如同是有规章有制度的模式，但其实却背离了麻利的思维。

所以当咱们基于麻利的理念去做开发时，大家都会用自动化工具是一方面，更重要一方面是，大家都会用自动化工具进行合作开发。

麻利开发的瞻望

麻利开发的演进是一个过程，并且没有起点，它会永远朝着一个指标后退：让人的价值最大化。无论是团队协同，还是借助各种自动化工具辅助，实质上都是在一直地放大人的价值。随着开发团队逐步走向麻利，兴许他们每天产生的代码会缩小，但每天产生的价值肯定会减少。