Release notes что это
Правила написания Release Notes
Release Notes – это документ, описывающий изменения между выпускаемой и предыдущей версиями программного продукта. Адресатом данного документа в первую очередь являются технические специалисты клиента, которые занимаются обслуживанием продукта, интеграторы и команды внедрения. Поэтому документ в первую очередь должен содержать полезную техническую информацию, а не маркетинговые лозунги.
Состав документа
В некоторых конторах в качестве Release notes наружу выдают маркетинговый булшит, а реальное техническое содержание оставляют только для внутреннего читателя. Это косвенно указывает на то, что в продукте много проблем, а производитель ПО вместо их исправления скрывает их. В обратной ситуации, когда принята политика открытости перед пользователем, и его честно информируют о всех косяках в софте, то пользователь будет более лоялен к производителю ПО. В качестве дополнительного бонуса прозрачность мотивирует делать качественные продукты. Стыдно ведь публично писать о своей криворукости.
Сам документ состоит из следующих разделов:
Краткое описание продукта
Несколько предложений или пара абзацев о продукте. Служит для того, чтобы человек, которому в руки попал документ, мог погрузиться в контекст. Иначе без введения на него сразу будет вывален список нового функционала и багов. Не нужно сразу пугать людей.
Что нового
Изменение функциональности относительно прошлой версии. Перечисление основных изменений с их кратким описанием. Цель раздела — объяснить пользователю зачем ему тратить своё время и переходить на новую версию.
Исправленные ошибки
Список исправленных ошибок относительно предыдущей версии. Как и предыдущий раздел, этот тоже стимулирует пользователя на апгрейд. Обязательно описать исправленные проблемы, на которые жаловались клиенты и которые были заявлены как known issues в прошлых версиях. Крайне желательно описать те серьезные проблемы, с которыми пользователь мог столкнуться в прошлых версиях, но жалоб на них не поступало. Отсутствие жалоб вовсе не означает, что с ними никто сталкивался. Возможно люди мучились, но у них не хватило сил пробиться через поддержку.
Включать в этот список все содержимое баг трекера не нужно:
Удобно указывать ID проблемы, для удобства истории ошибки.
Список известных проблем или known issues
Если у вас нет known issues – значит никто не тестировал продукт.
Приводим список известных проблем (багов). Идеально, если в нем содержатся все актуальные баги для данной версии. Если их слишком много, то выбираем наиболее критичные для пользователя. Для каждого бага нужно указывать:
Есть соблазн написать в этот раздел поменьше, чтобы не пугать клиентов. Всех, кто так считает, можно отправить к рассказу Драгунского «Тайное становится явным». Если клиенты действительно используют продукт, то все равно они найдут все эти баги, в дополнение у них еще появятся вопросы к качеству тестирования продукта производителем. А так вы честно демонстрируете открытость клиентам и сразу выдаете список woraround’ов, снижая затраты на поддержку.
Не стоит забывать и про мотивационную составляющую. Если люди работают в условиях прозрачности, то они склонны делать свою работу более качественно, краснеть никто не любит.
Технические ограничения
Любое ПО имеет технические ограничения. Ваш сервер позволяет работать одновременно 10 пользователям? В базу можно сделать только 10000 записей? UI рассчитан только на Full HD? Напишите об этом.
Системные требования
В данном разделе все понятно: минимальные и рекомендуемые требования по железу, поддерживаемые операционные системы, требуемый сторонний софт.
Если параметры железа зависят от сценариев использования продукта, например, от количества пользователей, сложности вычислений, количества данных в базе, то хорошо сделать sizing guide. Это таблица в стиле: если ожидается такая нагрузка, то рекомендуется такое железо.
Особенности обновления с прошлой версии.
Апдейт не всегда проходит гладко. А потеря данных пользователя вообще караул. Лучше сразу предупредить о возможных проблемах.
Кто пишет документ
Все новости сайта в телеграм канале: @pmlife_ru
Как автоматически создать отчет о релизе
Сегодня расскажем, как автоматизировать создание отчетной документации по релизу (release notes) на основе импорта данных из трекинговых систем TFS, Redmine и JIRA и из системы управления проектами Microsoft Project Server.
Статья будет интересна в первую очередь менеджерам IT-проектов.
В чем проблема?
Главными проблемами были ошибки и разнобой в оформлении release notes. Это сопроводительный документ, который мы отправляем заказчику вместе с очередным релизом. Release notes должен быть точным, как инструкция по запуску космического корабля. Каждый относящийся к релизу багфикс, каждая закрытая user story и вся информация по user feedback должны быть четко отражены в отчете. Составлялся этот большой и важный документ вручную, копипастом из трекинговых программ. Вот тут-то и возникали проблемы.
Проблема 1. Ошибки.
При ручном составлении отчета иногда возникали ошибки. Некоторые наши проекты очень объемны и по технологическим причинам ведутся сразу в двух трекерах (например, часть проекта по созданию мобильного приложения ведется в Redmine, а по созданию веб-приложения – в TFS). Собирать по ним огромный отчет – долго и человеческий фактор мешал сделать все отчеты на 100% верифицированными.
Проблема 2. Разнобой в оформлении.
Кто-то из менеджеров проектов писал подробные комментарии к релизу, кто-то отправлял просто список работ. Красота оформления тоже страдала, поскольку release notes выглядел как обычное электронное письмо, хотя это одно из самых важных писем, которое приходит заказчику.
Постепенно мы пришли к пониманию того, что создание отчетов по релизам нужно автоматизировать.
Что мы получили после автоматизации?
На нашем внутреннем портале появился веб-конструктор, который позволяет в несколько кликов собрать готовый отчет по релизу. Логинишься в приложение, выбираешь проект, релиз, нужные user story и таски, нажимаешь кнопочку – и остается только при необходимости дописать комментарии. По отзывам проджектов, эти простые действия приносят стойкое ощущение счастья.
Конструктор интегрирован с таск-трекерами и автоматически подтягивает в готовый release notes всю информацию по релизу. На выходе приложение генерирует красиво сверстанный e-mail отчет для заказчика. В нем вся информация разбита по категориям и каждый пункт снабжен ссылкой, ведущей на соответствующую страницу в трекере.
Вот так выглядит готовый сверстанный release notes:
Управленческие бонусы
Автоматизация по шагам
Прежде чем делать свое решение для автоматизации, мы поискали готовые варианты. Теоретически для автоматизации составления release notes можно было использовать плагины к трекерам, в которых мы работаем (TFS, Redmine и JIRA). Но плагины у TFS и Redmine оказались неудобными. А для сборки единого отчета сразу из двух или трех трекеров вообще не нашлось готового решения. Поэтому нам пришлось сделать свое.
Шаг 1. Навели порядок в трекерах: ввели единые стандарты для менеджеров проектов, по которым они ведут проекты.
По технологическим причинам наши проекты ведутся в трех трекерах (TFS, JIRA, Redmine) и стандарты ведения проектов в них немного отличались. Для интеграции трекеров пришлось провести работу по внедрению единых стандартов для всех трекеров.
Кроме того, понадобилось также причесать те блоки информации в трекерах, которые непосредственно экспортируются в release notes. Проект должен быть разбит по релизам, релизы поделены на задачи и у них проставлены статусы, все user story правильно описаны и закрыты, все задачи по фидбэку классифицированы, заведены все спринты. Кроме того, всем задачам и релизам должны быть даны понятные названия, ведь они потом войдут в отчет для заказчика
Шаг 2. Собрали Data WareHouse на основе данных из трекеров и MS Project Server
Мы построили представления над базами данных наших трекинговых систем (TFS, Redmine и JIRA), также подтянули некоторые данные из Microsoft Project Server (например, данные о заказчике). При этом нам пришлось решить некоторые проблемы с интеграцией данных из трекеров. Например, для каждого трекера пришлось найти индивидуальное решение проблемы с авторизацией для получения данных. Подробно об этом мы уже писали.
Данные из трёх трекинговых систем (TFS, Redmine, JIRA) и Microsoft Project собираются в единое хранилище данных Data Warehouse.
Сначала загружаем данные из Microsoft Project.
Далее, чтобы не заморачиваться с удалением старых данных, мы очищаем таблицы, связанные с задачами. И приступаем к сбору данных из трекинговых систем. Для каждой системы данные собираются по-своему. Как уже писалось в этой статье, для Redmine и TFS мы написали представления, которые возвращают нам все необходимые данные.
Так как доступа к базе JIRA у нас нет, то мы использовали JIRA REST APIi. Как вы сами понимаете, это самая медленная часть скрипта и куча возможностей для оптимизации. Но это уже отдельная история.
После загрузки данных из трекеров нужно заполнить «пробелы» в таблицах проектов и сотрудников. Эти пробелы возникают в связи с тем, что не все проекты и сотрудники заведены в Microsoft Project в силу каких-то обстоятельств (либо не успели завести, либо исторически так сложилось). Отсутствующие данные сразу видны в отчете из OLAP куб, они помечены в отдельном столбце как Mismatch, и их можно сразу же обработать и навести порядок.
Далее осталось собрать всё воедино. Собираем вместе список задач.
И заполняем таблицу фактов (кто, куда и сколько потратил времени).
После чего мы запилили Job, который выполняет SSIS пакет раз в 3 минуты. И в итоге наш Data Warehouse готов. Далее с ним можно делать кучу полезных вещей. Например, собрать из него OLAP-куб для построения отчётов, или взять данные для Release Notes, или использовать для построения графика отпусков (да, да, про это тоже скоро расскажем).
Шаг 3. Сверстали красивый release notes нашей мечты.
Тут все просто: дизайнер и верстальщик сделали html-файл, в котором вся информация разбита по категориям, добавлены все необходимые ссылки.
Шаг 4. Сделали веб-приложение, которое на основе данных из Data Warehouse создает единый html-документ с отчетом для заказчика.
Шаг 5. Проект не останавливается.
Первые же письма вызвали восторженную реакцию заказчиков, и они попросили нас адаптировать шаблон под их бренд-буки и дать возможность самостоятельно редактировать наш release notes, сортируя информацию и добавляя комментарии для отправки новым адресатам.
А мы думаем, какие трудозатраты и бизнес-процессы еще оптимизировать.
Автоматизируем подготовку Release Notes в современной команде разработки
Делимся своим опытом о том, как мы в True Engineering собираем отчёты по релизам – быстро, корректно и без ручного труда.
Мы начали автоматизировать подготовку Release Notes несколько лет назад. Нашей целью было привести их к единому для всех команд стандарту, избавить тимлидов и PM-ов от ручной работы по подготовке материалов, застраховаться от возможных ошибок, которые обязательно возникают, если что-то делается вручную.
Мы сделали на нашем внутреннем портале веб-конструктор, который позволяет в несколько кликов собрать готовый отчет по релизу. Сервис интегрирован с таск-трекерами, откуда он автоматически подтягивает всю информацию по релизу. На выходе приложение генерирует красиво сверстанный e-mail отчет для заказчика. Вся информация разбита по категориям, у каждого пункта есть ссылка на соответствующую страницу в трекере.
Несколько лет инструмент работал в таком виде, но прогресс не стоит на месте. Когда мы стали внедрять Trunk Based Development (TBD), подход к Release Notes тоже пришлось поменять.
Концепция TBD предполагает, что разработка идёт непрерывно, а команда постоянно выпускает обновления микрорелизами. Это ускоряет развитие продукта, сокращает Time-to-Market (время от начала разработки до поставки продукта пользователям), обеспечивает разработчикам оперативную обратную связь от заказчика и пользователей.
Ещё один фактор – за последние годы большинство продуктов True Engineering переехали на микросервисы. Такая архитектура предполагает, что в командах используются несколько репозиториев для каждого участвующего микросервиса. Выпуск одной фичи включает несколько релизов для разных микросервисов, и отслеживать это довольно сложно.
Мы переосмыслили подготовку Release Notes, опираясь на автоматический анализ PBI (Product Backlog Item, условно – цельная задача в терминологии TFS). До этого мы уже наладили автоматическую маркировку задач тегами, чтобы QA-инженеры видели, какие фичи можно забирать на тест. Теперь эти же теги мы используем для Release Notes.
Специально созданный плагин TFS на базе TFS Aggregator ежедневно просматривает завершённые PBI и формирует письмо с итогами для менеджеров, директоров, отдела продаж. Aggregator позволяет автоматизировать многие ручные операции при работе с PBI – например, отслеживать, когда последняя задача в PBI получает статус Done, и помечать как готовую всю PBI. Причём` Aggregator умеет очень гибко работать с базой правил – разделять их по проектам, по типам задач и т.д.. В общем, он идеально выполняет рутинную работу, на которую у команды уходит много времени и сил.
Таким образом и получается автоматически готовить Release Notes. Пилот решения уже стартовал на двух наших проектах, скоро новая механика распространится на все команды True Engineering. Прелесть в том, что масштабировать этот опыт будет очень просто – достаточно письма в техподдержку, где будет указан тег, который должен ловить Aggregator, и список адресов, куда нужно отправлять Release Notes.
Как организовать релиз
Как готовиться к релизу?
Выбрать ответственного человека
Можно дежурить по очереди, либо бросать игральные кости, либо тянуть спички —любой способ хорош. Важна ротация людей и обучение тех, кто не умеет делать релиз. Например, при броске костей можно ввести правила что тот, кто дежурил в прошлый раз, имеет право перебросить, а если дежурил два раза подряд, то автоматически не дежуришь. Дежурство не должно восприниматься как наказание или повинность, и обязательно должны быть люди, которые могут подстраховать.
Настроить календарь
Настроить дату в корпоративном календаре и убедится что все стейкхолдеры в курсе.
Сделать таблицу в вики
Укажите таблице версию, дату и человека, ответственного за релиз. Это больше нужно для ведения исторических данных. Можно и нужно тут же отметить, был ли релиз успешный и что именно вошло в релиз.
Release notes
Это то самое “что именно вошло в релиз”. В первую очередь, этими данными нужно поделится с аналитиками: любые изменения в KPI они могут сравнивать с тем, что вошло в релиз. На основании этих данных они могут делать выводы, какой функционал нужен пользователям, какие идеи хорошие, а какие нет, и что войдет в следующею итерацию.
Внутренний анонс
Другим отделам важно знать когда произошел релиз, чтобы, например, сделать посты в соц. сетях о новой версии продукта (создать инфоповод), следить за KPI (возможен рост или падение метрик) и т.д.
Во время релиза
Создать релизный бранч
Код, который подлежит выпуску не должен меняться, за исключением исправления критических багов. И в идеальном случае любой фикс должен пройти пул-реквест. Так же все тесты должны быть зеленые.
Отправить уведомление
Нужно уведомить всех по почте или в мессенджере о том, что создан релизный бранч и идет подготовка к релизу.
Сделать тэг
Обязательно сделать тэг, когда релиз финализирован, и затянуть фиксы в девелоп-ветку.
Сделать сам релиз
В идеальном варианте у вас должны быть механизмы, которые контролируют релиз: например, сделать релиз только на 10% пользователей или только на не платящих. Это необходимо для того. чтобы уменьшить урон от ошибок, которые возникли в процессе разработки и не были найдены во время тестирования.
Релиз одной кнопкой
Мифический. Безусловно, чем меньше человеческого фактора участвует в релизе, тем лучше. Но это нормально, если не все получается автоматизировать.
Если все пошло не так, как планировалось
Конечно же в случае какой-либо ошибки нельзя друг друга обвинять, а нужно решить проблему вместе и придумать план по предотвращению подобных инцидентов в будущем.
После релиза
Мониторить
Не забывайте мониторить ошибки, нагрузку на сервера. Также стоит обратить внимание на KPI: если вы сделали релиз и у вас упало DAU, то, возможно, что-то работает не так хорошо, как должно было, либо сломаны сами средства мониторинга. Любую подозрительную активность стоит проверить.
Сообщить об успехах и неудачах
Намного лучше если о проблеме узнают от разработчиков, а не от пользователей. И конечно же, если вы решили какие-то проблемы, то этим можно смело похвалиться.
Провести ретроспективу
Это, конечно же, частично зависит от методологии разработки, но если что-то в процессе релиза пошло не так — это стоит обсудить. Если что-то было хорошо, то это также стоит обсудить. В идеале на доске на каждый пункт неудачи должен быть пункт успеха либо благодарность коллеге. Это поможет не скатить ретроспективу в нытье и негатив.
Заказать пиццу и отпраздновать
Во время таких посиделок просто коллеги становятся друзьями и боевыми товарищами. А это значит, что в следующем бою друзья не подведут.
Начать подготовку к следующему релизу
Мне очень нравится идея Release train, когда каждый релиз проходит регулярно в четко обозначенные даты. Благодаря этому механизм релиза отлаживается командой. Как я писал выше, не обязательно делать релиз на 100% пользователей: можно выкатить на небольшую группу людей.
Управлять релизом просто: правила и этапы release management
Релиз является одним из самых важных и ожидаемых событий в жизненном цикле продукта. Приготовления к релизу могут занимать много усилий и времени, участия всей команды и заинтересованных сторон. Хорошо, если выпуск продукта или его версии проходит гладко и становится настоящим праздником. Но бывает иначе. Что из себя представляет эффективный релиз-менеджмент и как менеджерам продукта научиться его секретам?
Релиз связан с запуском нового продукта/сервиса/услуги или набором новых функций, изменений, которые становятся доступны клиентам или пользователям и обеспечивают новую продуктовую ценность.
Часто релиз состоит из ряда решений по устранению проблем и улучшений предоставляемых услуг, может включать изменения в ПО. На самом деле, это довольно значимое событие как для внутренних команд, так и для целевой аудитории.
Управление релизами помогает командам планировать свою работу и видеть конечный результат, а для клиентов это, своего рода, гарантия качества и получения новой ценности.
Хорошо подготовленный релиз — это не только предоставление доступа к новым техническим возможностям продукта. Это конечная дата, когда ваша команда может предоставить новый пользовательский опыт, поддержать и развить взаимодействие с ним.
Релизы должны включать все дополнительные задачи и активности, такие, например, как обновления на официальном сайте и в социальных сетях, обучение команды поддержки, обновление всех маркетинговых материалов и т. д.
Основная цель управления релизом — создавать, тестировать и доставлять новые возможности, которые будут удовлетворять все продуктовые требования и намеченные цели.
Продуктовым командам стоит тщательно планировать релизы, поскольку они являются новым предложением, которое ожидают клиенты.
Что включает процесс управления релизом?
Понимание процесса управления выпуском продукта может отличаться у разработчиков и нетехнических специалистов. Важно учитывать все аспекты релиза и прислушиваться к мнению каждого члена команды.
Процесс управления релизом может включать следующие этапы:
В управлении релизом продукта могут участвовать практически все члены команды.
Product manager и Project Manager
Менеджеры продуктов и менеджеры проектов несут основную ответственность за релиз. Функционал product manager project и manager отличается, но миссия у них одна — выпустить продукт и представить его клиентам в идеальном виде.
Разбработчики
Команда разработки — это ключевые игроки в управлении релизом, поскольку они участвуют в большинстве процессов в жизненном цикле продукта. Они оценивают изначальные затраты и время, определяют основные требования, создают документацию и разрабатывают функциональность. Они принимают главные решения о том, что можно сделать и что не нужно, а также сколько времени это займет.
Маркетинг
Маркетологи всегда должны “держать руку на пульсе” и быть в курсе того, чем живут конкуренты. В управлении релизом им важно тесно отрудничать с sales-менеджерами для получения новых и удержания существующих клиентов.
Тестировщики
Тестировщики работают вместе с разработчиками. Их задача — тестировать результаты исследований и разработки, основываясь на установленных критериях. Продукт не придет к релизу, пока не будут учтены все замечания и критерии прохождения тестирований.
Служба поддержки
Support-команда или отдельный специалист поддержки первыми получают сообщения, елси что-то пошло не так. Они должны понимать и знать все о релизе и должны быть должным образом подготовлены на всех уровнях еще на стадии планирования.
Помимо этих основных ролей, к управлению релизом могут привлекаться и другие специалисты: отдела закупок, финансисты, sales, биллинг, system engineering и др.
Почему нужно внедрять процесса управления релизам?
Что такое Release Notes в процессе управления релизом?
Release Notes — это примечания к версии продукта, в которых описываются изменения между выпускаемой и предыдущей версиями этого продукта. Такой документ может составляться для пользователей и для внутренних команд: тестировщиков, маркетологов, службы поддержки.
Когда используются примечания к релизу?
Примечания к релизу распространяются вместе с продуктами. Иногда — когда продукты все еще находятся в разработке или тестировании. Документ может быть доставлен клиентам при выпуске обновления (для продуктов, которые уже были использованы клиентами).
Вы можете найти различные варианты написания Release Notes, поскольку для этого документа нет единого стандарта или формата. В разных компаниях менеджеры продуктов, тестировщики и разработчики, которые обычно ответственны за написание примечаний, обычно используют свои собственные шаблоны.
Вот как выглядит страница с примечаниями к релизу у Firefox:
Как писать примечания к релизу?
Содержание документа зависит от типа релиза. Вот пример основных пунктов:
Заключение
Управление релизом во многих компаниях становится отдельным самостоятельным процессом, который сообщает заказчику дату выпуска продукта и основные этапы его развития. Заказчик участвует в приоритизации и вовлечен в определение содержания релиза.
Процесс позволяет менеджерам продуктов и команде своевременно оценить загрузку и управлять объемом работ, доставлять изменения в срок. Управление релизами позволяет собирать собственную статистику, с которой удобнее в дальнейшем обосновывать запросы на дополнительные ресурсы.
Если вы хотите детальнее разобраться в теме release management и отыскать интересные инсайты разных компаний, следующие книги будут полезными: (на английском языке)