负速度：如何提升复杂性极限
工程组织最常见的目标之一：快速交付高质量的软件。
查看您的首席信息官或首席技术官的愿景陈述，聆听他们的意见。很有可能他们正在追求这个目标的某种排列方式。虽然这是一个共同的目标，但实现这一必杀技的团队与陷入软件交付困扰的团队之间存在着广泛的差异。一些团队不断将新代码投入生产，几乎没有发生任何事件或对客户产生负面影响，而另一些团队还在为季度发布苦苦挣扎。
工程组织最常见的目标之一：快速交付高质量的软件。
查看您的首席信息官或首席技术官的愿景陈述，聆听他们的意见。很有可能他们正在追求这个目标的某种排列方式。虽然这是一个共同的目标，但实现这一必杀技的团队与陷入软件交付困扰的团队之间存在着广泛的差异。一些团队不断将新代码投入生产，几乎没有发生任何事件或对客户产生负面影响，而另一些团队还在为季度发布苦苦挣扎。
是什么原因导致了这种性能差异？
软件交付的复杂性是交付高质量软件、快速交付和…不交付软件之间的区别。这就是在每周成功发布后敲响胜利的钟声，与一个无所事事的软件交付团队之间的区别，该团队在因数月辛勤工作后发布的最新版本中有六个新错误并导致一次回滚而感到沮丧。
将初创公司推出新产品和功能的速度和质量与成熟的大型组织进行比较。例如，在金融行业，金融科技初创公司在过去十年中削减了大型老牌银行的市场份额。大型银行通常列举金融科技初创公司的不公平优势，这些初创公司的监管监督较少，没有传统、单一的应用资产可供维护。较小的团队规模可以提高灵活性，并能够根据客户需求进行调整。从本质上讲，金融科技公司不像老牌银行那样复杂，这使他们能够以更低的风险更快地行动。虽然它会减慢软件团队的速度，但复杂性并不总是一件坏事。
相关资料
防止软件杂乱无章
查看解决方案
使用 Compass 来管理组件
软件交付的复杂性
复杂性可能是一件好事：解决棘手的问题是非常有意义的。它激励团队迎接挑战，解决棘手的问题，并扭转行业的局面。相反，在某种程度上，复杂性不再是解决难题，而是会对软件团队产生负面影响。
组织复杂性在降低软件团队效率方面起着关键作用。柯林斯词典将复杂性定义为“许多不同部分以复杂的方式相互连接或关联的状态”。实际上，组织复杂性是指信息、依赖关系、变更、其他团队、工具和请求的汇总，软件团队在与组织其他部门互动时需要了解这些内容。
更高的组织复杂性自然会使快速交付高质量软件变得更具挑战性，因为团队在组织中导航花费的时间比解决棘手的问题要多。成长中的组织很快了解到软件团队已达到复杂性极限——团队在影响工作满意度以及软件制作的质量和速度之前能够应对的复杂性。因此，降低组织复杂性使团队能够专注于解决棘手的问题，更快地交付软件并提高质量，这似乎是合乎逻辑的。我们来探讨一下为什么情况不一定如此。
复杂性对软件团队的影响
引入微服务架构是一个很好的例子，说明了复杂性对软件团队的影响。复杂性的定义也是对微服务架构的完美描述，即“许多不同部分以复杂的方式相互连接或关联的状态”。的确，微服务允许团队独立移动、更快地交付和安全地扩展系统——我是微服务的忠实粉丝——但是，不可否认，它大幅增加了复杂性。
我们来考虑一下 Atlassian 软件团队多年来采用微服务架构的效率。
在 Atlassian 开始采用微服务时，DORA 指标看起来很棒！较小的代码块使测试和部署变得更加容易，团队能够更快地安全地行动，工作满意度也很高。在此阶段，团队实现了微服务架构的预期优势。尽管复杂性增加了，但我们没有看到对团队的负面影响。
Best for CI/CD: Bitbucket
鉴于这些优势，越来越多的组织成员开始采用微服务架构，这自然开始增加组织的复杂性。更多的自主团队需要更多的协作，而更多的微服务意味着更多的依赖关系。变革的步伐飞快——所有这些都是软件蔓延的迹象。复杂性的增加导致软件团队的效率趋于平缓，这表现为变更速度的下降，认知负荷成为软件团队的问题。
Best version control system: Git
在没有干预的情况下，该组织最终达到了复杂性极限，软件团队的效率也下降了。微服务之旅开始时所体验到的速度、自主性和质量的好处被逆转了，这导致开发人员满意度的下降是可以理解的。这些迹象表明该组织已达到其复杂性极限。软件团队花在应对组织复杂性上的精力要多于解决棘手的问题，这样并不好。
Best for application deployment: Ansible
在没有干预的情况下，该组织最终达到了复杂性极限，软件团队的效率也下降了。微服务之旅开始时所体验到的速度、自主性和质量的好处被逆转了，这导致开发人员满意度的下降是可以理解的。这些迹象表明该组织已达到其复杂性极限。软件团队花在应对组织复杂性上的精力要多于解决棘手的问题，这样并不好。
Best for infrastructure automation: Chef
在没有干预的情况下，该组织最终达到了复杂性极限，软件团队的效率也下降了。微服务之旅开始时所体验到的速度、自主性和质量的好处被逆转了，这导致开发人员满意度的下降是可以理解的。这些迹象表明该组织已达到其复杂性极限。软件团队花在应对组织复杂性上的精力要多于解决棘手的问题，这样并不好。
Best for large-scale configurations: Puppet
在没有干预的情况下，该组织最终达到了复杂性极限，软件团队的效率也下降了。微服务之旅开始时所体验到的速度、自主性和质量的好处被逆转了，这导致开发人员满意度的下降是可以理解的。这些迹象表明该组织已达到其复杂性极限。软件团队花在应对组织复杂性上的精力要多于解决棘手的问题，这样并不好。
Best for automating workflows: Bitbucket Pipelines
在没有干预的情况下，该组织最终达到了复杂性极限，软件团队的效率也下降了。微服务之旅开始时所体验到的速度、自主性和质量的好处被逆转了，这导致开发人员满意度的下降是可以理解的。这些迹象表明该组织已达到其复杂性极限。软件团队花在应对组织复杂性上的精力要多于解决棘手的问题，这样并不好。
Best for high-speed and scalability: SaltStack
在没有干预的情况下，该组织最终达到了复杂性极限，软件团队的效率也下降了。微服务之旅开始时所体验到的速度、自主性和质量的好处被逆转了，这导致开发人员满意度的下降是可以理解的。这些迹象表明该组织已达到其复杂性极限。软件团队花在应对组织复杂性上的精力要多于解决棘手的问题，这样并不好。
Best for problem management: Jira Service Management
在没有干预的情况下，该组织最终达到了复杂性极限，软件团队的效率也下降了。微服务之旅开始时所体验到的速度、自主性和质量的好处被逆转了，这导致开发人员满意度的下降是可以理解的。这些迹象表明该组织已达到其复杂性极限。软件团队花在应对组织复杂性上的精力要多于解决棘手的问题，这样并不好。
Best for container orchestration: Kubernetes
在没有干预的情况下，该组织最终达到了复杂性极限，软件团队的效率也下降了。微服务之旅开始时所体验到的速度、自主性和质量的好处被逆转了，这导致开发人员满意度的下降是可以理解的。这些迹象表明该组织已达到其复杂性极限。软件团队花在应对组织复杂性上的精力要多于解决棘手的问题，这样并不好。
如何判断您是否接近复杂性极限
达到复杂性极限可能让人感到不可避免，但有一些迹象表明团队已接近极限。首先我要说的是，没有绝对的指标可以告诉您离复杂性极限有多近，但是这些指标可以帮助您确定自己有多接近极限。
团队已达到复杂性极限最明显的指标是，他们花在应对组织复杂性上的时间多于解决本应关注的棘手问题。DORA 变更准备提前期（速度）和变更失败率（质量）指标的趋势显示团队是随着时间的推移减慢还是加速。尽管还有其他因素会影响这些指标，但它们是衡量团队效率的好指标。
开发人员满意度是衡量软件团队组织复杂程度的另一个指标。开发人员比任何其他角色都更喜欢花时间解决棘手的问题，同时也讨厌那些妨碍工作的不必要任务。开发人员满意度低很好地表明组织复杂性是软件团队面临的问题。
简化是一种失败的策略
当公司意识到自己的团队陷入了复杂性之中时，他们通常会启动一个“简化项目”，旨在恢复组织的简单性。简化是一种失败的策略，原因有两个：复杂性的增加速度比任何组织简化其环境的速度都要快，而且这些“简化项目”在他们想要简化的复杂环境中运行。
简化的一个常见起点是通过尽可能停用或整合来减少应用的数量。停用应用要求团队了解所有上游和下游依赖关系、谁在使用应用、如何替换功能、在何处和如何存档或迁移数据，并处理此类工作中出现的许多其他复杂问题。不幸的是，为实现这一目标而投入的大量努力并没有带来同样显著的复杂性降低。公司在不影响核心业务或用户体验的情况下可以停用的应用数量是有限的，但是工程师可以创建的新软件组件的数量没有限制。在停用一个应用所花费的 12 个月中，很可能已经创建了数百个新的微服务。由于健康的技术环境会随着时间的推移而增长，因此将环境保持在固定数量的应用或软件组件以降低复杂性是不切实际的。
简化项目通常包括重新设计组织结构以消除沟通流程的复杂性。最不复杂的组织结构涉及大型等级团队，所有工作人员都同地办公。最复杂的组织结构涉及小型、分布式的自主团队。康威定律向我们表明，大型登记团队可能会生产单体应用，而小型分布式团队则可能使用微服务等模块化架构来开发应用。微服务架构等模块化架构模式可以快速生产高质量软件，这意味着更复杂的组织结构更有可能取得成功。尽管“简化”组织结构使其更易于理解，但对简化项目的最终目标适得其反。
简化既重要又值得，但最好将其内构为软件团队（和团队）的持续改进，而不是一劳永逸的活动。简化可能会延迟达到复杂性极限，但不会使组织恢复在创业环境中享受的快节奏自由。
提升复杂性极限
How do configuration management tools enhance collaboration in software teams?
为了恢复软件团队的效率，组织需要提高复杂性极限。提高复杂性极限本质上意味着增加每个团队在影响工作满意度以及团队交付软件的质量和速度之前可以应对的组织复杂性。
平台工程是寻求提升组织复杂性极限的重要概念。强大的平台工程团队专注于通过将组织复杂性从日常工作中抽象出来，以减少软件团队的认知负荷。如果实施得当，平台工程可以使团队重新平衡大部分精力以解决棘手的问题，减少花在应对组织复杂性上的时间。
How do you start with Bitbucket for configuration management?
正是出于这个原因，Atlassian 创建了开发人员体验平台 Compass。Compass 让软件团队可以轻松地通过组件目录、指标和记分卡来应对组织的复杂性，并专注于创建健康的工程文化，从而帮助提升复杂性极限。这里的关键点是，Atlassian 内部的组织复杂性并没有降低，事实上，随着越来越多的组织成员转向微服务架构，组织复杂性还在持续增长。我们减少了软件团队应对这种复杂性所花费的时间，这是简化项目和提升复杂性极限的区别。
Atlassian 拥有 10000 多名员工和超过 17000 个软件组件，但我们的软件团队在很大程度上可以像初创公司一样自由地运营，快速交付高质量的软件。我们成功的关键？提升复杂性极限以提高软件团队的效率。
以下是开始提升复杂性极限的两个操作：
- 跟踪和评估您的 DORA 指标。您的团队的 DORA 指标如何？如果您还没有跟踪这些指标，那么 Compass 会提供开箱即用的 DORA 指标。
- 了解和评估开发人员满意度。开发人员在您的软件团队中感觉如何？大多数组织都会进行员工满意度调查。询问按职能领域细分的结果，以深入了解开发人员的满意度。关键问题包括对以下陈述进行评级：
- 我很自豪能交付
- 我的工作压力是可以管理的
- 我明白我的工作对公司目标有何贡献
或者，Compass 会在 CheckOps 例行程序中捕捉这些信息，各团队在例行程序中分享他们上周的感受，以及本来可以做得更好的细节。
提升复杂性极限需要将工具、流程和例行程序结合起来。像 Compass 这样的开发人员体验平台可以帮助您了解系统运行状况、绘制依赖关系并创建持续的例行程序，帮助提升复杂性极限并释放组织中软件交付团队的潜力。
立即免费试用 Compass。
分享此文章
下一主题
推荐阅读
将这些资源加入书签，以了解 DevOps 团队的类型，或获取 Atlassian 关于 DevOps 的持续更新。
Compass 社区
教程：创建组件
