Как правильно управлять проектом Releases в Асане?
Небольшой список правил и вещей, которые помогут вести проект Releases правильно и приоритизировать задачи.
  • Прописать все задачи в формате User Stories: "Я, как пользователь, хочу иметь возможность делать что-то для чего-то"

  • Все задачи для реализации конкретной User Stories должны быть прописаны в под-задачи этой User Stories. То есть, все задачи: Frontend (Web, Mobile), Backend, Design - не важно. Всё для реализации этой User Stories.

  • В предcтоящий релиз вносятся только самые приоритетные User Stories

  • Все задачи для реализации самых приоритетных User Stories должны быть оценены (хотя бы на предстоящий релиз)

  • Самые приоритетные задачи (то есть, под-задачи) для реализации самых приоритетных User Stories должны быть в нынешнем спринте. Тем самым, мы видим над каким именно функционалом работает каждый инженер.

  • Как идёт нумерация релиза? Например, 4.1.2. Первая цифра "4" - это большой релиз большого функционала (например, релиз Medcheck ID). Вторая цифра "1" - это улучшение существующего функционала (например, добавление экстренных контактов в Medcheck ID). Третья цифра "2" - это исправление багов, мелких ошибок, опечаток и любые мелкие задачи (например, исправление текста в статье, исправление расположение текста по центру).

  • У каждой задачи должен быть проставлен тэг: Frontend, Backend, Design, Infra, Flutter, Sign In, Sign Out, Transactions и т.д. - то есть, мы тэгаем задачи по технологиям и по функционалу

  • Релиз нужно делать еженедельно, или, как минимум, стараться делать их еженедельно. Даже если ты просто исправил один пробел или небольшой текст - выпускайте релиз. Команда должна привыкать выпускать апдейты еженедельно.

  • Каждый релиз должен иметь своё название и чёткий Release Note.
© 2022 Mancho Devs (ОсОО «Прораб»)
Все права защищены.
Разделы