- PVSM.RU - https://www.pvsm.ru -
После формального окончания проекта — работа не заканчивается, а только начинается. Необходимо реализовать функционал который не вошёл в основное содержание проекта, исправить некритичные ошибки которые не препятствовали запуску, и обслуживать поток изменений и инцидентов, сопутствующих процессу эксплуатации. При этом, необходимо организовать процесс таким образом, чтобы учитывать приоритеты запросов, технические зависимости, оставлять время на анализ требуемых изменений.
Процесс «управление релизами», один из стека процессов ITSM, как раз и предлагает решение для формальной приоритизации и группировки запросов пользователей (запросов на изменения, инцидентов) в общие пакеты доставки — «релизы».
В данной статье кратко раскрываются следующие темы:
Когда целесообразно применять процесс, в дополнение к управлению инцидентами и управлению изменениями? Разумеется, в каждом случае набор критериев разный, но перечисленные ниже сценарии — хороший повод задуматься о релизах:
Кроме того, при определенных условиях планирования и организации этапов релизов — весь процесс доставки можно максимально приблизить к методике Scrum (регулярная поставка изменений, с наивысшей ценностью для заказчика), таким образом постепенно переходя к использованию гибких подходов в организациях, не очень к этому предрасположенных.
Процесс состоит из последовательности этапов. В разных реализациях процесса некоторые этапы могут быть объединены, или могут называться по другому — но общий принцип сохраняется
Активности:
Подбор запросов на изменения и инцидентов в список того, что планируется делать, проводится начальная приоритезация, анализ взаимозависимостей и предварительная оценка трудозатрат на анализ и разработку.
Результат:
Все требования содержат высокоуровневую оценку сложности и рекомендации по группировке в релиз на основании области изменений и/или технических зависимостей.
С учётом этих оценок и рекомендаций, на основании бизнес-приоритетов заказчика и доступных ресурсов исполнителя, к анализу принимается группа запросов на изменения и инцидентов. Не вошедшие в этот список обращения возвращаются в общий пул и будут оценены в рамках следующих релизов
Ресурсы:
Активности:
Проводится детальный анализ и оценка, подготовка спецификаций по изменениям, отобранным на основании приоритетов заказчика Отобранные требования полностью проанализированы и утверждены заказчиком, технические спецификации проработаны, детальная оценка трудозатрат проведена.
Результат:
Полностью проанализированные запросы на изменения подготавливаются к финальному подтверждению содержания релиза. Запросы, для которых анализ или согласование не завершено — возвращаются в общий пул. Они — кандидаты на анализ (окончание анализа) в рамках следующего релиза
Ресурсы:
Активности:
Получение подтверждение ресурсов от исполнителей (для разработки) и заказчиков (дляд тестирования). Оценка общего бюджета релиза (если применимо). Финальное согласование с заказчиком содержания релиза, исходя из готовности отдельных запросов, приоритетов, оценённого бюджета, доступных ресурсов.
Результат:
Сформировано финальное содержание релиза.
Все запросы на изменения, входящие в финальное содержание релиза передаются в разработку. Остальные запросы на изменения возвращаются в общий пул. Поскольку эти изменения имеют высокую степень готовности — они кандидаты в следующий релиз
Ресурсы:
Активности:
Разработка и исправление дефектов для всех заявок, вошедших в финальное содержимое релизов. Внутреннее тестирование и подготовка к приемочному тестированию.
Результат:
Заявки, включенные в содержание релиза — разработаны. Передача заказчику на приемочное тестирование.
Если разработка для какого-то изменение из содержания релиза не завершено, то на основании анализа технических зависимостей рассматриваются вопрос либо о переносе изменения в следующий релиз, либо к задержке выпуска текущего релиза.
Ресурсы:
Активности:
Проведение приемочного тестирования заказчиком, исправление выявленных ошибок, проведение необходимых доработок (по согласованию)
Результат:
Содержимое релиза протестировано, принято заказчиком, и готово к распространению.
Если приемка какого-то изменение из содержания релиза не завершено, то на основании анализа технических зависимостей рассматриваются вопрос либо о переносе изменения в следующий релиз, либо к задержке выпуска текущего релиза.
Ресурсы:
Активности:
Пакет изменений передается в эксплуатацию. Публикация новой версии продукта в продуктивной среде.
Результат:
Изменения перенесены в продуктивную среду и доступны заказчику
Ресурсы:
Активности:
Завершение работ над пакетом изменений: необходимые формальные шаги (документы, акты, счета ), обсуждение внутри команды результатов релиза.
Результат:
Формальное завершение работ. Улучшения процесса.
Ресурсы:
Как и любую активность, релизы нужно планировать. К счастью, управление релизами — это процесс, и поэтому при планировании можно рассчитывать на то что этапы, их взаимосвязь не меняются. Однако для планирования расписания релиза необходимо принципиально определиться с подходом к доставке:
Это планирование проводится в самом начале внедрения процесса, и относится к процессу, как таковому — а не к отдельным релизам, поскольку длительность отдельного релиза меняться не будет.
Принципиальная стабильность календаря релизов в этом случае позволяет осуществлять параллельное исполнение нескольких релизов со смещением относительно друг друга. В этом случае, основная задача календарного планирование этапов релизов — это соблюдение баланса между скоростью доставки изменений заказчику и обеспечение оптимальной загрузки ресурсов команды.
Что будет меняться определенно — это ресурсы, доступные на каждом из этапов, в разных релизах (люди болеют, ходят в отпуск). Но с учетом перечисленных ограничений планирования это будет сказываться только на объем доставляемых изменений, а не на календарный план.
В целом, планирование релизов с фиксированной длительностью, и зависимостью объема доставки от наличия ресурсов — задача относительно несложная. В результате, процесс получается максимально предсказуемый и ритмичный, во многом близкий к Scrum.
В случае, когда релизы планируются исходя из заданного объема изменений зафиксированных перед началом стадии анализа, а сроки сдачи оцениваются от сложности и ресурсов — от менеджера релизов требуется детальное планирование длительности каждого этапа. В этом смысле, релизы соответствуют стандартной «водопадной» модели разработки, планирование не отличается от планирования проекта.
При такой модели организации релизов довольно сложно организовать параллельное выполнение нескольких релизов, поскольку каждый должен быть спланирован отдельно и параллельные релизы должны рассматриваться как портфель проектов с точки зрения использования ресурсов.
Относительно сроков доставки, релизы, планируемые от объемов, также не предлагают заказчику большую определенность по сравнению с проектным подходом:
Таким образом, использование релизов с планированием от объема доставки, нисколько не упрощает операционную деятельность по поддержке приложения по сравнению с проектной, и требует соответствующих ресурсов на управление. Также для заказчика оценка времени доставки требуемых изменений остается очень примерной.
В дальнейшем будем обсуждать только детали, касающиеся релизов с фиксированной длительностью.
Поскольку этапы определены, их взаимосвязи зафиксированы, и длительность каждого этапа будет неизменной, календарное планирование одно релиза не представляет сложности. Основной вопрос, с которыми необходимо определиться — длительность каждого из этапов.
Для этого можно попробовать использовать следующие данные, которые у вас могут быть на основании завершенного проекта:
Имея информацию о соотношении затрат и составе команды — можно определить соотношение времен этапов. Хорошей базой для фиксации конечных длительностей может служить фаза разработки (поскольку как раз оценка затрат на разработку является наиболее методологически проработанной) — от нее будут считаться длительности всех остальных этапов.
Длительность этапов «Deployment» и «Closure» обычно устанавливается фиксированной, поскольку они на прямую не зависят от объема изменений. Разумеется, если зависимость в вашем случае существует — она должна учитываться.
После определения длительностей каждого из этапов, можно переходить к созданию «календаря проекта» — обозначение дат каждого из этапов. Если вы планируете регулярный выпуск обновлений — скажем ежемесячно, ежеквартально, — удобнее всего строить календарный план путем «обратного планирования», отталкиваясь от ожидаемых дат выпуска.
В любом случае — используйте инструменты, предназначенные для календарного планирования (как, например MS Project). Особенно это важно при создании календаря с пересекающимися во времени релизами, поскольку нужно будет тщательно контролировать загрузку ресурсов.
Как видно из описания этапов релиза, на каждом из этапов вовлечены разные ресурсы и профиль загрузки — не однородный:
Таким образом, ожидаемым шагом по оптимизации загрузки ресурсов — параллельное выполнение двух (или более) релизов, спланированных так, чтобы ресурсы постоянно переключались между одинаковыми этапами последующих проектов. То есть, например, аналитик, завершив стадию анализа для релиза R1, переключался на стадию анализа релиза R2. Аналогично — для разработчиков и заказчиков.
При всей очевидности, реализация такого плана — реализуемая, но нетривиальная задача.
Основная сложность заключается в том, что длительности этапов анализа и разработки/тестирования — в общем случае неодинаковы, что приводит либо к перегрузке одних ресурсов, либо к простою других.
В случае, если вы строите процесс управления релизами с параллельными этапами — календарный план релиза должен учитывать перекрытия и загрузку ресурсов. Вполне возможно, что качественное расписание параллельно выполняемых релизов будет накладывать дополнительные требования на состав команды — так чтобы общая «выработка» Аналитиков и Разработчиков с учетом длительности этапов были равны.
Посмотрим, из чего складывается ожидаемый объем содержимого релиза.
Объем заявок на изменения, которые могут быть проанализированы к рамках этапа «Scope» представляют максимальную неопределенность. Действительно — пока аналитик не начнет анализировать заявку, не поймет о чем идет речь, сказать сколько займет полный анализ очень сложно. Конечно, предварительный анализ заявок на стадии «Draft» поможет дать первую оценку, но ее можно использовать для распределения заявок между аналитиками — в зависимости от их специализации и опыта. Кроме того, необходимо учитывать, что аналитик вовлечен в приемочное тестирование — так что, анализом требований и передачей в разработку нагрузка на аналитика в рамках релиза не заканчивается.
Таким образом, первая оценка содержимого релиза может быть дана в терминах «количество заявок на аналитика в релиз». Наиболее пессимистичная оценка «1 заявка на изменение на аналитика в релиз» — с нее и стоит начинать. После того, как статистика по «производительности» аналитиков набрана — оценка содержимого станет более точной.
Работа по анализу технической реализации, на основании собранных требований, также требует времени и усилий — от группы разработки. Как правило, лидер группы отвечает за подготовку технической спецификации и оценки затрат на разработку.
Может случиться, что подготовка спецификаций занимает больше положенного времени и не укладывается в рамки стадии «Scope» — тогда запрос на изменение автоматически «выбывает» из содержимого текущего релиза.
Оценить сложность на подготовку технического решения можно только после завершения анализа. В качестве оптимистичной оценки можно всегда держать «все что было подготовлено аналитиком — будет проработано техническим лидером», хотя, конечно, это не всегда так.
На основании подготовленных требований, технической спецификации получается достаточно точная оценка затрат на разработку — именно она и будет использоваться далее.
Оценка затрат на разработку, доступные ресурсы Разработчиков, доступность Заказчика для участия в приемочном тестировании — все это определяет финальное содержание релиза.
Итак, без учета переноса готовых запросов с предыдущих релизов — объем содержимого релиза ограничен сверху количеством проанализированных заявок (определяется ресурсами Аналитиков). Ограничения по ресурсам Разработчиков могут дополнительно сокращать объем релиза.
Поделюсь некоторыми наблюдениями о проблемах, сопровождающих процесс релизов. Разумеется, в другой организации, скорее всего, проблемы будут свои и бороться с ними прийдется самостоятельно. Но по крайней мере — какие-то общие моменты необходимо иметь ввиду.
При планировании параллельных релизов возникает ситуация, когда все ресурсы — Аналитики, Заказчики и Разработчики должны «переключаться» между релизами. В частности, сценарии переключения следующие:
«Переключение контекста — это плохо». Действительно, это приводит к снижению эффективности, потере фокуса на задаче, и может привести к задержках на ключевых этапах процесса.
В качестве вспомогательной меры по минимизации влияния переключения приходится дополнительно их координировать — это нагрузка на менеджера релизов.
Поскольку релизы планируются «один за другим» или вообще «параллельно» — любая задержка любого этапа, и, соответственно, не освобождение ресурсов обычно влияет как на текущий — так и не следующий релиз через дефицит ресурсов.
Исходя из конструкции этапов релиза и перехода между ними — наибольший негативный эффект имеет задержка этапов разработки и тестирования. Фазы анализа («Draft», «Scope», «Approval») имеют возможность понизить содержание релиза за счет переноса неоконченных заявок на следующий релиз — и это воспринимается заказчиком, обычно, легче, чем перенос из после утверждения содержания релиза.
Это — основная причина нарушения календаря релиза. Поскольку процесс на каждом этапе подразумевает, что команда принимает на себя обязательства, исходя из доступных ресурсов — всегда есть процедурная возможность снизить объем доставки чтобы уложиться в сроки. Однако, очень часто — под давлением заказчика, или в погоне за «выработкой» (что особенно часто случается при контрактной разработке) — команда принимает на себя «повышенные обязательства», которые немедленно отражаются или на сроках или на качестве (а чаще всего — и на том, и на другом).
В качестве меры по можно использовать пессимистичную оценку объема ресурсов при фиксации содержимого релиза на этапе «Approval». Вообще тема «недооценки задачи/переоценки собственных сил и как с этим бороться» — очень дискуссионная. И решение очень сильно зависит от организационного окружения, в котором работает команда.
Довольно часто в ходе анализа выясняется, что объем задачи не помещается во временные рамки этапа «Work in progress» — требуемый объем не получается разработать и доставить в рамках одного релиза.
Если увеличить ресурсы Разработчиков не представляется возможным, остается два возможных путей решения этой проблемы:
Субъективно, первый вариант является более предпочтительным, поскольку позволяет сохранить регулярность доставки и представить хотя-бы часть функциональности в текущем релизе.
Однако, вполне возможно, второй вариант может быть более предпочтительным с точки зрения загрузки ресурсов Разработчиков.
Обработка инцидентов и устранение дефектов, очевидно, занимают ресурсы команды (в большей мере — Разработчиков, но иногда и Аналитиков). Кроме того, нередко устранение некритических дефектов, имеющих известные способы обхода (workarounds) могут иметь меньшую ценность для бизнеса, по сравнению с требуемыми изменениями. Отсюда — очевидное желание рассматривать задачи устранения дефектов (или предоставления дополнительных сервисов) в общем контексте планирования содержания релиза — делать то, что важно.
С другой стороны, устранение дефектов может быть утверждено заказчиком в качестве априорно наиважнейшей задачи — таким образом, ресурсы на устранение дефектов прийдется выделять в приоритетном порядке.
В любом случае, необходимо учитывать наличие дефектов при оценке доступных ресурсов, которые можно выделить на содержимое релизов.
Вне зависимости от подхода к оценке необходимых ресурсов, включение задач по устранению дефектов в содержимое релизов может оказаться полезным при анализе технических зависимостей всех изменений, над которыми работает команда.
Серьезным преимуществом процесса релизов (особенно, при релизах с фиксированной длительностью) в глазах заказчика является заранее объявленное дата выпуска, обычно привязанная к определённым календарным точкам (например — ежемесячно, ежеквартально). Это позволяет строить прозрачный и ритмичный процесс, с ожидаемыми по срокам контрольными точками (переходами между этапами) и ожидаемыми результатами на каждой точке. Кроме того, заказчик непосредственно вовлечён в определение содержимого релиза путём определения приоритетов.
Для команды, поддерживающей продукт, процесс предоставляет возможность реализовать оптимальную загрузку своих ресурсов, и управлять объемом работ, доставляя изменения в срок и качественно. Также, после нескольких завершенных релизов, на базе собранной статистики, команде будет проще обосновывать запросы на дополнительные ресурсы в ответ на растущие запросы заказчика.
Автор: serhit
Источник [1]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/agile/242782
Ссылки в тексте:
[1] Источник: https://habrahabr.ru/post/321664/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best
Нажмите здесь для печати.