- PVSM.RU - https://www.pvsm.ru -
Мы продолжаем делиться с сообществом внутренней кухней Retail Rocket [1], и сегодня расскажем о нашем подходе к работе с бэклогом. Правильная приоритезация задач — это первый шаг в решении таких важных проблем проекта как:
За годы существования проекта у нас сложилась система, при которой вся работа со списком задач подчиняется двум принципам: «не начинай новое, если не закончил старое» и «всегда расчищай место для нового функционала».
Вот как эти два принципа воплощаются в правила приоритезации бэклога.
Если вы уверены, что нашли баг, его следует исправить в первую очередь, до разработки любого нового функционала. Следовать этому правилу необходимо по следующим причинам:
Важно подчеркнуть, что речь идет не о расширении функционала, а о доработках, каких-то неточностей (они могут быть довольно существенные). Если вдруг после выпуска функционала в бой выяснилось, что какие-то детали не были учтены на этапе проектирования, эти доработки должны идти по приоритету сразу после багов. Причина, по которой этот тип задач идет впереди остальных, та же, что и в работе с багами — это ранее начатый, но не законченный функционал, а значит, нужно закончить все доработки прежде, чем браться за что-то новое.
Я еще не встречал компаний за свою практику (а это более 10 компаний в которых работал сам, и примерно столько же, с которыми хорошо знаком изнутри), кроме нашей, у которых в бэклоге были бы задачи на удаление функционала, хотя, наверное, такие существуют. Каждая новая фича увеличивает стоимость производства следующей фичи, иными словами сделать 10-ю фичу в проекте гораздо проще, чем 5000-ую фичу. Это происходит из-за того, что при разработке последней надо разобраться, как она вписывается во все 4999 ранее сделанных фич.
Также большое кол-во фич снижает скорость сборки проекта и скорость прохождения тестов, что в совокупности сильно усложняет работу над 5000-ой фичей, а значит снижение количества фич в проекте положительно влияет на скорость производства новых.
Мы разработали для себя следующую формулу: на каждые 3 человеко-дня разработки нового функционала берутся в работу 2 человеко-дня на устранение технического долга и 2 человеко-дня на улучшения системы в целом (intangible задачи). О коэффициентах (2 или 3 человеко-дня) можно спорить, и они, конечно же, могут и должны меняться в зависимости от этапов жизни проекта. Но сама идея о том, что на каждый затраченный на новый функционал человеко-день, мы должны выполнить и задачи по техническому долгу, и задачи по улучшению системы в целом, довольно очевидна.
В заключение можно сказать, что реальная работа, конечно же, сложнее придуманных правил и иногда нам приходится их нарушать или отходить от них, но в повседневной работе само наличие правил сильно упрощают жизнь.
Пишите в комментариях ваши мысли о том, как вы работаете в бэклогом и делитесь ссылками на материалы которые вам понравились.
Андрей Чиж,
CTO Retail Rocket
P.S.
Мы всегда рады новым членам команды и у нас открыто сразу несколько вакансий на позицию “.NET Разработчик” [2]. Наш технологический стек и уровень задач можно оценить в самом первом посте на Хабре [3]. Резюме можно прислать сразу мне на почту avchizh@retailrocket.ru [4] (HR-ов у нас нет, общаться будем сразу напрямую).
Автор: chizh_andrey
Источник [5]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/razrabotka/256084
Ссылки в тексте:
[1] Retail Rocket: https://retailrocket.ru
[2] вакансий на позицию “.NET Разработчик”: http://retailrocket.ru/vakansii/#net
[3] в самом первом посте на Хабре: https://habrahabr.ru/company/retailrocket/blog/246793/
[4] avchizh@retailrocket.ru: mailto:avchizh@retailrocket.ru
[5] Источник: https://habrahabr.ru/post/329346/
Нажмите здесь для печати.