研发效能认证学员作品：谈敏捷开发团队转型中的协作化与自动化丨IDCF

共 3810字，需浏览 8分钟

· 2023-06-21

星标关注，第一时间获取IDCF社区资讯，了解活动动态，福利多多不容错过！

作者：
杨凌宇（现就职中国电信研究院）
研发效能（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自动化工具也都有使用上，但是整个研发效能还是上不去，其实就是协作化和自动化没有很好的结合起来。每个人都盯着分配给自己的那些任务，遇到困难时不会主动去进行沟通，而是自己闷着解决，这样就拉低了整个团队的进度。代码提交的时候缺乏评审机制，所有人都想着赶紧把自己的代码先提上去，因为晚提代码的人要解决冲突这种烦心事，谁负责的功能模块出问题就谁解决，没有一种互相协作的氛围。表面上看这种好像是有规章有制度的形式，但其实却背离了敏捷的思想。

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

敏捷开发的展望

敏捷开发的演进是一个过程，并且没有终点，它会永远朝着一个目标前进：让人的价值最大化。无论是团队协同，还是借助各种自动化工具辅助，本质上都是在不断地放大人的价值。随着开发团队逐渐走向敏捷，也许他们每天产生的代码会减少，但每天产生的价值一定会增加。