技术债务

技术债务是软件开发的组成部分。大多数拥有遗留代码的团队都有某种技术上的债务，我们也是如此。我们的大多数移动产品都有一定的技术债务。

由于我们将速度降低到以前的能力的50％，因此我们有一定的喘息空间来承担较小的技术债务，这是在团队给定速度下进行计划的一部分。对于所有团队来说，决定将开发速度降低一半是一个艰难的决定。我们与产品管理团队紧密合作，优先处理技术债务和工程改进以及新功能，以确保我们的产品长期成功。

团队结构

当我们开始DevOps转型之旅时，QE团队独立于开发人员运作。质量工程师负责测试产品。但是，这种安排在DevOps结构中不太适合。

管理层意识到了这个问题，改变了团队结构。质量团队与开发团队合并。每个人都专注于提供高质量的产品，而质量是团队中每个人的责任。QE与开发人员结对，向相同的经理汇报工作，并在设计和开发开始时就致力于质量。我们创建了DevOps风格的团队。DevOps团队是功能齐全的团队，能够构建，测试，具有基础架构和管理服务技能。如果您是像VMware这样的大型组织，则无需为每个团队创建最基本的技能，而可以继续拥有一个平台团队来满足关键项目和跨多个项目的共同需求。但是，请确保使每个团队都能自行管理应用程序和服务。

技能和知识

当管理层更改团队结构以使每个人对产品质量负责时，说起来容易做起来难。技能和产品知识方面存在差距。例如，开发人员不知道如何创建测试用例。QE团队不了解产品代码对代码开发的贡献。

为了解决这个问题，我们开始提高团队技能和交叉技能。在代码开发和开发人员方面进行QE培训，以考虑质量，测试计划，测试策略以及整体采用质量思维方式。这样做的目的不是让QE开始开发代码，也不是让开发人员开始全职测试，而是要获得所需的技能以更加熟悉产品和代码。此外，我们希望拥有编程方面的专业知识，以开始构建其团队所需的工具和系统。知识共享，结对编程，跨团队技能开发简化了转换的过程。

自动化

DevOps涉及整个SDLC生命周期中的早期反馈，而自动化在提供早期和一致的反馈中扮演着非常重要的角色。没有自动化，就无法实现DevOps的发展。当我们开始时，就已经有了自动化，但是，自动化没有得到有效利用。由于对自动化脚本缺乏信任，测试结果被忽略了，并且开发人员没有为自动化编写任何测试脚本（少数单元测试除外）。

我们做了什么？我们回顾了我们的自动化测试策略。为了向左移动，我们选择了与开发人员所使用的接近的工具和技术，以便他们可以使用自己喜欢的语言，IDE和工具编写测试脚本。这在很大程度上帮助了我们，开发人员逐渐能够开始编写测试脚本，质量工程师开始修复产品缺陷。它还为我们提供了测试自动化的稳定性。我们测试框架的更好的设计和架构使每个团队成员都能够为实现质量目标做出贡献。

环境

自动化的瓶颈之一是按需测试环境的可用性，因为Workspace ONE是一个非常复杂的产品，并且具有许多相互依存关系。对于每个团队来说，要在每次测试运行中按需创建这样的环境并不容易。

这是我们的基础架构团队介入的地方，并开始从事一个项目，以便为每个团队提供按需测试环境。整个解决方案基于自助服务门户和REST API。我们所有人很容易采用和使用API与自动化集成并创建测试环境。

跨团队协作

如上所述，Workspace ONE是一款非常复杂的产品，具有数百个相互依赖关系，并分为数百个模块。团队经常在孤岛上工作，专注于自己的交付物，而没有考虑共享最佳实践或创建可重用的代码。这不是一个容易解决的问题，需要文化上的转变。

解决方案是什么？我们组成了一个小团队，开始团队之间的协调，调整发布周期，在团队之间重用代码并改善代码文档。示例之一是重新创建基于微服务体系结构的测试框架，以便每个团队可以共享自己的代码脚本以避免重复。成立了一个跨平台团队来分离和编写可在产品线中使用的可重用代码。

结论

通过应用上述解决方案，我们能够做出许多积极的改变。去年，当我们回顾并评估了移动SDK的结果时，我们发现iOS的发布速度提高了50％，Android的发布速度提高了25％。计划外的补丁和次要版本在iOS上降低了58％，在Android上降低了29％。我们减少了上报次数，提高了生产率，增加了团队之间的协作和质量，以及许多其他无形的收益。

不要害怕变化。正如*马丁·福勒（Martin Fowler）*所说

（编辑：柳州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!