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

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

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

Требования инженера к продукту:

  • Следовать правилам семантического версирования
  • Поддерживать предыдущие мажорные версии в течение двух лет
  • По возможности выпускать мажорные версии не чаще раза в год
  • Поддерживать текущую стабильную версию багфикс-релизами в процессе разработки следующей минорной или мажорной
  • Иметь клиентоориентированные релиз ноуты
  • При релизе мажорной версии публиковать также гайды по миграции

Работа методолога:

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

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

Для того чтобы обеспечить поддержку текущей стабильной версии багфиксами в процессе активной разработки следующей:

  • Вводим стратегию работы с ветками git flow.
  • На этапе планирования спринта вводим практику выделения критичных багов, которые должны в первую очередь чиниться в текущей стабильной версии.

Практика показала что писать релиз ноуты в процессе релиза, когда могло пройти много времени с момента реализации фичи, и многие детали забылись, бывает непросто. Поэтому пробуем практику, где текст релиз-ноута, направленный на пользователя, делается частью definition of done для фичи. В процессе подготовки к релизу эти тексты собираются в релиз-ноуты, с правками по необходимости.

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

Требование выпускать мажорную версию не чаще раза в год методологом полностью обеспечиться не может. Это в основном зависит от инженера по требованиям.