Русский
Русский
English
Статистика
Реклама

Эволюция работы с техническим долгом

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

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

Немного теории

Технический долг справа внизуТехнический долг справа внизу

Что такое технический долг?Технический долг - работы, если их не сделать, несут ущерб невидимый для пользователя (ручная настройка фичи, нечитаемые/отсутствие логов).

Результат погашения технического долга не виден пользователю, но повысит качество продукта (надежность, безопасность, скорость разработки, стабильность).

Каждый берет, то, что ему ближе

Когда продукт новый, тех. долга у него, немного. Из-за этого у нас не было какого-то механизма ранжирования задач, которые попадают в технический долг, как не было механизма для погашения, кроме собственного энтузиазма разработчиков. Принцип бойскаута - это про нас. На самом деле, всё было не столь радужно.

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

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

Из-за отсутствия механизма ранжирования задач, каждый брал то, что интересно ему. А из-за отсутствия процесса, который позволял бы задачам дойти до боевых серверов, такие задачи часто застревали где-то в районе code-review или тестирования (ведь основные задачи всегда более приоритетны!)

Собственный велосипед для ранжирования

Мы не стали брать какую-то готовую систему оценки, которую кроме того, что применить, нужно еще и подстроить для себя, а сделали собственную.

Каждую из задач технического долга мы оценивали по 4 критериям:

  • Повторяемость - как часто мы сталкиваемся с этой проблемой. (0 - очень редко, раз в полгода, 5 - каждый день)

  • Скорость доставки - как данная задача повлияет на скорость доставки других фичей. (скорость разработки, время тестирования, время деплоймента, предсказуемость разработки) (0 - не влияет, 5 - экономит очень много времени)

  • Влияние на время оперирования (расходы на эксплуатацию, нагрузка на сервер, безопасность) (0 - не влияет, 5 серьезно снижает расходы и риски оперирования)

  • Уровень технической инвестиции (0 - это не инвестиция, 5 - технический энейблер для большого ряда задач)

Каждую задачу мы оценили в привычных для нас story points, чтобы оценить сложность.

Исходя из этих параметров, мы можем посчитать условное TechDebt Value, на основе которого задачи ранжируются (чем больше, тем важнее).

В формуле можно заметить коэффициенты X, Y и Z. Они нужны для того, чтобы в каждый момент времени мы могли повлиять на наш скоринг - если для текущего состояния продукта нам больше важна скорость доставки, то сделать X больше чем Y и Z и всё в таком духе.

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

Самое сложное в этом процессе - собрать команду и вместе оценить все задачи тех. долга по каждому критерию.

А что же с гашением? Здесь постарались договориться с нашим владельцем продукта, чтобы часть задач технического долга делалась в рамках спринта, на равне с продуктовыми задачами.

Упрощаем процесс

Поняв, что текущая оценка достаточно сложная и долгая, мы решили отказаться от неё.

Но чем заменить?

Решили оценить влияние на техническое состояние продукта одним числом, так, как делаем это с оценкой в story point - на основе сравнения с другими задачами. Не важно, влияет это на оперирование или на скорость доставки, если влияют одинаково, то и оценка будет одна и та же.

Раз в квартал оцениваем все задачи - учитывая, количество технического долга и количество разработчиков, за час каждый может оценить 10-15 задач. Если кто-то не согласен с оценкой, обсуждаем.

Процесс погашения тоже претерпел изменения.

Среди задач, всегда есть какие-то совсем простые. Чтобы не занимать место в спринте (оно ограничено нашим capacity), решили собрать из них новую доску. В рамках любой продуктовой задачи, можно сделать и какую-нибудь маленькую задачу, улучшив продукт.

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

А дальше?

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

Источник: habr.com
К списку статей
Опубликовано: 24.11.2020 10:23:43
0

Сейчас читают

Комментариев (0)
Имя
Электронная почта

Agile

Управление продуктом

Scrum

Техдолг

Технический долг

Tech debt

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru