Как укротить бесконтрольное разрастание набора ПО

Поначалу распознать симптомы бесконтрольного роста программного обеспечения бывает нелегко. Они могут проявляться в виде раздражающих мелочей, которые отодвигаются на второй план в пользу более высоких приоритетов. Тем не менее, если не остановить бесконтрольный рост программного обеспечения, он может навредить командам разработчиков и увеличить умственную нагрузку, снизить вовлеченность команд и свести к нулю преимущества архитектуры на основе слабосвязанных компонентов. Как говорится, лучший момент для посадки дерева был 20 лет назад, второй лучший момент — сейчас. Будущий успех зависит от укрощения бесконтрольного роста программного обеспечения до того, как это станет проблемой.

Ниже перечислены три признака разрастания ПО, а также шаги, которые вы можете предпринять для обуздания хаоса и создания инновационной и динамичной среды разработки, раскрывающей потенциал команд.

Одним из первых признаков разрастания ПО может служить тот факт, что инциденты, исходя из обзора последствий инцидентов (post incident review, PIR), все чаще случаются из-за изменений в вышестоящих системах. Растущее число микросервисов и увеличение объема изменений могут вносить сложности в устоявшийся порядок сотрудничества и координации изменений между разработчиками. Даже если в одном модернизированном приложении изменения начинают происходить чуть чаще, например не ежемесячно, а еженедельно, то общее число релизов за месяц может вырасти в сотню раз. Поэтому неудивительно, что разработчики вынуждены перестраивать формат сотрудничества. Вероятность инцидентов в пользовательской среде тем выше, если устоявшийся порядок совместной работы не масштабируется под стремительно меняющуюся среду разработки.

Однако если найти способ, как ненавязчиво оповещать разработчиков об изменениях в выше‑ и нижестоящих системах, то можно взять под контроль последствия разрастания ПО. В Atlassian мы используем Compass — портал для разработчиков, который позволяет командам ориентироваться в распределенных архитектурах. С его помощью можно отправлять другим командам встроенные в приложения уведомления об изменениях, если последние могут привести к поломкам в выше‑ или нижестоящих службах. Команды тех служб, которые зависимы от исходного приложения, могут подтверждать получение уведомления. Таким образом они сообщают инициатору о том, что ознакомились с изменением. Так появляется возможность координировать свои действия, если ожидается, что изменение может оказаться проблематичным, а также снижается вероятность неожиданных негативных последствий уже в пользовательской среде. Поскольку в динамичных средах разработки инциденты рано или поздно случаются, координация участников команд во время инцидента крайне важна для быстрого восстановления работы служб.

Анализ инцидентов, произошедших по причине изменений в вышестоящей системе, выявляет следующую типичную закономерность. Время восстановления работы служб зависит от того, насколько быстро удастся локализовать то самое проблемное изменение, а также найти соответствующую команду или контактное лицо. Логично предположить, что, если со временем ускорить локализацию проблемных изменений, то удастся сократить и среднее время восстановления работы службы (mean time to restore, MTTR). Это сделать гораздо труднее в слабосвязанной архитектуре, где службы образуют сложную иерархию зависимостей, и причина проблемы может крыться где угодно. Лица, реагирующие на инцидент, обычно прочесывают логи и историю изменений, чтобы локализовать изменение, вызвавшее проблему. В динамичной среде разработки это похоже на раскопку муравейника в поисках ужалившего муравья.

В Atlassian мы используем ленту событий Compass, чтобы снизить MTTR. В ней представлены все события в вышестоящих системах, а также информация о команде, отвечающей за систему. Время на приоритизацию проблемы существенно снижается, так как это помогает совместным усилиям разработчиков при реагировании на инцидент. Инциденты случаются всегда, однако локализация проблемного изменения в вышестоящей системе в сжатые сроки крайне важна для смягчения негативных последствий и быстрого восстановления работы служб.

Переход на слабосвязанную архитектуру — это ключ к одной из составляющих высокой эффективности команды и ее удовлетворенности, а именно к возможности движения вперед с достаточной степенью автономии. Если не уделить достаточного внимания разрастанию ПО, то оно может свести на нет эти выгоды, из‑за чего команда разработчиков может стать перегруженной, неэффективной и подавленной. Если побеседовать с разработчиками, чаще всего они жалуются на то, что «все идет хорошо, пока не возникнет необходимость взаимодействовать с другой командой». Ситуация усугубляется в связи с разрастанием программного обеспечения. Поскольку среда разработки быстро расширяется и меняется, разработчикам становится все труднее отслеживать контактных лиц в выше‑ и нижестоящих системах. В конечном итоге это приводит к снижению темпа и упадку духа, ведь команды стремятся выпускать релизы своевременно.

Представим такую ситуацию. Бригада «А» и бригада «Б» еженедельно закрывают в Jira одинаковое количество задач одинаковой сложности. Бригада «А» тратит 90 % усилий на разработку и поставку нового функционала пользователям, в то время как бригада «Б» тратит 30 % усилий на новый функционал и 70 % на координацию с многочисленными вышестоящими службами, от которых она зависит. Производительность обеих бригад одинакова, но именно бригада «А» будет считаться более эффективной. Разрастание ПО усиливает необходимость в координации между командами. Нахождение разумных подходов к тому, каким образом вовлекать автономные команды в сотрудничество, — ключ к раскрытию преимуществ слабосвязанной архитектуры.

В быстрорастущей, динамичной среде разработки возможность самостоятельно находить информацию очень важна для эффективности команд и их удовлетворенности. Решить эту задачу можно путем создания единого каталога программных компонентов с децентрализованным управлением. В таком каталоге каждая команда отвечает за создание и поддержание в актуальном состоянии служб, которые она разрабатывает. В традиционно сложившихся средах разработки, как правило, имеется централизованный каталог, которым управляет специальная команда. Однако такое положение дел не поспевает за скоростью изменений в распределенной среде, и командам приходится создавать «шпионские заметки» в Wiki о контактных лицах и о том, каким образом привлечь их к взаимодействию. Мы в Atlassian поняли, что децентрализованный подход позволяет сократить количество потраченных впустую и неучтенных усилий среди команд, дает возможность самостоятельно находить информацию и создает среду, где разработчиков привлекают по запросу. Контроль за разрастанием ПО благодаря возможности самостоятельно находить информацию о выше‑ и нижестоящих зависимостях — отличный способ улучшить коллективную эффективность и получить сопутствующие выгоды, такие как субъективная удовлетворенность и вовлеченность команд.