Управление изменениями и управление разработкой ПО – вместе или врозь?

Разработка ПО

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

 

Этой деятельностью организации управляют для того, чтобы получить больше ценности и возможностей при меньших затратах. Типичные запросы, поступающие на вход этой цепочки (потока):

• Изменение программного обеспечения (например, изменение или создание новой функциональности в программном обеспечении).
• Реализация изменений с помощью инструментов no-code или low-code, то есть через конфигурирование имеющихся информационных систем (например, добавление атрибутов к объекту какой-либо ИТ-системы, включая модификацию пользовательского интерфейса, экранных и печатных форм).
• Реализация изменений путём переобучения или дополнительного обучения ранее созданных языковых моделей (например, изменение потребительских характеристик чат-бота через обучение его на новом массиве данных).

При этом поступающие запросы могут быть как простыми (например, одна пользовательская история), так и комплексными (эпик, требующий декомпозиции). Кроме того, запросы могут быть изолированными (ничего не требуется, бери и делай) и взаимозависимыми (невозможно сделать данный запрос, пока не будет выполнен какой-либо другой запрос).

 

Управление изменениями

Также во многих организациях, использующих ИТ, определена и формализована деятельность по управлению изменениями. Её можно в общем случае представить так:

 

Организации управляют изменениями для того, чтобы снизить риски (так нам рассказывал ITIL 2 и ITIL v3), а также чтобы увеличивать долю успешных изменений при заданных качестве и скорости (так учит ITIL 4). Примеры запросов на изменение включают:

• Изменение исключительно аппаратного обеспечения (например, установка дополнительного модуля памяти в физический сервер, замена диска в системе хранения данных).

• Изменение характеристик виртуальных сред (например, изменение объёма доступного дискового пространства виртуального сервера, создание виртуального кластера).

• Реализация изменений через конфигурирование инфраструктуры (например, подключение нового узла к системе мониторинга).

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

 

Это точно разное?

Традиционно два этих процесса в организациях различны. Они имеют разных ответственных и разные регламенты. Отчасти это обусловлено тем, что все основные источники знаний и лучших практик (ITIL, COBIT, ISO 20000) с начала 2000-х годов описывают их как отдельные процессы. При этом условный ITIL исторически близок к управлению инфраструктурой (а потому делал акцент на управлении изменениями, а не разработкой ПО), а методологии разработки ПО исторически мало что содержат про управление изменениями. Два мира, два процесса.

Тем не менее, у них много общего – даже слишком много:

1. Схожая суть того, что приходит на вход. Фактически, на вход поступает потребность в изменении чего-либо. Способ изменения (через ПО, через “железо”, через комбинацию того и другого) вторичен.
2. Практически идентичная суть того, что на выходе – изменение в среде эксплуатации. Большое или маленькое, простое или комплексное, не важно.
3. Одинаковая суть первых трёх этапов обработки: анализ/проектирование, реализация/выполнение, тестирование/валидация. Разница лишь в четвёртом этапе, развёртывание/тиражирование. Этот этап, как правило, требуется для распространения изменений в ПО и редко необходим для выполнения запросов на изменение.
4. Сильно совпадающая цель деятельности – реализация ценности через изменение среды эксплуатации.
5. Идентичный набор метрик, как связанный с процессом (скорость, объём работы), так и с результатом (доля неуспешных изменений или дефектов).
6. Одинаковые особенности, связанные с декомпозицией: комплексные запросы приходится разбивать на составные части.
7. Так же одинаковые особенности в области взаимозависимостей и связей: запросы могут быть связаны как между собой, так и с другими запросами.

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

 

 

Как сделать в РИТМе?

Сейчас активно идёт разработка РИТМа – рациональной ИТ-методологии. Предлагается в процессной модели РИТМа описывать и регламентировать оба вида деятельности как единый поток создания ценности.

 

Следствия такого решения:

1. В РИТМе не будет описано отдельного процесса управления изменениями, совсем. Все изменения (как ПО, так и инфраструктурные), будут описываться и реализовываться через единый производственный поток.
2. Нюансы отдельных видов изменений (кодирование; low-code/no-code; настройка инфраструктуры; апгрейд сервера) могут быть описаны внутри четырёх этапов, приведённых выше (анализ/проектирование, разработка/настройка, тестирование/валидация/приёмка, распространение/тиражирование).

Так как это важное архитектурное решение, то архитекторы и авторы РИТМа решили провести исследование. Что об этом радикальном предложении думают профессиналы управления ИТ?

Заполните, пожалуйста, короткий опросник. Ваше мнение имеет значение!

 

Если по какой-то причине форма выше не отображается, то перейдите, пожалуйста, по ссылке.

Благодарю за участие!