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

Процесс «управление релизами», один из стека процессов ITSM, как раз и предлагает решение для формальной приоритизации и группировки запросов пользователей (запросов на изменения, инцидентов) в общие пакеты доставки — «релизы».

В данной статье кратко раскрываются следующие темы:

• применимость процесса — когда имеет смысл его внедрять
• основные этапы процесса, активности, вовлеченные ресурсы и результаты
• планирование релизов: календарь, объем, параллельное выполнение
• некоторые проблемы доставки в релизах

Применимость процесса

Когда целесообразно применять процесс, в дополнение к управлению инцидентами и управлению изменениями? Разумеется, в каждом случае набор критериев разный, но перечисленные ниже сценарии — хороший повод задуматься о релизах:

• Начальный период постпроектной поддержки: значительное количество изменений, проблемы с приоритизацией, необходимость эффектично упрявлять ожиданиями заказчика
• Процесс поддержки продукта: необходимость организовать процесс, оптимизирующий использование всех доступных ресурсов в рамках существующего бюджета.
• Большой процент запросов на изменения затрагивают пересекающиеся предметные области или приводят к техническим зависимостям — необходимо явно группировать изменения с целью оптимизации работ по разработке или тестированию.
• Процесс непосредственной доставки разработанных изменений продукта на продуктив — “дорогой”, с любой точки зрения: от координации, до непосредственных расходов на распространение изменений.

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

Этапы процесса

Процесс состоит из последовательности этапов. В разных реализациях процесса некоторые этапы могут быть объединены, или могут называться по другому — но общий принцип сохраняется

1. Draft

Активности:
Подбор запросов на изменения и инцидентов в список того, что планируется делать, проводится начальная приоритезация, анализ взаимозависимостей и предварительная оценка трудозатрат на анализ и разработку.

Результат:
Все требования содержат высокоуровневую оценку сложности и рекомендации по группировке в релиз на основании области изменений и/или технических зависимостей.

С учётом этих оценок и рекомендаций, на основании бизнес-приоритетов заказчика и доступных ресурсов исполнителя, к анализу принимается группа запросов на изменения и инцидентов. Не вошедшие в этот список обращения возвращаются в общий пул и будут оценены в рамках следующих релизов

Ресурсы:

• Аналитики (ведущий аналитик)
• Заказчики
• Менеджер релиза

2. Scope

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

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

Ресурсы:

• Аналитики
• Заказчики
• Разработчики (Тех лид)

3. Approval

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

Результат:
Сформировано финальное содержание релиза.

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

Ресурсы:

• Заказчики
• Менеджер релиза

4. Work in progress

Активности:
Разработка и исправление дефектов для всех заявок, вошедших в финальное содержимое релизов. Внутреннее тестирование и подготовка к приемочному тестированию.

Результат:
Заявки, включенные в содержание релиза — разработаны. Передача заказчику на приемочное тестирование.

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

Ресурсы:

• Разработчики
• Аналитики

5. Testing

Активности:
Проведение приемочного тестирования заказчиком, исправление выявленных ошибок, проведение необходимых доработок (по согласованию)

Результат:
Содержимое релиза протестировано, принято заказчиком, и готово к распространению.

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

Ресурсы:

• Заказчики
• Аналитики
• Разработчики

6. Deployment

Активности:
Пакет изменений передается в эксплуатацию. Публикация новой версии продукта в продуктивной среде.

Результат:
Изменения перенесены в продуктивную среду и доступны заказчику

Ресурсы:

• Служба эксплуатации

7. Closure

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

Результат:
Формальное завершение работ. Улучшения процесса.

Ресурсы:

• Менеджер релиза

Планирование релизов

Как и любую активность, релизы нужно планировать. К счастью, управление релизами — это процесс, и поэтому при планировании можно рассчитывать на то что этапы, их взаимосвязь не меняются. Однако для планирования расписания релиза необходимо принципиально определиться с подходом к доставке:

1. Если, внедряя релизы, вы планируете также обеспечивать регулярность выхода новых версий — то, скорее всего, и длительность этапов должны быть зафиксированы на некоторых оптимальных значениях.
   
   
2. Если же релизы будут использоваться только как группировка отдельных запросов на изменение, а общая длительность релиза должна быть оценена исходя из объемы работ и ресурсов — оценка длительности этапов ничем принципиально не отличается от планирования любого проекта.

Планирование релизов с фиксированной длительностью

Это планирование проводится в самом начале внедрения процесса, и относится к процессу, как таковому — а не к отдельным релизам, поскольку длительность отдельного релиза меняться не будет.

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

Что будет меняться определенно — это ресурсы, доступные на каждом из этапов, в разных релизах (люди болеют, ходят в отпуск). Но с учетом перечисленных ограничений планирования это будет сказываться только на объем доставляемых изменений, а не на календарный план.

В целом, планирование релизов с фиксированной длительностью, и зависимостью объема доставки от наличия ресурсов — задача относительно несложная. В результате, процесс получается максимально предсказуемый и ритмичный, во многом близкий к Scrum.

Планирование релизов от объема доставки

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

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

Относительно сроков доставки, релизы, планируемые от объемов, также не предлагают заказчику большую определенность по сравнению с проектным подходом:

• длительность каждого релиза изначально может быть оценена только на основании начальной оценки — вероятность ошибки велика
• задержки работ на каждом из этапов процедурно не корректируется уменьшением содержания — задержки накапливаются

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

В дальнейшем будем обсуждать только детали, касающиеся релизов с фиксированной длительностью.

Календарное планирование релиза

Поскольку этапы определены, их взаимосвязи зафиксированы, и длительность каждого этапа будет неизменной, календарное планирование одно релиза не представляет сложности. Основной вопрос, с которыми необходимо определиться — длительность каждого из этапов.

Для этого можно попробовать использовать следующие данные, которые у вас могут быть на основании завершенного проекта:

• примерное соотношение между ресурсами аналитиков и разработчиков при работе на одну задачу. Например, «если аналитик потратил на требования 5 человеко*дней, то затраты на разработку и тестирование составят примерно 10 человеко*дней».
• аналогично — соотношение между анализом требований, и длительностью приемочных испытаний
• состав команды: количество аналитиков, разработчиков, тестировщиков.

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

Длительность этапов «Deployment» и «Closure» обычно устанавливается фиксированной, поскольку они на прямую не зависят от объема изменений. Разумеется, если зависимость в вашем случае существует — она должна учитываться.

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

В любом случае — используйте инструменты, предназначенные для календарного планирования (как, например MS Project). Особенно это важно при создании календаря с пересекающимися во времени релизами, поскольку нужно будет тщательно контролировать загрузку ресурсов.

Одновременное выполнение нескольких релизов

Как видно из описания этапов релиза, на каждом из этапов вовлечены разные ресурсы и профиль загрузки — не однородный:

• Аналитики — максимально загружены на этапе Scope и Test, менее загружены на этапах Draft и Work in progress. Во время Work in progress аналитики часто вовлечены в работу с Разработчиками, в случае необходимости поясняя требования.
• Разработчики — максимально загружены в период Work in progress. В зависимости от реализации процесса, на этом этапе ведётся работа по запросам на изменения, вошедшим в утвержденное содержание релиза. При этом в остальное время могут заниматься исправлением дефектов, рефакторингом кода, и прочими полезными делами.
• Заказчики — вовлечены в период сбора требований (Scope) и приемочного тестирования (Testing). В остальные периоды — вовлечение заказчика незначительное.

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

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

В случае, если вы строите процесс управления релизами с параллельными этапами — календарный план релиза должен учитывать перекрытия и загрузку ресурсов. Вполне возможно, что качественное расписание параллельно выполняемых релизов будет накладывать дополнительные требования на состав команды — так чтобы общая «выработка» Аналитиков и Разработчиков с учетом длительности этапов были равны.

Определение содержимого поставки при фиксированной длительности релиза

Посмотрим, из чего складывается ожидаемый объем содержимого релиза.

Фаза анализа требований

Объем заявок на изменения, которые могут быть проанализированы к рамках этапа «Scope» представляют максимальную неопределенность. Действительно — пока аналитик не начнет анализировать заявку, не поймет о чем идет речь, сказать сколько займет полный анализ очень сложно. Конечно, предварительный анализ заявок на стадии «Draft» поможет дать первую оценку, но ее можно использовать для распределения заявок между аналитиками — в зависимости от их специализации и опыта. Кроме того, необходимо учитывать, что аналитик вовлечен в приемочное тестирование — так что, анализом требований и передачей в разработку нагрузка на аналитика в рамках релиза не заканчивается.

Таким образом, первая оценка содержимого релиза может быть дана в терминах «количество заявок на аналитика в релиз». Наиболее пессимистичная оценка «1 заявка на изменение на аналитика в релиз» — с нее и стоит начинать. После того, как статистика по «производительности» аналитиков набрана — оценка содержимого станет более точной.

Подготовка технического решения

Работа по анализу технической реализации, на основании собранных требований, также требует времени и усилий — от группы разработки. Как правило, лидер группы отвечает за подготовку технической спецификации и оценки затрат на разработку.

Может случиться, что подготовка спецификаций занимает больше положенного времени и не укладывается в рамки стадии «Scope» — тогда запрос на изменение автоматически «выбывает» из содержимого текущего релиза.

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

На основании подготовленных требований, технической спецификации получается достаточно точная оценка затрат на разработку — именно она и будет использоваться далее.

Фиксация содержимого проекта

Оценка затрат на разработку, доступные ресурсы Разработчиков, доступность Заказчика для участия в приемочном тестировании — все это определяет финальное содержание релиза.

Итак, без учета переноса готовых запросов с предыдущих релизов — объем содержимого релиза ограничен сверху количеством проанализированных заявок (определяется ресурсами Аналитиков). Ограничения по ресурсам Разработчиков могут дополнительно сокращать объем релиза.

Известные проблемы

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

Переключение контекста при параллельных релизах

При планировании параллельных релизов возникает ситуация, когда все ресурсы — Аналитики, Заказчики и Разработчики должны «переключаться» между релизами. В частности, сценарии переключения следующие:

• Аналитик закончил анализ (стадия «Scope») для релиза R1 и переключился на сбор анализ для следующего релиза R2. Ему прийдется переключится обратно в контекст релиза R1 для поддержки приемочного тестирования.
• Аналогичный шаблон переключений — у Заказчика, особенно, если его запросы на изменения идут в последующих релизах.
• У разработчиков переключение контекста выражено меньше — только в случае если нужно переключаться между новой разработкой и старыми дефектами.

«Переключение контекста — это плохо». Действительно, это приводит к снижению эффективности, потере фокуса на задаче, и может привести к задержках на ключевых этапах процесса.

В качестве вспомогательной меры по минимизации влияния переключения приходится дополнительно их координировать — это нагрузка на менеджера релизов.

Ресурсные конфликты при нарушении календаря релиза

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

Исходя из конструкции этапов релиза и перехода между ними — наибольший негативный эффект имеет задержка этапов разработки и тестирования. Фазы анализа («Draft», «Scope», «Approval») имеют возможность понизить содержание релиза за счет переноса неоконченных заявок на следующий релиз — и это воспринимается заказчиком, обычно, легче, чем перенос из после утверждения содержания релиза.

Взятие «повышенных обязательств»

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

В качестве меры по можно использовать пессимистичную оценку объема ресурсов при фиксации содержимого релиза на этапе «Approval». Вообще тема «недооценки задачи/переоценки собственных сил и как с этим бороться» — очень дискуссионная. И решение очень сильно зависит от организационного окружения, в котором работает команда.

Реализация «больших» задач

Довольно часто в ходе анализа выясняется, что объем задачи не помещается во временные рамки этапа «Work in progress» — требуемый объем не получается разработать и доставить в рамках одного релиза.

Если увеличить ресурсы Разработчиков не представляется возможным, остается два возможных путей решения этой проблемы:

• дробление исходной задачи на две или более — так что каждая из них независима с точки зрения доставки и распределение из по нескольким релизам, с учетом бизнес-приоритетов
• если дробление невозможно по техническим или иным причинам — формальный перенос задачи в более дальний релиз, и работа над полным скопом в течение двух и более релизов

Субъективно, первый вариант является более предпочтительным, поскольку позволяет сохранить регулярность доставки и представить хотя-бы часть функциональности в текущем релизе.

Однако, вполне возможно, второй вариант может быть более предпочтительным с точки зрения загрузки ресурсов Разработчиков.

Устранение дефектов в контексте релизов

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

С другой стороны, устранение дефектов может быть утверждено заказчиком в качестве априорно наиважнейшей задачи — таким образом, ресурсы на устранение дефектов прийдется выделять в приоритетном порядке.

В любом случае, необходимо учитывать наличие дефектов при оценке доступных ресурсов, которые можно выделить на содержимое релизов.

• В качестве первого варианта можно оценить потенциальный объем дефектов за релиз и ресурсы затрачиваемые в среднем на один дефект. На эту оценку уменьшаются ресурсы, выделяемые на новые запросы на изменения.
• Альтернативным подходом может служить выделение группы ресурсов, отвечающих только за устранение дефектов. Но скорее всего — это целесообразно только в случае большого количества серьезных дефектов

Вне зависимости от подхода к оценке необходимых ресурсов, включение задач по устранению дефектов в содержимое релизов может оказаться полезным при анализе технических зависимостей всех изменений, над которыми работает команда.

Заключение

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

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