#рабочийпроцесс #релиз

Релиз по скоупу задач.
Основной принцип: после/перед/во время каждого релиза происходит планирование следующего. Со всеми сторонами согласовывается чёткий список задач, которые будут выпущены в следующем релизе и очень примерные сроки этого релиза. Когда оговоренные задачи готовы, происходит отсечка релизной ветки и никакие другие задачи в неё не входят.
Как выглядит процесс: во время планирования релиза задачи набираются из беклога команды, обсуждаются, примерно оцениваются, исходя из этого даётся примерный срок выпуска релиза (тут лучше всего оговаривать три варианта: оптимистичный, пессимистичный и нормальный). Ко времени, когда все задачи готовы (разработаны и протестированы), отсекается релизная ветка. Важно, чтобы новые, не оговоренные задачи, не входили в релиз, чтобы не происходило раздувание скоупа и усложнение регресса. На релизной ветке проводится регресс, вносятся правки обнаруженных багов и если всё хорошо, ветка льётся в прод (тут хорошо бы проводить ретро по релизу и смотреть попали ли мы в оценки и сроки и если нет, то почему и как в следущий раз оценивать точнее).
Подводные камни: бывает, что возникают какие-то срочные задачи, которые не вошли в релиз и такие моменты стоит заранее проговорить и зафиксировать правила, например, золотое правило: "впихивая невпихуемое выпихивается ранее впихнутое", т.е если надо добавить срочную задачу, то какую-то другую, аналогичную по оценке задачу мы из скоупа убираем.
У этого подхода довольно высокий риск скатиться к хаотичным релизам (про них напишу позже).
Задача тестировщика: примерно такая же, как и всегда - вовремя давать обратную связь по задачам, которые планируются в релиз и вовремя давать обратную связь по регрессу.
Задача релиз-менеджера (не технического):
1. следить, чтобы на запланированных в релиз задачах был проставлен соответствующий релиз
2. следить, чтобы команда занималась только релизными задачами или техническими, если релизные закончились
3. договариваться с заказчиками про "внезапные срочные" задачи и вовремя выпихивать ещё не начатые задачи, добавляя на их место "срочные"
4. следить, чтобы в нужное время все релизные задачи были слиты в релизную ветку, а не релизные НЕ слиты!!
5. отслеживать степень готовности релизной ветки к выпуску и работать с рисками, угрожающими затянуть релиз.
6. при необходимости готовить материалы для оповещения бизнесу по релизнутым задачам и релиз ноутс для пользователей.

P.S. ещё раз напомню, что в пятницу и перед праздниками лучше не релизиться 😅
Ну и моё мнение - релизы по скоупу задач чаще всего превращаются в хаотичные, мне приятнее работать либо с календарными релизными, либо без релизов (позадачный выпуск в прод).

Не знаю такой ли славы я хотела, но это было неожиданно 😂

#рабочийпроцесс #бесплатное

По следам доклада из предыдущего поста написала статью: кому неудобно смотреть, можно прочитать 😊
https://habr.com/ru/companies/sportmaster_lab/articles/760576/

#общее #рабочийпроцесс

Удачная выдалась неделя! Выложили подкаст, в котором я приняла участие. Выпуск посвящен работе тестировщика и в частности моей работе куратора в Спортмастере, обсудили с Арсением разные интересные вопросы, было здорово, с удовольствием поучаствую и в других подкастах, мне понравилось! 😊
https://t.iss.one/RedBarn_ru/3807

#общее #рабочийпроцесс

А пока пишется следующий пост про релизы, вышло моё интервью у Лёши Пименова с нетипичными вопросами о тестировании и тестировщиках 😊
https://youtu.be/XqKsXKXyABA?si=dRLYJ5fwUJHVmLwS

#рабочийпроцесс #релиз

Еще один подход к релизу:
релиз по требованию, инициируемый ЛПР (лицом, принимающим решение).
Основной принцип: есть ЛПР и договоренность в команде, что релиз инициируется его требованием, при этом, чем руководствуется ЛПР может и не обсуждаться. Задачи, которые войдут в релиз определяются ЛПР в день принятия решения исходя из готовности задач и мотивов необходимости релиза.
Как выглядит процесс:
Команда заранее договаривается, сколько времени займут приготовления к релизу (сливания, регрессы и т.д.). ЛПР, зная про эти сроки, планирует релиз: даёт отмашку команде, что надо начинать подготовку релиза, может оговорить какие задачи в него должны войти или по умолчанию туда входят все задачи, которые к этому времени готовы.
Таким образом отсекается релизная ветка и туда больше никакие новые задачи не вносятся. На этой ветке проводится регрессионное тестирование и если всё хорошо, в условленную дату ветка льётся в прод.
Подводные камни:
1. подготовительные работы для выпуска релиза могут задержаться дольше, чем планировали
2. на середине подготовки релиза ЛПР может сказать, что появилась острая необходимость в еще одной/-тцати задачах, которые просто обязаны войти в этот релиз и значит надо начинать всё если не сначала, то почти сначала.
Как можно нивелировать риск "подводных камней":
1. после каждого релиза проводить ретро и заново оценивать время на подготовку релиза, учитывать нововыявленные риски, если такие были.
2. ЛПР должен договориться с бизнесом, что если докидываются задачи уже после отмашки, то это повлияет на сроки (тут стоит обговорить либо конкретные сроки в общем случае для любых задач, либо то, что сроки будут зависеть от докидываемой задачи)
Задача тестировщика: здраво оценивать трудозатраты на тестирование задач и на проведение регресса, учитывая возможные риски и своевременно сигнализировать о проблемах и состоянии релиз-кандидата.
Задача релиз-менеджера, в данной ситуации скорее всего он же ЛПР:
1. своевременно размечать запланированные в релиз задачи
2. следить, чтобы задачи, не вошедшие в релиз не имели отметки текущего релиза
3. следить, чтобы релизные задачи были слиты в релизную ветку, а не релизные НЕ слиты!!
4. следить, чтобы в релизную ветку не добавлялись новые задачи без соответствующей отмашки
5. отслеживать степень готовности релизной ветки к выпуску и вовремя предпринимать нужные действия, чтобы выпустить релиз в обозначенный заранее срок или своевременно предупреждать бизнес о задержке.
6. при необходимости готовит материалы для оповещения бизнесу по задачам и релиз ноутс для пользователей

P.S.
Если у вас остались вопросы, пишите в чатике.
Если вам нужна консультация по конкретному вашему кейсу, пишите в личку, за определенную оплату могу провести консультацию или серию консультаций.

P.P.S. Про какие еще подходы к релизам вы слышали? Или разбор каких вопросов вы хотели бы тут еще увидеть? Накидывайте в чатик 😊

#анонс

Други, уже завтра начинается наша любимая SQA days, впервые устраиваю круглый стол, кто будет, заходите! 😊
https://sqadays.com/ru/talk/112207

И, конечно, приходите на наш стенд SM Lab, у нас в этот раз будет очень крутой движ, еще круче, чем раньше! Не пропустите! 😉
https://t.iss.one/sqadays/13095

И еще пушка-бомба новость! Мы выпустили ролик про наше QA в SM Lab, я непосредственно приложила руки к этой поделке! https://www.youtube.com/watch?v=ghJhQpaOPAo