Как стать автором
Поиск
Написать публикацию
Обновить

Рефлексия о техдолге и AutoDay

Уровень сложностиПростой
Время на прочтение11 мин
Количество просмотров567
Всего голосов 8: ↑8 и ↓0+9
Комментарии7

Комментарии 7

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

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

Если с бизнесом удалось договориться, то всё отлично, никакой проблемы нет и не нужно изобретать велосипеды в виде AutoDay.

Если договориться не удалось, то остаётся 2 варианта:

  • Смириться с тем, что мир несправедлив и продолжать страдать.

  • Увеличивать время на реализацию бизнес фич, закладывая туда время на исправление техдолга. Либо задачи по исправлению техдолга маскировать под бизнес задачи, чтобы никто не понял, то они про техдолг.

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

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

А тут уже тонкие финансовые зависимости. Нового человека нужно обосновать, а потом постоянно загружать работой)
Можно временно усилить команду - тоже вариант закрывать те или иные проблемы. В нашем случае мы выделили время на работу с техническим долгом

Во-вторых, бизнес приоритезирует бэклог команды.

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

У вас есть спринты. Когда спринт заканчивается, у вас освобождаются ресурсы для выполнения новых задач. Лид команды\менеджер проекта знают, что за 1 спринт команда выполняет 3 задачи, поэтому в конце спринта им надо сообщить бизнесу, чтобы бизнес выбрал 3 задачи для следующего спринта, а там уже сам бизнес определяет, что ему важно в данный момент, а что нет. От лида\менеджера нужно лишь следить, чтобы бизнес не наглел и не пытался запихнуть более 3-х задач в спринт.

Если руководитель какого-то бизнес юнита вовремя не предоставил задачу для следующего спринта, то команда в рамках спринта будет выполнять не 3 задачи, а всего 2. Это приучит бизнес к ответственности и увеличит их вовлечённость в процесс. А команда получит дополнительное время, например, для сокращения техдолга.

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

Зарегистрируйтесь на Хабре, чтобы оставить комментарий