Comments 33
Не создавать техдолг
Нет техдолга — нет проблем! И в этом нам поможет такая замечательная практика как DOD, которую мы успешно применяем в нашем продукте. Теоретически, туда можно записать что угодно, но приведу то, чем мы пользуемся в данный момент:
Есть тесты (минимальное покрытие 80%)
Настройка метрик
Написана документация
Пока не закрыт DOD, задача не может считаться выполненной и будет перенесена в следующий спринт.
Это все прекрасно. Но это никак не решает проблему тех долга. Тех долг возникает, потому что у нас уже сделан продукт, покрыт тестами и т.п. и тут бизнес решает, что что-то нужно сделать по другому, что прямо не вписывается в архитектуру. И тогда у нас есть два варианта, сидеть 3 месяца перепиливать архитектуру проекта, или сбоку костылями прибить фичу которую хочет бизнес за 1 неделю. И конечно бизнес говорит, что 3 месяца его никак не устраивают, а 1 неделю он так и быть потрепит. Да и разработчикам тоже нафиг не надо под каждую подобную фичу долго и мучительно перепилывать архитектуру.
А потом повляется новое требование, и костылем обвешивается уже старый костыль. Какое у вас при этом количество тестов, пусть хоть 100%, совершенно не важно. Просто у вас будет хорошее покрытие закостыленного кода. Но там еще сложнее, т.к. по каждый такой новый костыль вам нужно удваивать количество тестов, а то и удисятерять. Конечно никто столько тестов писать не будет. Фактически простое тестовое покрытие не отражает всю сложность реальных кейсов которые могт проявиться в продукте.
А потом в какой-то момент люди уже не могут пилить новые сложные фичи, потому что у них сломается костыль, на который завязано еще 10 костылей. В результате чинить это никто не решается, т.к. это долго и дорого и потенциально сломает важные бизнес процессы - например 500 отчетов в бухгалтерию или еще что-то.
Тех долг возникает, потому что у нас уже сделан продукт, покрыт тестами
и т.п. и тут бизнес решает, что что-то нужно сделать по другому, что
прямо не вписывается в архитектуру.
Но ведь это только один из видов техдолга. Данная история по классификации из статьи может быть отнесена к рефакторингу.
А потом в какой-то момент люди уже не могут пилить новые сложные фичи,
потому что у них сломается костыль, на который завязано еще 10 костылей.
Именно поэтому я говорю, что бизнесу необходимо доносить, почему необходимо делать ту или иную задачу, даже если изначально кажется, что на бизнес какой-то там рефакторинг совершенно не влияет. Здесь очевидно, что чем дольше мы не рефакторим, тем больше становится наше время поставки (в крайнем случае упираемся в бесконечность - невозможность поставки новых фич без рефакторинга)
сломается костыль, на который завязано еще 10 костылей
При ближайшем рассмотрении, вырванный костыль оказался позвоночником (баян с просторов)
Как там живется среди единорогов и розовых пони? :D
Техдолг появляется вне зависимости покрыто-ли у вас все тестом, написано-ли максимально хорошо, соблюдая все лучшие принципы или нет.
Причины:
Бизнес и его быстро меняющиеся требования, которые в принципе невозможно учесть, при этом ему нужно как можно быстрее их внедрить, иначе смысл их поропадет, а прибыль будет упущена
Развитие ПО - языки, окружение и инфраструктура сами постоянно меняются и совершенствуются. Как вы бы смогли, например, дцать лет подготовиться к контейнеризации?
Поэтому техдолг есть и будет всегда, но его нужно не бояться, а уметь с ним работать.
уметь с ним работать
А что это означает в вашем понимании?
Никто не говорит, что техдолг не появляется сам собой. Из моих типов сюда относятся и рефакторинг, и обновить версию чего-то, и переезд на новую технологию.
Пункт про "не создавать техдолг" был про сознательное создание техдолга. Например: тесты написать не успели, напишем когда-нибудь потом. Но да, это не отменяет "естественного" техдолга.
Поэтому техдолг есть и будет всегда, но его нужно не бояться, а уметь с ним работать.
Я пытался донести, что с техдолгом надо работать как и с любой другой задачей, у которой есть определённая бизнес-ценность. Возможно где-то недосказал или возникло недопонимание.
Сознательное создание техдолга это нормально. Как раз ненормально его несознательное создание.
Сознательно сделать какую-то фичу как быстрее, а не как правильнее. Это осознанное создание техдолга. Бизнес хочет фичу, но не уверен что она полетит и проживает хотя бы год. Если фича полетела и пользователи пошли у нас есть техдолг и довольный бизнес. С этим можно работать.
А вот неосознанно делать криво и получать техдолг это печально. Тут есть явная проблема с командой разработки которая не понимает что такое хорошо. Стоит не над кодом и техдолгом работать, а людей нанимать. Желательно дорогих людей.
Вы просто перестарались с кликбейтом для заголовка, поэтому вашу статью воспринимают с трудом, в основном выискивая возможность поспорить.
Заголовок: техдолга не существует.
Статья: было выделено 9 типов техдолга.
Немного поясню. Я попытался разобраться в том, что такое техдолг, но в сообществе много разных мнений. Поэтому я решил исходить из своей практики и посмотреть, что же люди относят к техдолгу по тем или иным соображениям.
Заголовок подразумевает, что не нужно выделять техдолг как отдельный класс задач, а стоит доносить их ценность до бизнеса и делать в соответствии с приоритетами.
- Ты видишь техдолг?
- Нет.
- И я нет, а он есть!
Идея хорошая, особенно про «не плодите техдолг», но есть несколько вариантов его возникновения, когда разработчик может хоть сеппуку себе сделать, но техдолг будет:
Разработчик пришёл на проект, а там чёрт ногу сломит. Уже. Просто как факт.
Можно сделать быстро, но с образованием «долга», который надо будет потом порешать, а можно долго и правильно. Разница между первым и вторым - клиент на несколько годовых зарплат команды.
Это только из очевидного. При этом в общем беклоге без явных лимитов на типы задач легко можно скатиться в «у кого убедительность больше, тот и определяет, какие задачи берут». Подсказка: у продактов дар убеждения в среднем прокачан больше, чем у технарей. Про объяснения с бизнесом - тоже идея хорошая, но «вот эта фича принесёт нам клиента на 1.5 миллиона, а сколько принесёт решение вот этой задачи техдолга»?
В общем, с бизнесом разговаривать надо, вопросов нет, и варианты решения проблем могут быть разными, в зависимости от конкретных случаев, но варианты решения, предлагаемые в статье, в целом кажутся даже более утопичными, чем отвергаемые.
Считать ли техдолгом отсутствие кэша, когда два клиента в приложении ходят с один и тем же запросом в какой-то второй сервис? SLA по производительности нет
Абстрактно: питон, панда 1.5.
Можно обновиться до 2.0, но там поменялись вызовы некоторых функций, которые активно дёргаются.
Можно не обновляться, но универсальные пакеты нейросеток хотят именно панду 2.х - тогда пилим всё самостоятельно.
И тут и там - засада.
Не вижу засады. Я бы так сделал:
Составить список отличающихся функций
Сделать обёртки для изменившихся функций, чтобы они соответствовали новому API, а под капотом дёргали старый.
Плавно перейти на использование обёрток вместо старого API
Когда весь код использует обёртки, провести обновление. Т.е., поднять версию либы, а в обёртках заменить вызовы старого API на вызовы нового 1 в 1.
Когда оттестировали новую версию и убедились, что всё работает нормально, избавляемся от обёрток и используем новый API напрямую.
уязвимости, эксплуатация которых может привести к простою вашего продукта
Эм... уязвимости могут привести к взлому и последующим финансовым и репутационным потерям. Отказ в обслуживании - самая незначительная часть возможного влияния незакрытых уязвимостей на бизнес.
Как PM могу сказать что техдолг отлично решается когда он оценён и у него прописан value для бизнеса.
В этом случае можно достаточно безболезненно включать его в продуктовые эпики и решать по мере работы над фичами.
Value зачастую это velocity increase.
Вот здесь вполне годная статья о том как объяснить бизнесу зачем его решать:
https://www.scrum.org/resources/blog/technical-debt-product-owners
Как-то вот не упомянута пара моментов.
У бизнеса тоже есть свой долг перед клиентами: это то, что ждут клиенты и без чего просто уйдут к конкурентам. Ну или этот долг сильно (заметно) влияет на выручку и скажется на итоги квартала или года.
Любой тех.долг имеет свою цену последствий для бизнеса - и плох тот менеджер (product, CTO, CIO) кто не может выразить это либо в упущенной выручке либо в снижении лояльности клиентов либо в росте рисков ('а оно завтра как нае...ся!'). В целом статья проходит рядом с этим моментом, но как-то невнятно.
Я извиняюсь, а как вы переведёте в деньги техдолг "Перейти на актуальную технологию"? Не как-то пальцем в небо, а data driven, так сказать. Это сравнительно легко сделать, когда закрытие техдолга решает какие-то конкретные оцененные задачи. Чем абстрактнее техдолг, тем сложнее выразить его значимость в денежках.
А ведь после закрытия техдолга могут ещё и попросить сверить эффект с предварительной оценкой. И как быть тогда?
Да вообщем-то не вижу проблем: если работодатель понимает значимость ИТ и есть своя разработка, то ответ прост - свои разработчики разбегутся (оставшимся придётся платить выше рынка), а новых набрать будет крайне сложно. Если в двух словах - увеличивается стоимость найма и онбординга.
А эффект сверить по закрытию рисков - это только эксперимент поставить. Обычно такое проверяется путем сверки с некой экспертизой на рынке: выставки, вендоры, системные интеграторы - у нормальных собственников бизнеса не боящихся собственной разработки софта всегда есть кого переспросить и провериться.
Так это не отвечает на вопрос "Сколько денег?". Сколько разрабов убежит? Сколько согласится ехать дальше на дохлой лошади за повышение зарплаты? А сколько человеко-часов (и считай денег) мы сэкономим в короткой перспективе за счёт того, что НЕ будем что-то переписывать?
Тут довольно много переменных. И оценить их "точно, в граммах" сложно. Можно использовать примерный и сравнительные оценки. Но сумма многих допущений даёт не точную оценку, а одно огромное допущение с ошеломляющей разницей значений.
Я бы предложил техдолг оценить не только деньгами, но и нематериально. Как корпоративную культуру, что ли.
Точная оценка и не нужна - оценить порядок сумм и качественно возможную ситуацию уже хорошо.
"оценить не только деньгами, но и нематериально" - с точки зрения коммерческой организации, цель которой заработать прибыль всё необходимо оценивать деньгами. Мы же не мессии какие-то, которые несут свет в тёмные массы - это уже иной вид деятельности.
Как мне кажется, сравнительно стабильной характеристикой техдолга является обмен отложенных проблем на быструю выгоду. С т.з. бизнеса, т.е. денег, нужно понимать, что мы быстрее получим деньги сейчас, но потом нужно будет часть этих денег потратить на закрытие техдолга. И тут мы видим, в каком случае техдолг имеет право на жизнь: когда бизнес сейчас заработает заметно больше денег, чем мы потом потратим на закрытие техдолга.
Выполнение этого условия работает по-разному в разных компаниях. Скромная контора в начале своего пути может нести затраты на разработку, сопоставимые с выручкой. Компания-гигант может иметь огромную выручку, но исправление легаси может стать для неё не просто сложной, а нерешаемой разумными средствами задачей. Но может быть и более общий и кмк частый случай, когда всё действительно складывается удачно: мы сейчас выкатим вот это вот чудо, а потом наведём порядки.
Я выступаю за то, чтобы техдолг лежал в одном бэклоге с бизнес-задачами. Грамотно оценивался, приоритезировался и регулярно брался в работу. Техдолгом нужно управлять и эта ответственность должна лежать на плечах архитектора/техлида и владельца продукта.
В общем случае техдолг -- задачи, которые не приносят непосредственный value бизнесу, но от решения которых зависит скорость выкатывания новых фич. Способом борьбы может быть также мелкий рефакторинг непосредственно при решении основной бизнес задачи. В некоторых случаях техдолг превосходит по объему полную реимплементацию проекта. Однако основной проблемой здесь будет объяснить бизнесу необходимость данного действия. Обычно такое происходит только после полной смены команды.
Напомнили автора Бёрд Киви из журнала Компьютерра... Почитать бы.
Техдолга не существует