Вот такой получился Kanban

В моей команде мы используем следующий подход к приоритезации задач и процессу разработки.

У нас определено 5 слоев приоритетности реализации features:

  1. Реализация бизнес-задач, которые приносят выручку/прибыль компании — подключение новых партнеров, типов услуг, ускорение того что должно быть быстрым, снижение лагов.
  2. Реализация задач, которые не дают потерять прибыль компании  — оптимизации, профилактика ошибок, исправление техдолгов, бекапы, резервирование.
  3. То, что влияет на принятие решений — статистика в различных разрезах, отчетность, графики, инструменты аналитики.
  4. Улучшения, которые снижают нагрузку на техническую команду — автоматизация того, что можно, чтобы все кто хочет получить те или иные данные/сборки/отчеты могли их самостоятельно запросить из системы и получить.
  5. Ошибки, улучшения не влияющие на принятие решений — улучшения в веб интерфейсе, скорости работы личного кабинета, добавление мелкой функциональности которая делает работу удобнее.

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

Термины юзерстори или эпик мы нигде не употребляем. Просто если есть какая-то важная большая задача (Мамонт) она идет в каком-то из этих слоев нарезанная по кусочкам.

И есть одна «красная линия» с высочайшим приоритетом: для задач асап/ критическим багом в продакшене.

Процесс один: беклог -> аналитика -> аналитика готова -> разработка -> разработка готова -> тестирование локально -> кодревью -> тестирование на стеджинге -> тестирование завершено -> выкат на прод -> тестирование на проде -> тесткейсы в вики -> автотест на ui -> внесение в регрессионый план -> завершено.

Популярное