Комментарии 25
Да, только на практике даже показав подобного рода таблички, не всегда уж просто объяснить почему важнее исправлять тех. долг, чем выкатывать новые фитчи и только когда делать новые фитчи становится сильно трудно из-за нерешённых старых проблем, тогда уже становится ясно зачем всё-таки исправлять тех. долг
А когда прижмет, тогда нужно выскочить и гордо произнести: "Ну я же говорил 🤌".
А если серьезно, то конечно бывает и так. Все зависит от степени доверия бизнеса к разработке, которое на 95% зависит от умения укладываться в сроки
Если посчитать затраты времени и финансов на ключевые действия (техдолг, фичи, тесты...) (и долго в них всматриваться :), то можно заметить как одно влияет на другое, или когда геморрой от неконтролируемых фичь начинает превышать предполагаемые затраты на обслуживание техдолга.
Просто надо понять что сравнивать и какое это имеет значение.
Извините за душноту. Но, откуда в слове "фича" (feature) может появиться буква "т"?
Вот, просто, как? :))
Согласен. Много раз сталкивался с возражениями вида "что вы мне своими табличками и терминами голову морочите". И это печально.
Из своей жизни могу привести два варианта борьбы с техдолгом на уровне процессов:
Относительно распространенная практика - выделение квоты на техдолг. Например, вы работаете по спринтам и 20% спринта посвящаете техдолгу. Но тут надо уметь контролировать бизнес, ибо он будет напихивать в ваш спринт бизнесовых задач с горкой и приносить горящие задачи по среди спринта.
Второй вариант борьбы с техдолгом - это явно прописывать то, что должно входить в завершенную задачу (definition of done). Например, надо сделать сервис + тесты (юнит и/или интеграционные) + документация, и если чего-то из этого нет, то задача остается на этапе разработки. А задачу на тесты и документацию выносить в отдельный техдолг только тогда, когда есть угроза срывов дедлайнов или других серьезных проблем. Это не исключает техдолг, но позволяет заложить время на то, чтобы его создавать меньше. На практике несколько раз проходил такой момент, что тесты откладывали в задачу по техдолгу, а потом удаляли десятки задач на тесты, потому что делать их уже никто не планирует. Лучше сразу взять побольше срок на выполнение задачи (в рамках разумного), чем просить на это время.
Спасибо! DoD действительно хорошая и полезная штука, особенно если он составлен совместно разработкой и заказчиком и когда он выполняется. DoD еще и многие другие проблемы позволяет решить
20% спринта посвящаете техдолгу
20% спринта - это один день в неделю. Если в компании столько техдолга, что весь её штат должен один день в неделю заниматься техдолгом, то имхо лучше всего просто убежать от такой компании подальше.
явно прописывать то, что должно входить в завершенную задачу
Выполнять задачи так, чтобы они сразу порождали техдолг - это вообще неприемлемо. Исключение - это какие-то хотфиксы для внезапно упавшего продакшена.
А вообще, полагать, что техдолг - это только недоделки - очень глупо и наивно. Сегодня ты пишешь идеальный код, а через год у тебя половина библиотек устарела, имеет обновления безопасности, но переход на новые версии требует рефакторинга - вот это основная и неизбежная статья техдолга.
Согласен, что 20% может быть многовато для того, чтобы исправлять техдолг, но это были просто числа "например". Это не железное правило. Если команда может не создавать технический долг до тех пор, пока не потребуется обновить все библиотеки или что-то подобное, то можно хоть соотношение 99 к 1 делать с упором на бизнес.
Чтобы задачи не порождали техдолг, надо сперва определиться с тем, что входит в задачу. Например, во фронтенде тесты встречаются гораздо реже, и если захочется исправить ситуацию, то потребуется много времени и сил, чтобы начать их писать (научить команду писать тесты, найти нужную стратегию покрытия тестами кода и т.д.), пока идет подготовка к тестированию - команда уже напишет еще кучу непротестированого кода.
Согласен, что техдолг - это не только недоделки, но и тесты, документация, обновление библиотек, end of life сервисов, перенастройка CI и т.д. Просто "неноделки" можно решать через DoD-ы гораздо проще, чем обновление библиотек.
Отсутствие тестов - это не обязательно техдолг. Должен быть стандарт компании, который предусматривает, какие именно должны быть тесты. И вот только когда стандарт есть, а тестов нет, только тогда отсутствие тестов становится техдолгом. Потому что даже если у вас есть тесты, всегда можно сказать, что их недостаточно. Unit, functional, integration, acceptance, selenium - это далеко не полный список типов тестов, и тут вполне очевидно, что нужно иметь какие-то границы.
Все эти ISO 25010 чаще всего не колышат менеджмент вообще никак. По той простой причине, что этот менеджмент в большинстве случаев наёмный и его KPI завязаны на видимые результаты типа количества фич, пользователей, и иже с ним.
И даже если этот менеджмент понимает что конструкция из костылей в конце концов осыпется, то он рассчитывает что под завалами окажутся как раз разработчики, а уж он то гордо спрыгнет с золотым парашютом. Ну или если он ещё не забрался по карьерной лестнице туда, где парашюты выдают, то просто выставит разработчиков как единственных виновников провала проекта, а сам благополучно уйдёт в другой проект или на повышение.
Согласен, часто бывают такие проблемы. Но это проблема в другой плоскости — какие цели у менеджмента, какие цели у вас и как они между собой согласуются. Если не согласуются или даже противоречат друг другу, то вам не то, что о тех.долге не получится договориться, а в целом по всем вопросам будут конфликты.
Что можно сделать? 1) Эскалировать минимальному общему руководителю; 2) договориться 1:1 об общей цели; 3) внедрить единую систему каскадного целеполагания типа OKR; 4) уволить такого менеджера к чертям собачьим. По своему опыту могу сказать, что эти способы работают. Но конечно не всегда 🤷♂️
Если менеджер и собственник это одно лицо, то все то же самое. Технический долг это что-то там абстрактное на уровне технорей. Ну примерно как уровни изоляции транзакций. Просто какой-то технический шум. Нужно же рубить капусту, и не тратить деньги на всякую фигню. Вот такие типичные рассуждения, будь то наемный менеджер или собственник.
Я обычно устраняю техдолг, пока разрабатываю фичу. Естественно, работы по устранению долгов ведутся только в той зоне, где идет разработка фичи, с учетов поставленных сроков. Если же требуется сделать что-то вне фичи, то порядок стандартный: отдельная задача, оценка, согласование, разработка.
Интересный метод идти от модели качества, спасибо. В последних двух компаниях использую ADR, и все что им не соответствует идёт в задачи техдолга. Но вы правы, самое сложное это описывать consequences на языке бизнеса - в деньгах. Часы и риски ещё куда ни шло, но метрики вроде cognitive complexity человекоцентричны. Можно притянуть числа Фибоначчи как мультипликатор, но разработчики и менеджмент понимают что это уже игра числами за ресурсы.
можете рассказать подробнее? что такое ADR в данном контексте?
Architectural Decision Record. Техлиды команд под руководством архитектора договариваются о среднесрочных принципах построения информационных систем компании (называются архитектурными решениями в смысле decision), документируя их в формате ADR. В отличие от традиционной слоевой структуры Policies-Standards-Guidelines, документы ADR линкуются, образуя граф решений. Нет необходимости документировать все решения по которым есть очевидный консенсус. Нет необходимости идти всегда от общего в частному как в слоях. С ADR меньше графоманства и больше конкретики для стейкхолдеров, с картинками и business value.
Рефакторинг приводит к ускорению разработки. И наоборот. Менеджмент должен это понимать. Думаю, что без глубокого погружения в процесс понимание невозможно. Всевозможные таблички неубедительны. Лечить управленцев у меня таблетки нет.
"Техдолг - это неизбежность из-за того, что" - не определение, а глупое утверждение. А значит объект для обсуждения не определен. Тех.долг - это чьи обязательства перед кем? В чем они выражены?
Тех.долг - это мнимые обязательства, это тот перечень недостатков с которым все готовы согласиться - временное решение, которое навсегда. Это такое уродство, которое отличает ваш продукт от вашего же представления об идеале и с которым все готовы смириться. Это способ невыполнения основных обязательств по разработке.
Не "выплачивается" он потому, что нет той стороны, которая сможет воспользоваться паяльником при наступлении срока выплаты, нет той стороны, к которой этот паяльник можно применить и нет самого паяльника.
Нужны коллекторы техничесого долга! Они будут назанивать менеджерам в 3 часа ночи и убеждать решить проблему с техничсеским долгом, обрезать провода в подъезде и писать на двери "техно-должник".
Техдолг — это способ невыполнения основных обязательств по разработке
Интересный взгляд на эту проблему, спасибо! Есть о чем задуматься
Это просто как и определение качества в ИТ. Баг есть нарушение спецификации. Техдолг есть нарушение принципов построения информационных систем компании. Если спецификаций нет то и багов нет, кругом фичи. Если принципов нет, то и техдолгов нет, кругом лигаси.
Давайте договоримся о тех.долге