Как организовать релиз
Как готовиться к релизу?
Выбрать ответственного человека
Можно дежурить по очереди, либо бросать игральные кости, либо тянуть спички —любой способ хорош. Важна ротация людей и обучение тех, кто не умеет делать релиз. Например, при броске костей можно ввести правила что тот, кто дежурил в прошлый раз, имеет право перебросить, а если дежурил два раза подряд, то автоматически не дежуришь. Дежурство не должно восприниматься как наказание или повинность, и обязательно должны быть люди, которые могут подстраховать.
Настроить календарь
Настроить дату в корпоративном календаре и убедится что все стейкхолдеры в курсе.
Сделать таблицу в вики
Укажите таблице версию, дату и человека, ответственного за релиз. Это больше нужно для ведения исторических данных. Можно и нужно тут же отметить, был ли релиз успешный и что именно вошло в релиз.
Release notes
Это то самое “что именно вошло в релиз”. В первую очередь, этими данными нужно поделится с аналитиками: любые изменения в KPI они могут сравнивать с тем, что вошло в релиз. На основании этих данных они могут делать выводы, какой функционал нужен пользователям, какие идеи хорошие, а какие нет, и что войдет в следующею итерацию.
Внутренний анонс
Другим отделам важно знать когда произошел релиз, чтобы, например, сделать посты в соц. сетях о новой версии продукта (создать инфоповод), следить за KPI (возможен рост или падение метрик) и т.д.
Во время релиза
Создать релизный бранч
Код, который подлежит выпуску не должен меняться, за исключением исправления критических багов. И в идеальном случае любой фикс должен пройти пул-реквест. Так же все тесты должны быть зеленые.
Отправить уведомление
Нужно уведомить всех по почте или в мессенджере о том, что создан релизный бранч и идет подготовка к релизу.
Сделать тэг
Обязательно сделать тэг, когда релиз финализирован, и затянуть фиксы в девелоп-ветку.
Сделать сам релиз
В идеальном варианте у вас должны быть механизмы, которые контролируют релиз: например, сделать релиз только на 10% пользователей или только на не платящих. Это необходимо для того. чтобы уменьшить урон от ошибок, которые возникли в процессе разработки и не были найдены во время тестирования.
Релиз одной кнопкой
Мифический. Безусловно, чем меньше человеческого фактора участвует в релизе, тем лучше. Но это нормально, если не все получается автоматизировать.
Если все пошло не так, как планировалось
Конечно же в случае какой-либо ошибки нельзя друг друга обвинять, а нужно решить проблему вместе и придумать план по предотвращению подобных инцидентов в будущем.
После релиза
Мониторить
Не забывайте мониторить ошибки, нагрузку на сервера. Также стоит обратить внимание на KPI: если вы сделали релиз и у вас упало DAU, то, возможно, что-то работает не так хорошо, как должно было, либо сломаны сами средства мониторинга. Любую подозрительную активность стоит проверить.
Сообщить об успехах и неудачах
Намного лучше если о проблеме узнают от разработчиков, а не от пользователей. И конечно же, если вы решили какие-то проблемы, то этим можно смело похвалиться.
Провести ретроспективу
Это, конечно же, частично зависит от методологии разработки, но если что-то в процессе релиза пошло не так — это стоит обсудить. Если что-то было хорошо, то это также стоит обсудить. В идеале на доске на каждый пункт неудачи должен быть пункт успеха либо благодарность коллеге. Это поможет не скатить ретроспективу в нытье и негатив.
Заказать пиццу и отпраздновать
Во время таких посиделок просто коллеги становятся друзьями и боевыми товарищами. А это значит, что в следующем бою друзья не подведут.
Начать подготовку к следующему релизу
Мне очень нравится идея Release train, когда каждый релиз проходит регулярно в четко обозначенные даты. Благодаря этому механизм релиза отлаживается командой. Как я писал выше, не обязательно делать релиз на 100% пользователей: можно выкатить на небольшую группу людей.
Релиз
Релиз (англ. Release) – подразумевает под собой последний выпуск программного обеспечения, это самая новая версия программного обеспечения, содержащая все изменения и обновления. В релизе содержатся новые и измененные конфигурационные единицы, в отношении которых осуществлено тестирование и которые готовы к использованию. Целью процесса управления релизами является консолидация, структурирование и оптимизация всех изменений или обновлений ПО. Также при этом снижаются риски при переходе продукта на новый качественный уровень.
Содержание
Общие сведения
Общую информацию Вы можете получить, перейдя по следующим ссылкам:
Расширенные сведения
С дополнительной информацией об этом понятии Вы можете ознакомиться ниже.
У релиза программного обеспечения есть свой жизненный цикл (см. иллюстрацию):
Пре-альфа
Первый этап жизненного цикла релиза ПО называется «Пре-альфа» (англ. Pre-alpha). Пре-альфа относится ко всем видам деятельности на этапе разработки ПО до момента тестирования. На этом этапе выполняют такие действия:
Альфа
Третий этап – «Бета» (англ. Beta). Данный этап, как правило, начинается с завершения разработки всех функций ПО. На этапе Бета в программах находят больше технических деффектов, чем на предыдущих этапах (например, скорость работы или производительность системы). Этот этап предполагает проведение тестирования эксплуатационной пригодности. Процесс предоставления пользователям бета-версии программы называется Бета-релиз. По сути, это тот этап, когда программное обеспечение становится доступным для внешних пользователей, а не только для разработчиков внутри организации.
Закрытое и открытое Бета-тестирование
Четвертый этап – «Закрытое и открытое Бета-тестирование». То есть разработчики выпускают или закрытую версию ПО, или открытую. Закрытая Бета-версия программы доступна лишь для узкого круга пользователей, которые протестируют ПО. Соответственно, открытая Бета-версия доступна широкому кругу лиц, которые могут протестировать программу по своей инициативе. После чего, они сообщают разработчикам о возникших ошибках и иногда предлагают дополнить программу какими-то функциями, которые, по их мнению, должны присутствовать в финальной версии программы. Примерами основных открытых бета-версий программ могут служить:
Тестирование открытых Бета-версий применимо в двух случаях:
Пятый этап называется «Релиз-кандидат» (англ. Release candidate, RC)- это Бета-версия продукта, который имеет достаточно потенциала для того, чтобы стать финальной версий. На этом этапе продукт станет финальным релизом, в случае, если не возникнут серьезные дефекты. На данном этапе происходит стабилизация функционирования ПО – все функции разработаны, закодированы и протестированы. Этот релиз превращается в релиз с утвержденным кодом (code complete), когда вся команда разработчиков убеждена, что ни один новый код не будет добавлен в данную программу.
Релиз для производства
Шестой этап называется «Релиз для производства» (англ. «Release to manufacturing,RTM). Термин RTM, известный также, как «становящийся золотом»(англ. Going Gold), используется, когда продукт может предоставляться конечным пользователям. Чаще всего, подразумеваются розничные продажи широкому числу покупателей. Термин RTM также может означать, что продукт был предоставлен клиентам для инсталляции на своих аппаратных устройствах. Этот термин не определяет способ и объем доставки ПО потребителям, он всего лишь указывает на то, что на этом этапе качества продукта достаточно для массового распространения. Этот этап предшествует этапу жизненного цикла релиза ПО под названием «Общедоступный Релиз».
Общедоступный Релиз
Веб-релиз
Окончание срока службы
Завершающий этап «Окончание срока службы» (англ. End-of-life). Означает, что программа больше не продается и не поддерживается. ПО морально устаревает, но иногда лояльность пользователей может продлить программе жизнь на еще какой-то промежуток времени.
Что значит альфа и бета версия, RC, релиз?
В сети нам часто попадаются программы с приставками вроде «альфа», «бета» и другими. Давайте рассмотрим, что они означают. Разработка любой программы проходит в несколько этапов. Результатом такой работы на каждом этапе становится какая-нибудь версия ПО. Постепенно программа доводится до стабильного состояния, когда все найденные ошибки исправлены, и она готова к использованию.
Пре-альфа (Pre-Alpha)
Эта приставка присваивается тем версиям программ, которые ещё не вышли в стадию альфа или бета. Тем не менее пре-альфа-программы уже прошли стадию разработки и предоставляются пользователям для оценки их функциональных возможностей. Пре-альфа может содержать далеко не все возможности более поздних версий программы. Так как это «сырая» версия продукта, то неизбежно наличие кучи багов, ошибок и прочих недоработок в программе.
Альфа (Alpha)
Приставка «альфа» присваивается программам, которые тестируются внутри фирмы-разработчика. Альфа-тестирование проводят в основном специалисты-тестеры. Использовать альфа-версии также не рекомендуется, так как в них всё ещё присутствует много ошибок и наверняка неполный функционал. Устанавливать альфа-версии стОит только для ознакомления с будущими возможностями программ.
Бета (Beta)
Бета-версии программ – это уже практически готовые продукты, разработанные в первую очередь для тестирования конечными пользователями. Часто их распространяют бесплатно, чтобы привлечь как можно больше пользователей, и, возможно, потенциальных покупателей будущей платной версии программы. Также благодаря свободному распространению и возможности её использования, у разработчиков появляется возможность получить оценки и отзывы от пользователей. У бета-версий программ также присутствуют ошибки, возможны сбои, так что на пользователя по-прежнему ложится вся ответственность за весь ущерб, который может быть нанесён от использования «беток». Многие разработчики специально затягивают этап бета-тестирования, чтобы избегать таких рисков.
Релиз-кандидат (RC от англ. release candidate)
После альфа и бета-тестирования все возможные ошибки уже устранены и программа практически стабильна. Однако есть ещё вероятность, что обнаружатся баги, поэтому разработчики выпускают программы именно в этой версии – RC. Во многих случаях может выйти несколько версий RC – 1, 2 и т.д.
Релиз (RTM /от англ. release to manufacturing/, Final, Stable)
Это финальная версия программы, готовая к использованию. В ней исправлены практически все ошибки, она обладает полным функционалом, работа её стабильна и протестирована многими пользователями ранее.
Обновление продуктов системы программ 1С:Предприятие (версии, редакции и релизы)
Эта информация необходима для того, чтобы понимать, как и какие части 1С:Предприятия необходимо обновлять, а также для того, чтобы при обращении в службу технической поддержки фирмы «1С» пользователь мог точно сообщить, с каким программным продуктом он работает. Информация о том, какие обновления установлены, существенно повышает эффективность консультации.
Прежде всего отметим, что 1С:Предприятие состоит из платформы (системной части) и различных конфигураций. Платформа поставляется всегда в готовом виде и не может быть изменена пользователем. Конфигурация также поставляется в готовом виде, но может изменяться пользователем (кроме базовых версий). В поставку большинства программных продуктов 1С:Предприятия входит платформа и одна или несколько конфигураций. Некоторые конфигурации поставляются отдельно, и для их работы у пользователя должен быть другой продукт, включающий платформу.
Платформа и конфигурации обновляются независимо, то есть обновления платформы и конфигурации выпускаются в разное время и имеют разные номера. Однако в некоторых случаях необходимо выполнять обновление и платформы, и конфигурации. Данное обстоятельство обычно оговаривается в инструкции по обновлению конфигурации.
Существует несколько способов получения обновлений.
Получение обновлений может выполняться у партнеров фирмы «1С». Возможность и условия обновлений следует обговаривать с конкретной партнерской организацией.
Зарегистрированные пользователи могут также получать обновления непосредственно в фирме «1С».
Не рекомендуется пользоваться неофициальными источниками для получения обновлений.
Установка новых версий программы выполняется достаточно редко и подробно описывается в прилагаемой документации.
Обновление конфигураций (редакций и релизов) должно выполняться согласно инструкции. Для типовых конфигураций инструкция по установке выдается в процессе установки новой редакции или релиза конфигурации. В состав конфигурации включается также и описание изменений, внесенных в данном релизе или редакции. Обновление конфигурации следует выполнять весьма внимательно. Рекомендуется до выполнения обновления сделать резервную копию информационной базы. При установке обновлений конфигураций следует придерживаться той последовательности, в которой выпускаются релизы и редакции. Так как при установке каждого релиза может выполняться конвертация информации, то для более корректного обновления не следует пропускать релизы.
На диске ИТС существует раздел с подробными рекомендациями по обновлению конфигураций.
Как обновить свою программу?
Эта информация необходима для того, чтобы понимать, как и какие части 1С:Предприятия необходимо обновлять, а также для того, чтобы при обращении в службу технической поддержки фирмы «1С» пользователь мог точно сообщить, с каким программным продуктом он работает. Информация о том, какие обновления установлены, существенно повышает эффективность консультации.
Прежде всего отметим, что 1С:Предприятие состоит из платформы (системной части) и различных конфигураций. Платформа поставляется всегда в готовом виде и не может быть изменена пользователем. Конфигурация также поставляется в готовом виде, но может изменяться пользователем (кроме базовых версий). В поставку большинства программных продуктов 1С:Предприятия входит платформа и одна или несколько конфигураций. Некоторые конфигурации поставляются отдельно, и для их работы у пользователя должен быть другой продукт, включающий платформу.
Платформа и конфигурации обновляются независимо, то есть обновления платформы и конфигурации выпускаются в разное время и имеют разные номера. Однако в некоторых случаях необходимо выполнять обновление и платформы, и конфигурации. Данное обстоятельство обычно оговаривается в инструкции по обновлению конфигурации.
Существует несколько способов получения обновлений.
Получение обновлений может выполняться у партнеров фирмы «1С». Возможность и условия обновлений следует обговаривать с конкретной партнерской организацией.
Зарегистрированные пользователи могут также получать обновления непосредственно в фирме «1С».
Не рекомендуется пользоваться неофициальными источниками для получения обновлений.
Установка новых версий программы выполняется достаточно редко и подробно описывается в прилагаемой документации.
Обновление конфигураций (редакций и релизов) должно выполняться согласно инструкции. Для типовых конфигураций инструкция по установке выдается в процессе установки новой редакции или релиза конфигурации. В состав конфигурации включается также и описание изменений, внесенных в данном релизе или редакции. Обновление конфигурации следует выполнять весьма внимательно. Рекомендуется до выполнения обновления сделать резервную копию информационной базы. При установке обновлений конфигураций следует придерживаться той последовательности, в которой выпускаются релизы и редакции. Так как при установке каждого релиза может выполняться конвертация информации, то для более корректного обновления не следует пропускать релизы.
На диске ИТС существует раздел с подробными рекомендациями по обновлению конфигураций.
Что такое «версия» программы?
В системе программ 1С:Предприятие понятие «версия» относится к платформе. Версия является своего рода «поколением» системы программ. Новая версия выпускается раз в несколько лет и является существенным развитием практически всех возможностей системы. Текущей версией 1С:Предприятия (на апрель 2001 года) является версия 7.7. По имени этой версии именуются и все продукты, выпускаемые с момента выхода данной версии. Например, 1С:Бухгалетерия 7.7, включает платформу 1С:Предприятия версии 7.7 и типовую конфигурацию, разработанную для этой версии. Конфигурации, разработанные для предыдущих версий, могут использоваться с данной версией, но только после выполнения конвертации (преобразования самой конфигурации и данных).
Что такое «редакции»?
Понятие «Редакция» в системе программ 1С:Предприятие применяется к конфигурациям. Новые редакции конфигураций разрабатываются в среднем раз в полгода и являются развитием конкретной конфигурации. В новых редакциях расширяется состав задач, решаемых программой, вводятся новые возможности (документы, справочники, отчеты), улучшаются алгоритмы и внешнее оформление. В некоторых случаях выпуск новых редакций обусловлен существенными изменениями законодательства, требующими перестройки механизмов учета. Новая редакция, как правило, имеет новую документацию. Кроме того, новая редакция обычно содержит описание отличий для пользователей предыдущих редакций. При переходе на новую редакцию требуется выполнить определенную процедуру установки, которая может выполняться с конвертацией данных или без нее в зависимости от характера развития конфигурации.
В некоторых конфигурациях номер редакции может не отображаться в режиме «О программе». Помимо этого, для некоторых конфигураций (например, «Зарплата + Кадры») понятие редакции не используется.
Что такое «релиз (выпуск)»?
Обновление релиза платформы выполняется достаточно просто. Конвертация данных при этом не производится. Обновление релиза конфигурации выполняется по прилагаемой инструкции. В зависимости от сделанных в релизе изменениях при обновлении может потребоваться или не потребоваться конвертация данных.
В некоторых конфигурация номер релиза может не отображаться в режиме «О программе».
Процесс «Управление релизами» — для постпроектной поддержки или развития продукта
После формального окончания проекта — работа не заканчивается, а только начинается. Необходимо реализовать функционал который не вошёл в основное содержание проекта, исправить некритичные ошибки которые не препятствовали запуску, и обслуживать поток изменений и инцидентов, сопутствующих процессу эксплуатации. При этом, необходимо организовать процесс таким образом, чтобы учитывать приоритеты запросов, технические зависимости, оставлять время на анализ требуемых изменений.
Процесс «управление релизами», один из стека процессов ITSM, как раз и предлагает решение для формальной приоритизации и группировки запросов пользователей (запросов на изменения, инцидентов) в общие пакеты доставки — «релизы».
В данной статье кратко раскрываются следующие темы:
Применимость процесса
Когда целесообразно применять процесс, в дополнение к управлению инцидентами и управлению изменениями? Разумеется, в каждом случае набор критериев разный, но перечисленные ниже сценарии — хороший повод задуматься о релизах:
Этапы процесса
Процесс состоит из последовательности этапов. В разных реализациях процесса некоторые этапы могут быть объединены, или могут называться по другому — но общий принцип сохраняется
1. Draft
Активности:
Подбор запросов на изменения и инцидентов в список того, что планируется делать, проводится начальная приоритезация, анализ взаимозависимостей и предварительная оценка трудозатрат на анализ и разработку.
Результат:
Все требования содержат высокоуровневую оценку сложности и рекомендации по группировке в релиз на основании области изменений и/или технических зависимостей.
С учётом этих оценок и рекомендаций, на основании бизнес-приоритетов заказчика и доступных ресурсов исполнителя, к анализу принимается группа запросов на изменения и инцидентов. Не вошедшие в этот список обращения возвращаются в общий пул и будут оценены в рамках следующих релизов
2. Scope
Активности:
Проводится детальный анализ и оценка, подготовка спецификаций по изменениям, отобранным на основании приоритетов заказчика Отобранные требования полностью проанализированы и утверждены заказчиком, технические спецификации проработаны, детальная оценка трудозатрат проведена.
Результат:
Полностью проанализированные запросы на изменения подготавливаются к финальному подтверждению содержания релиза. Запросы, для которых анализ или согласование не завершено — возвращаются в общий пул. Они — кандидаты на анализ (окончание анализа) в рамках следующего релиза
3. Approval
Активности:
Получение подтверждение ресурсов от исполнителей (для разработки) и заказчиков (дляд тестирования). Оценка общего бюджета релиза (если применимо). Финальное согласование с заказчиком содержания релиза, исходя из готовности отдельных запросов, приоритетов, оценённого бюджета, доступных ресурсов.
Результат:
Сформировано финальное содержание релиза.
Все запросы на изменения, входящие в финальное содержание релиза передаются в разработку. Остальные запросы на изменения возвращаются в общий пул. Поскольку эти изменения имеют высокую степень готовности — они кандидаты в следующий релиз
4. Work in progress
Активности:
Разработка и исправление дефектов для всех заявок, вошедших в финальное содержимое релизов. Внутреннее тестирование и подготовка к приемочному тестированию.
Результат:
Заявки, включенные в содержание релиза — разработаны. Передача заказчику на приемочное тестирование.
Если разработка для какого-то изменение из содержания релиза не завершено, то на основании анализа технических зависимостей рассматриваются вопрос либо о переносе изменения в следующий релиз, либо к задержке выпуска текущего релиза.
5. Testing
Активности:
Проведение приемочного тестирования заказчиком, исправление выявленных ошибок, проведение необходимых доработок (по согласованию)
Результат:
Содержимое релиза протестировано, принято заказчиком, и готово к распространению.
Если приемка какого-то изменение из содержания релиза не завершено, то на основании анализа технических зависимостей рассматриваются вопрос либо о переносе изменения в следующий релиз, либо к задержке выпуска текущего релиза.
6. Deployment
Активности:
Пакет изменений передается в эксплуатацию. Публикация новой версии продукта в продуктивной среде.
Результат:
Изменения перенесены в продуктивную среду и доступны заказчику
7. Closure
Активности:
Завершение работ над пакетом изменений: необходимые формальные шаги (документы, акты, счета ), обсуждение внутри команды результатов релиза.
Результат:
Формальное завершение работ. Улучшения процесса.
Планирование релизов
Как и любую активность, релизы нужно планировать. К счастью, управление релизами — это процесс, и поэтому при планировании можно рассчитывать на то что этапы, их взаимосвязь не меняются. Однако для планирования расписания релиза необходимо принципиально определиться с подходом к доставке:
Планирование релизов с фиксированной длительностью
Это планирование проводится в самом начале внедрения процесса, и относится к процессу, как таковому — а не к отдельным релизам, поскольку длительность отдельного релиза меняться не будет.
Принципиальная стабильность календаря релизов в этом случае позволяет осуществлять параллельное исполнение нескольких релизов со смещением относительно друг друга. В этом случае, основная задача календарного планирование этапов релизов — это соблюдение баланса между скоростью доставки изменений заказчику и обеспечение оптимальной загрузки ресурсов команды.
Что будет меняться определенно — это ресурсы, доступные на каждом из этапов, в разных релизах (люди болеют, ходят в отпуск). Но с учетом перечисленных ограничений планирования это будет сказываться только на объем доставляемых изменений, а не на календарный план.
В целом, планирование релизов с фиксированной длительностью, и зависимостью объема доставки от наличия ресурсов — задача относительно несложная. В результате, процесс получается максимально предсказуемый и ритмичный, во многом близкий к Scrum.
Планирование релизов от объема доставки
В случае, когда релизы планируются исходя из заданного объема изменений зафиксированных перед началом стадии анализа, а сроки сдачи оцениваются от сложности и ресурсов — от менеджера релизов требуется детальное планирование длительности каждого этапа. В этом смысле, релизы соответствуют стандартной «водопадной» модели разработки, планирование не отличается от планирования проекта.
При такой модели организации релизов довольно сложно организовать параллельное выполнение нескольких релизов, поскольку каждый должен быть спланирован отдельно и параллельные релизы должны рассматриваться как портфель проектов с точки зрения использования ресурсов.
Относительно сроков доставки, релизы, планируемые от объемов, также не предлагают заказчику большую определенность по сравнению с проектным подходом:
В дальнейшем будем обсуждать только детали, касающиеся релизов с фиксированной длительностью.
Календарное планирование релиза
Поскольку этапы определены, их взаимосвязи зафиксированы, и длительность каждого этапа будет неизменной, календарное планирование одно релиза не представляет сложности. Основной вопрос, с которыми необходимо определиться — длительность каждого из этапов.
Для этого можно попробовать использовать следующие данные, которые у вас могут быть на основании завершенного проекта:
Длительность этапов «Deployment» и «Closure» обычно устанавливается фиксированной, поскольку они на прямую не зависят от объема изменений. Разумеется, если зависимость в вашем случае существует — она должна учитываться.
После определения длительностей каждого из этапов, можно переходить к созданию «календаря проекта» — обозначение дат каждого из этапов. Если вы планируете регулярный выпуск обновлений — скажем ежемесячно, ежеквартально, — удобнее всего строить календарный план путем «обратного планирования», отталкиваясь от ожидаемых дат выпуска.
В любом случае — используйте инструменты, предназначенные для календарного планирования (как, например MS Project). Особенно это важно при создании календаря с пересекающимися во времени релизами, поскольку нужно будет тщательно контролировать загрузку ресурсов.
Одновременное выполнение нескольких релизов
Как видно из описания этапов релиза, на каждом из этапов вовлечены разные ресурсы и профиль загрузки — не однородный:
При всей очевидности, реализация такого плана — реализуемая, но нетривиальная задача.
Основная сложность заключается в том, что длительности этапов анализа и разработки/тестирования — в общем случае неодинаковы, что приводит либо к перегрузке одних ресурсов, либо к простою других.
В случае, если вы строите процесс управления релизами с параллельными этапами — календарный план релиза должен учитывать перекрытия и загрузку ресурсов. Вполне возможно, что качественное расписание параллельно выполняемых релизов будет накладывать дополнительные требования на состав команды — так чтобы общая «выработка» Аналитиков и Разработчиков с учетом длительности этапов были равны.
Определение содержимого поставки при фиксированной длительности релиза
Посмотрим, из чего складывается ожидаемый объем содержимого релиза.
Фаза анализа требований
Объем заявок на изменения, которые могут быть проанализированы к рамках этапа «Scope» представляют максимальную неопределенность. Действительно — пока аналитик не начнет анализировать заявку, не поймет о чем идет речь, сказать сколько займет полный анализ очень сложно. Конечно, предварительный анализ заявок на стадии «Draft» поможет дать первую оценку, но ее можно использовать для распределения заявок между аналитиками — в зависимости от их специализации и опыта. Кроме того, необходимо учитывать, что аналитик вовлечен в приемочное тестирование — так что, анализом требований и передачей в разработку нагрузка на аналитика в рамках релиза не заканчивается.
Таким образом, первая оценка содержимого релиза может быть дана в терминах «количество заявок на аналитика в релиз». Наиболее пессимистичная оценка «1 заявка на изменение на аналитика в релиз» — с нее и стоит начинать. После того, как статистика по «производительности» аналитиков набрана — оценка содержимого станет более точной.
Подготовка технического решения
Работа по анализу технической реализации, на основании собранных требований, также требует времени и усилий — от группы разработки. Как правило, лидер группы отвечает за подготовку технической спецификации и оценки затрат на разработку.
Может случиться, что подготовка спецификаций занимает больше положенного времени и не укладывается в рамки стадии «Scope» — тогда запрос на изменение автоматически «выбывает» из содержимого текущего релиза.
Оценить сложность на подготовку технического решения можно только после завершения анализа. В качестве оптимистичной оценки можно всегда держать «все что было подготовлено аналитиком — будет проработано техническим лидером», хотя, конечно, это не всегда так.
На основании подготовленных требований, технической спецификации получается достаточно точная оценка затрат на разработку — именно она и будет использоваться далее.
Фиксация содержимого проекта
Оценка затрат на разработку, доступные ресурсы Разработчиков, доступность Заказчика для участия в приемочном тестировании — все это определяет финальное содержание релиза.
Итак, без учета переноса готовых запросов с предыдущих релизов — объем содержимого релиза ограничен сверху количеством проанализированных заявок (определяется ресурсами Аналитиков). Ограничения по ресурсам Разработчиков могут дополнительно сокращать объем релиза.
Известные проблемы
Поделюсь некоторыми наблюдениями о проблемах, сопровождающих процесс релизов. Разумеется, в другой организации, скорее всего, проблемы будут свои и бороться с ними прийдется самостоятельно. Но по крайней мере — какие-то общие моменты необходимо иметь ввиду.
Переключение контекста при параллельных релизах
При планировании параллельных релизов возникает ситуация, когда все ресурсы — Аналитики, Заказчики и Разработчики должны «переключаться» между релизами. В частности, сценарии переключения следующие:
В качестве вспомогательной меры по минимизации влияния переключения приходится дополнительно их координировать — это нагрузка на менеджера релизов.
Ресурсные конфликты при нарушении календаря релиза
Поскольку релизы планируются «один за другим» или вообще «параллельно» — любая задержка любого этапа, и, соответственно, не освобождение ресурсов обычно влияет как на текущий — так и не следующий релиз через дефицит ресурсов.
Исходя из конструкции этапов релиза и перехода между ними — наибольший негативный эффект имеет задержка этапов разработки и тестирования. Фазы анализа («Draft», «Scope», «Approval») имеют возможность понизить содержание релиза за счет переноса неоконченных заявок на следующий релиз — и это воспринимается заказчиком, обычно, легче, чем перенос из после утверждения содержания релиза.
Взятие «повышенных обязательств»
Это — основная причина нарушения календаря релиза. Поскольку процесс на каждом этапе подразумевает, что команда принимает на себя обязательства, исходя из доступных ресурсов — всегда есть процедурная возможность снизить объем доставки чтобы уложиться в сроки. Однако, очень часто — под давлением заказчика, или в погоне за «выработкой» (что особенно часто случается при контрактной разработке) — команда принимает на себя «повышенные обязательства», которые немедленно отражаются или на сроках или на качестве (а чаще всего — и на том, и на другом).
В качестве меры по можно использовать пессимистичную оценку объема ресурсов при фиксации содержимого релиза на этапе «Approval». Вообще тема «недооценки задачи/переоценки собственных сил и как с этим бороться» — очень дискуссионная. И решение очень сильно зависит от организационного окружения, в котором работает команда.
Реализация «больших» задач
Довольно часто в ходе анализа выясняется, что объем задачи не помещается во временные рамки этапа «Work in progress» — требуемый объем не получается разработать и доставить в рамках одного релиза.
Если увеличить ресурсы Разработчиков не представляется возможным, остается два возможных путей решения этой проблемы:
Однако, вполне возможно, второй вариант может быть более предпочтительным с точки зрения загрузки ресурсов Разработчиков.
Устранение дефектов в контексте релизов
Обработка инцидентов и устранение дефектов, очевидно, занимают ресурсы команды (в большей мере — Разработчиков, но иногда и Аналитиков). Кроме того, нередко устранение некритических дефектов, имеющих известные способы обхода (workarounds) могут иметь меньшую ценность для бизнеса, по сравнению с требуемыми изменениями. Отсюда — очевидное желание рассматривать задачи устранения дефектов (или предоставления дополнительных сервисов) в общем контексте планирования содержания релиза — делать то, что важно.
С другой стороны, устранение дефектов может быть утверждено заказчиком в качестве априорно наиважнейшей задачи — таким образом, ресурсы на устранение дефектов прийдется выделять в приоритетном порядке.
В любом случае, необходимо учитывать наличие дефектов при оценке доступных ресурсов, которые можно выделить на содержимое релизов.
Заключение
Серьезным преимуществом процесса релизов (особенно, при релизах с фиксированной длительностью) в глазах заказчика является заранее объявленное дата выпуска, обычно привязанная к определённым календарным точкам (например — ежемесячно, ежеквартально). Это позволяет строить прозрачный и ритмичный процесс, с ожидаемыми по срокам контрольными точками (переходами между этапами) и ожидаемыми результатами на каждой точке. Кроме того, заказчик непосредственно вовлечён в определение содержимого релиза путём определения приоритетов.
Для команды, поддерживающей продукт, процесс предоставляет возможность реализовать оптимальную загрузку своих ресурсов, и управлять объемом работ, доставляя изменения в срок и качественно. Также, после нескольких завершенных релизов, на базе собранной статистики, команде будет проще обосновывать запросы на дополнительные ресурсы в ответ на растущие запросы заказчика.