2015-12-10: Технический долг - как работать с костылями

Материал из MaksWiki
Перейти к: навигация, поиск
Еще про архитектуру

Как говорил на одном из докладов Максим Дорофеев: "ИТ - единственная область, где с костылями быстрее, чем без них". А кроме костылей есть еще много других способов сделать быстрее. Например, опустить документацию, не делать тесты, не реализовывать побочные ветви процесса, которые сейчас все равно не понадобятся. В результате вполне работающий софт может появиться гораздо быстрее, особенно у опытного разработчика. Проблемы вскрываются потом, когда этот код надо сопровождать, дорабатывать, рефакторить. Вот тут-то выясняется, что никто не знает, как этот код работает и как он должен работать, является ли какое-либо поведение фичей или багом. Даже сам автор. Даже если он доступен, через полгода-год работы на другом проекте подробности вытесняются из памяти.

Для работы с этим в отрасли придумано такая конструкция, как технический долг. И когда встрече по Agile для госпроектов в обсуждении в группах зашла речь об этих проблемах я бегло рассказал об этой практике. На уровне беглого рассказа это приняли, но потом некоторые участники у меня просили литературу, где бы это было описано подробнее. В литературе я не силен, поэтому переадресовал вопрос Алексею Пименову, но оказалось, что он тоже не знает хороших книг и смог вспомнить только доклад Антона Бевзюка на AgileDays-14 Эй, программистик, за тобой должок!

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

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

Суть работы с техническим долгом состоит в следующем.

  1. Вы заводите специальный реестр технического долга.
  2. Запускается практика фиксации долга
    1. Каждый раз, когда разработчик или менеджер принимает решение о реализации с отступлением от явных или неявных критериев качества, в этом реестре появляется отдельная запись, фиксирующая суть этого отступления. Запись должна содержать ожидаемый эффект, для достижения которого мы пошли на такое решение. Типы отступлений могут быть различны,основные я перечислил:
      1. Костыли,то есть реализация с нарушением каких-то принципов архитектуры или хорошего дизайна кода, например, нарушением изоляции уровней
      2. Исключение или уменьшение поддерживающих процессов - тестовых сценариев или автотестов, внешней и технической документации, codereview, оформления патчей и так далее
      3. Исключение или уменьшение функционала, например, исключение из реализации побочных веток алгоритма.
    2. Для каждой такой записи формулируется риск, то есть потенциальный ущерб, который может быть нанесен. Риски должны быть в терминах, описывающих потенциальный ущерб от таких действий. Хорошая формулировка риска может требовать большей квалификации, чем есть у разработчика, который фиксирует долг, поэтому это - отдельное действие. Примеры.
      • Поскольку этот код быстро писал очень квалифицированный разработчик без покрытия тестами и документирования, то в случае каких-либо изменений, даже незначительных, будет необходимо привлечение не менее квалифицированного разработчика, который не менее 3 дней будет разбираться в коде. Это касается даже автора кода, если внесение изменений потребуется более. чем через 3 месяца.
      • Поскольку проектные решения не зафиксированы, а велись в переписке, то в случае необходимости доработок этого функционала будет необходимо привлечение опытного аналитика, который не менее 1 недели будет разбираться с пользователями системы, выясняя особенности работы.
      • Поскольку тестирование велось опытным тестировщиком совместно с пользователями. и контекст находится исключительно у тестировщика в голове, регрессионное тестирование этого функционала сможет проводить только этот человек, а в случае его недоступности необходимо будет откладывать выпуск версии или выпускать без тестирования. Передача контекста другому тестировщику возможна, но потребует 3-5 дней совместной работы.
    3. Оценивается трудоемкость (она же стоимость) снятия риска. В тех же терминах, в которых оценивается другая разработка на проекте.
    4. Об увеличении долга сообщается заказчикам проекта. Сразу, а не потом. Состав информации: достигнутый эффект для этого релиза, потенциальный риск (ущерб) для проекта, трудоемкость устранения риска.
  3. В работу по планированию версий добавляется работа с реестром долга
    1. Зафиксированный долг представляет собой исходный материал.
    2. Долг перекомпоновывать примерно в том же формате, в котором отдельные желания пользователей компонуются в фичи. Потому что долг имеет обыкновение накапливаться в определенных зонах проекта, а не распределяться равномерно. И задачи устранения тоже целесообразно делать по областям, а не по отдельным записям о долге.
    3. Решение о включении в итерацию работ по устранению определенного долга принимается из следующих соображений
      1. В рамках работ предполагается изменение того функционала, который уже затронут долгом. Обычно реализация с устранением долга дольше, чем реализация без его устранения, но не на полную стоимость устранения, а меньше. То есть есть возможность экономии для проекта в целом. Хотя в тяжелых случаях реализация с рефакторингом может быть даже выгоднее, чем реализация без него.
      2. Для определенной области размер потенциального ущерба превышает допустимый для проекта. Например, возникает критическая зависимость выпуска версии от определенного человека, который может и заболеть. Или для обработки запроса на доработку в определенной области может потребоваться недопустимое с точки зрения бизнеса время на подготовку к изменениям (разбирательство с кодом или функционалом), или потребоваться критический дефицитный ресурс.
  4. Работы устранению долга включаются в состав работ над релизом и реализуются так же, как обычные задачи.

Собственно, все.

Наиболее неочевидным моментом здесь является явная фиксация ущерба. Но именно она обеспечивает возможность сознательного управления долгом. Конечно, можно и без нее. Собственно, именно так обычно предлагается: вы фиксируете в реестре появившийся долг и трудоемкость исправления, ставите какие-то значения, которые долг не должен превышать, и при достижении порога начинаете исправлять долг. Только вот вы не сможете объяснить это менеджеру проекта, над которым довлеют сроки. Если проект устроен таким образом, что пики запросов на доработку сменяются относительно свободным временем, которое можно потратить на устранение долга - так можно. Но и тогда надо каким-то образов выбирать, какой долг устранять и по сути в процессе выбора мы соотносим риск от различных долгов. В этих тепличных условиях можно вообще оставить работу долгом внутри команды. Есть еще одна проблема. Риски иногда реализуются, то есть ущерб причиняется до того, как долг исправили. И если риски не были объявлены заранее, то это достаточно однозначно трактуется как некачественная работа команды. А вот если долг обсуждался в момент возникновения как плата за скорость поставки - то это совместный и осознанно принятый риск проекта. И, главное, он может быть объяснен.

[ Хронологический вид ]Комментарии

Мне кажется что на эту тему надо смотреть шире, а именно попытаться понять почему принимается решение о взятии долга. Результаты разбора (статья, доклады) и много интересных ссылок можно посмотреть тут http://www.maxshulga.ru/search/label/техдолг. В том числе есть мнение, что не надо тратить время на отслеживание долга: http://swreflections.blogspot.ru/2015/02/dont-waste-time-tracking-technical-debt.html

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

Ссылки на материалы с обсуждения на Facebook

  1. От Бориса Вольфсона - его доклад http://www.slideshare.net/blv/c-14782982 К сожалению, видео оказалось битым, только слайды.
  2. От Николая Рыжикова Материалы на InfoQ http://www.infoq.com/technicaldebt/ там много. Но я посмотрел несколько статей "подходящих" по названию - (Managing Technical Debt Using Total Cost of Ownership, Addressing Organizational Debt, How To Pay Down Technical Debt), к сожалению там в основном качественные рассуждения о том, что технический долг надо устранять, а то будут потери. Механизма расчета потерь нет. Если воспользоваться метафорой кредитной ставки в последней статье, там говорят "ну, вы же не будете пользоваться кредитной картой под 36%". На это есть два возражения менеджера (в метафоре): (а) а докажите, что там 36%, а не 12% и (б) многие люди используют кредиты типа "быстрые деньги" под 100 и более процентов.

Войдите, чтобы комментировать.