Что такое релиз нота

release note

A typical set of release notes for an RTOS includes a list of all the bugs that have been uncovered in the software. — Типичный набор ПЗ к релизу ОС РВ содержит список всех ошибок, обнаруженных в этой системе см. тж. testing

Англо-русский толковый словарь терминов и сокращений по ВТ, Интернету и программированию. . 1998-2007 .

Смотреть что такое «release note» в других словарях:

release note — A computer printout, or manual equivalent, for a consignment of goods which has been given Customs release. HM Customs & Revenue Glossary … Financial and business terms

release note — /rɪ li:s nəυt/ noun a note from a bank to say that a bill of exchange has been paid … Dictionary of banking and finance

Release notes — are documents which are distributed along with software products, often when the product is still in the development or test state (e.g., a beta release). For products that have already been in use by clients, the release note is a supplementary… … Wikipedia

Note Out — release poster Directed by Kutty Naduvil Produced by Joseph George … Wikipedia

Release Management — is the relatively new but rapidly growing discipline within software engineering of managing software releases.As software systems, software development processes, and resources become more distributed, they invariably become more specialized and … Wikipedia

Note Printing Australia — (NPA), which is located in Craigieburn, Melbourne, is a wholly owned subsidiary of the Reserve Bank of Australia and was corporatised in July 1998. NPA has its origins as a subsidiary of the Commonwealth Bank and was established in 1913 to print… … Wikipedia

Note to Self EP — EP by Richy Nix Released March 23, 2010 Recorded 2009 2010 Genre Rap rock / Alternative Rock … Wikipedia

Release Candidate — Version d un logiciel Une version d un logiciel correspond à un état donné de l évolution d un produit logiciel utilisant le versionnage. Selon le Grand dictionnaire terminologique, le versionnage (équivalent francophone de l anglais versioning)… … Wikipédia en Français

Release candidate — Version d un logiciel Une version d un logiciel correspond à un état donné de l évolution d un produit logiciel utilisant le versionnage. Selon le Grand dictionnaire terminologique, le versionnage (équivalent francophone de l anglais versioning)… … Wikipédia en Français

Note by Note: The Making of Steinway L1037 — For other uses, see Steinway (disambiguation). Note by Note: The Making of Steinway L1037 Directed by Ben Niles Produced by Ben Niles, Geoff O Brien … Wikipedia

Myofascial Release — is a form of soft tissue therapy which includes, but is not limited to, structural assessments and manual massage techniques for stretching the fascia and releasing bonds between fascia, integument, muscles, and bones are applied with the goal of … Wikipedia

Источник

Release Notes: Пользу или юмор вперёд?

Вот, как это выглядит для меня: «Мы месяц занимались неведомой хренью, поэтому выкатили обновление, но там ничего полезного нет. Чтобы хоть что-то написать, мы сейчас пошутим. Шутим. Шутим. Пошутили».

Редактор и маркетолог Ника Троицкая в блоге «Биодинамической редакции» рассказала, что ничего хорошего в смешных Release notes на самом деле нет, и что прежде всего от них должна быть польза.

Некоторые люди находят уместными шутки в App Store — там, где разработчики по идее пишут, что нового появилось в приложении.

Вот, как это выглядит для меня: «Мы месяц занимались неведомой хренью, поэтому выкатили обновление, но там ничего полезного нет. Чтобы хоть что-то написать, мы сейчас пошутим. Шутим. Шутим. Пошутили». Такие шутейки я встречала у Рокетбанка и 2ГИСа.

Аналогично бесполезен в таких описаниях рассказ о том, как «нам важно ваше мнение, спасибо что делитесь впечатлениями, мы стараемся для вас, бла-бла-бла». Пустословие. Например, этим страдает Facebook.

Мне нравится, когда компании пишут, что реального они исправили, даже если это небольшое изменение. Так делает Модульбанк, Twitter, Тинькофф-банк. Я считаю, описание «Что нового» решает две задачи:

1. Рассказывает пользователям о новых фичах. Иногда они не очевидны, особенно если это небольшие нововведения.
2. Показывает, что компании не дурака валяют и действительно стараются стать лучше.

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

В комментариях к посту Ники на Facebook встретилось и несколько противоположных мнений.

У этих комментов Рокета главная цель — чтобы люди это обсуждали. Они, в общем, этого добились 🙂 Круче всех конечно были Альфа.

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

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

• Есть минорное обновление, которое надо выпустить (грубо говоря, исправлена пара багов, это нужно релизнуть, практически никто ничего не заметит);
• Не хочется отписываться в стиле «БАГ ФИКСЕС», «НЕЗНАЧИТЕЛЬНЫЕ УЛУЧШЕНИЯ»;
• Ребята пишут, что так и так, ничего нового и значительного для юзера, и вполне, кстати, по канонам инфостиля, все честно, как есть 🙂
• В итоге РН расходится вирусно по Пикабу и всяким пабликам. Это хорошо? Это *** (очень хорошо), потому что вирусный охват нахаляву.

То, что надо делать обновления пореже, чтобы делать РН поинтереснее — это вообще булшит на 146%. Если баги есть — надо править. Если в App Store их нужно заливать через мучительный процесс с написанием РН — пусть пишут и шутят, блин! В мире и так **** (очень много) унылого говна, а ребятам весело.

И, да, фидбек на эту шутейку был так хорош, что даже до инстастори моих знакомых долетело 🙂 Как сммщица я в восторге.

Источник

Правила написания Release Notes

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

Состав документа

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

Сам документ состоит из следующих разделов:

Краткое описание продукта

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

Что нового

Изменение функциональности относительно прошлой версии. Перечисление основных изменений с их кратким описанием. Цель раздела — объяснить пользователю зачем ему тратить своё время и переходить на новую версию.

Исправленные ошибки

Список исправленных ошибок относительно предыдущей версии. Как и предыдущий раздел, этот тоже стимулирует пользователя на апгрейд. Обязательно описать исправленные проблемы, на которые жаловались клиенты и которые были заявлены как known issues в прошлых версиях. Крайне желательно описать те серьезные проблемы, с которыми пользователь мог столкнуться в прошлых версиях, но жалоб на них не поступало. Отсутствие жалоб вовсе не означает, что с ними никто сталкивался. Возможно люди мучились, но у них не хватило сил пробиться через поддержку.

Включать в этот список все содержимое баг трекера не нужно:

• Если баг был сделан, найден и исправлен в процессе разработки текущей версии, то пользователь его видеть не мог, а значит и писать о нем смысла нет.
• Если баг был в прошлой версии, но пользователь его с ним не мог столкнуться. Например, проблема была прикрыта заплаткой в стиле «программа падает при вводе имени пользователя длинной более 10 символов, поэтому мы сделали ограничение на ввод в 9 символов».

Удобно указывать ID проблемы, для удобства истории ошибки.

Список известных проблем или known issues

Если у вас нет known issues – значит никто не тестировал продукт.

Приводим список известных проблем (багов). Идеально, если в нем содержатся все актуальные баги для данной версии. Если их слишком много, то выбираем наиболее критичные для пользователя. Для каждого бага нужно указывать:

• ID по которому дальше можно отслеживать его судьбу.
• Workaround. Что делать пользователю, если он встретился с данной проблемой? Если workaround’а нет для критичного бага, значит продукт содержит критическую проблему и не готов к релизу.

Есть соблазн написать в этот раздел поменьше, чтобы не пугать клиентов. Всех, кто так считает, можно отправить к рассказу Драгунского «Тайное становится явным». Если клиенты действительно используют продукт, то все равно они найдут все эти баги, в дополнение у них еще появятся вопросы к качеству тестирования продукта производителем. А так вы честно демонстрируете открытость клиентам и сразу выдаете список woraround’ов, снижая затраты на поддержку.

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

Технические ограничения

Любое ПО имеет технические ограничения. Ваш сервер позволяет работать одновременно 10 пользователям? В базу можно сделать только 10000 записей? UI рассчитан только на Full HD? Напишите об этом.

Системные требования

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

Если параметры железа зависят от сценариев использования продукта, например, от количества пользователей, сложности вычислений, количества данных в базе, то хорошо сделать sizing guide. Это таблица в стиле: если ожидается такая нагрузка, то рекомендуется такое железо.

Особенности обновления с прошлой версии.

Апдейт не всегда проходит гладко. А потеря данных пользователя вообще караул. Лучше сразу предупредить о возможных проблемах.

Кто пишет документ

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

Все новости сайта в телеграм канале: @pmlife_ru

Источник

Автоматизируем подготовку 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.

Источник