Хабр, привет! Мы продолжаем делиться с сообществом внутренней кухней Retail Rocket, и сегодня расскажем о нашем подходе к работе с бэклогом. Правильная приоритезация задач — это первый шаг в решении таких важных проблем проекта как:
За годы существования проекта у нас сложилась система, при которой вся работа со списком задач подчиняется двум принципам: «не начинай новое, если не закончил старое» и «всегда расчищай место для нового функционала».
Вот как эти два принципа воплощаются в правила приоритезации бэклога.
Если вы уверены, что нашли баг, его следует исправить в первую очередь, до разработки любого нового функционала. Следовать этому правилу необходимо по следующим причинам:
Важно подчеркнуть, что речь идет не о расширении функционала, а о доработках, каких-то неточностей (они могут быть довольно существенные). Если вдруг после выпуска функционала в бой выяснилось, что какие-то детали не были учтены на этапе проектирования, эти доработки должны идти по приоритету сразу после багов. Причина, по которой этот тип задач идет впереди остальных, та же, что и в работе с багами — это ранее начатый, но не законченный функционал, а значит, нужно закончить все доработки прежде, чем браться за что-то новое.
Я еще не встречал компаний за свою практику (а это более 10 компаний в которых работал сам, и примерно столько же, с которыми хорошо знаком изнутри), кроме нашей, у которых в бэклоге были бы задачи на удаление функционала, хотя, наверное, такие существуют. Каждая новая фича увеличивает стоимость производства следующей фичи, иными словами сделать 10-ю фичу в проекте гораздо проще, чем 5000-ую фичу. Это происходит из-за того, что при разработке последней надо разобраться, как она вписывается во все 4999 ранее сделанных фич.
Также большое кол-во фич снижает скорость сборки проекта и скорость прохождения тестов, что в совокупности сильно усложняет работу над 5000-ой фичей, а значит снижение количества фич в проекте положительно влияет на скорость производства новых.
Мы разработали для себя следующую формулу: на каждые 3 человеко-дня разработки нового функционала берутся в работу 2 человеко-дня на устранение технического долга и 2 человеко-дня на улучшения системы в целом (intangible задачи). О коэффициентах (2 или 3 человеко-дня) можно спорить, и они, конечно же, могут и должны меняться в зависимости от этапов жизни проекта. Но сама идея о том, что на каждый затраченный на новый функционал человеко-день, мы должны выполнить и задачи по техническому долгу, и задачи по улучшению системы в целом, довольно очевидна.
В заключение можно сказать, что реальная работа, конечно же, сложнее придуманных правил и иногда нам приходится их нарушать или отходить от них, но в повседневной работе само наличие правил сильно упрощают жизнь.
Пишите в комментариях ваши мысли о том, как вы работаете в бэклогом и делитесь ссылками на материалы которые вам понравились.
Андрей Чиж,
CTO Retail Rocket
P.S.
Мы всегда рады новым членам команды и у нас открыто сразу несколько вакансий на позицию “.NET Разработчик”. Наш технологический стек и уровень задач можно оценить в самом первом посте на Хабре. Резюме можно прислать сразу мне на почту avchizh@retailrocket.ru (HR-ов у нас нет, общаться будем сразу напрямую).
- уменьшение технического долга,
- поддержка скорости работы производства,
- поддержка качества продукта.
За годы существования проекта у нас сложилась система, при которой вся работа со списком задач подчиняется двум принципам: «не начинай новое, если не закончил старое» и «всегда расчищай место для нового функционала».
Вот как эти два принципа воплощаются в правила приоритезации бэклога.
Первый приоритет всегда отдается работе с багами
Если вы уверены, что нашли баг, его следует исправить в первую очередь, до разработки любого нового функционала. Следовать этому правилу необходимо по следующим причинам:
- Баг- это ранее разработанный функционал, в котором допущена ошибка, а следовательно, подчиняется первому принципу «не начинай новое, если не закончил старое».
- Из-за багов в системе может быть затруднена разработка новых функций системы, т.к. эти функции приходится вписывать в среду с багами. Это не только сложно, но и деморализует команду. Здесь вступает в силу второй принцип «всегда расчищай место для нового функционала».
Вторым приоритетом идут все доработки по созданному ранее функционалу
Важно подчеркнуть, что речь идет не о расширении функционала, а о доработках, каких-то неточностей (они могут быть довольно существенные). Если вдруг после выпуска функционала в бой выяснилось, что какие-то детали не были учтены на этапе проектирования, эти доработки должны идти по приоритету сразу после багов. Причина, по которой этот тип задач идет впереди остальных, та же, что и в работе с багами — это ранее начатый, но не законченный функционал, а значит, нужно закончить все доработки прежде, чем браться за что-то новое.
Третий по значимости приоритет — задачи по удалению старого функционала или MVP-разработок, которые оказались не нужны
Я еще не встречал компаний за свою практику (а это более 10 компаний в которых работал сам, и примерно столько же, с которыми хорошо знаком изнутри), кроме нашей, у которых в бэклоге были бы задачи на удаление функционала, хотя, наверное, такие существуют. Каждая новая фича увеличивает стоимость производства следующей фичи, иными словами сделать 10-ю фичу в проекте гораздо проще, чем 5000-ую фичу. Это происходит из-за того, что при разработке последней надо разобраться, как она вписывается во все 4999 ранее сделанных фич.
Также большое кол-во фич снижает скорость сборки проекта и скорость прохождения тестов, что в совокупности сильно усложняет работу над 5000-ой фичей, а значит снижение количества фич в проекте положительно влияет на скорость производства новых.
И в последнюю очередь нужно заниматься задачами по разработке нового функционала
Мы разработали для себя следующую формулу: на каждые 3 человеко-дня разработки нового функционала берутся в работу 2 человеко-дня на устранение технического долга и 2 человеко-дня на улучшения системы в целом (intangible задачи). О коэффициентах (2 или 3 человеко-дня) можно спорить, и они, конечно же, могут и должны меняться в зависимости от этапов жизни проекта. Но сама идея о том, что на каждый затраченный на новый функционал человеко-день, мы должны выполнить и задачи по техническому долгу, и задачи по улучшению системы в целом, довольно очевидна.
В заключение можно сказать, что реальная работа, конечно же, сложнее придуманных правил и иногда нам приходится их нарушать или отходить от них, но в повседневной работе само наличие правил сильно упрощают жизнь.
Пишите в комментариях ваши мысли о том, как вы работаете в бэклогом и делитесь ссылками на материалы которые вам понравились.
Андрей Чиж,
CTO Retail Rocket
P.S.
Мы всегда рады новым членам команды и у нас открыто сразу несколько вакансий на позицию “.NET Разработчик”. Наш технологический стек и уровень задач можно оценить в самом первом посте на Хабре. Резюме можно прислать сразу мне на почту avchizh@retailrocket.ru (HR-ов у нас нет, общаться будем сразу напрямую).
