День 1497. #ProjectManagement
Хватит Говорить: «Технический Долг». Окончание
Начало
Чтобы решить эти проблемы, выберите что-то измеримое для оценки качества системы, например: нагрузка по обслуживанию. Сколько времени и усилий разработчики тратят на задачи, не связанные с добавлением или удалением функций? Если у нас 6 разработчиков, но половина работы приходится на обслуживание, то надо планировать выпуск функций, полагаясь только на 3 разработчиков. Мы также можем отслеживать это число и определять, насколько быстро оно растёт с течением времени. Чем быстрее растёт нагрузка по обслуживанию, тем больше разочарований мы можем ожидать. Нулевой рост означает, что мы всегда можем обслуживать систему с той же долей нашей команды инженеров.
Как бороться с ростом нагрузки по обслуживанию? С помощью хороших практик управления кодом: документирование систем, восстановление контекста из кода и проектирование будущих изменений. Мы редко вознаграждаем, признаём или учимся управлению кодом так, как мы делаем это в отношении навыков разработки.
Снижение нагрузки по обслуживанию делает код более удобным для сопровождения с течением времени. Это требует выделения отдельных задач обслуживания, отслеживания их происхождения и устранения этих проблем в источнике. Эти рутинные работы, подкреплённые эмпирическими данными, дают нам что-то конкретное для обсуждения на встречах о техническом долге.
Выполняем ли мы сейчас много рутинных обновлений библиотек или фреймворков? Может быть, нужно регулярно выделять время на них. Чем больше их накапливается, тем сложнее становится отлаживать взаимодействие между выпусками разных библиотек. И чем реже программисты их выполняют, тем меньше у них практики, что делает обновление более сложным и болезненным, когда оно становится обязательным.
Есть ли у нас заброшенные репозитории, и мы каждый раз выясняем, как внести в них изменения? Возможно, нужно приложить усилия для восстановления информации о том, как они работают. Когда кто-то из ключевых членов команды уходит, внезапно оказывается, что они знали много критической информации, которая нигде не была записана или систематизирована. Разработчикам необходимо заранее оценить и устранить ущерб, нанесённый общим знаниям команды, прежде чем перед дедлайном окажется, что нужно изменить незнакомые части кодовой базы.
Мы работаем с устаревшей унаследованной архитектурой, основанной на предположениях о предметной области, которые больше не соответствуют действительности? Может быть, нужно создать план перестройки архитектуры.
Как определять такие задачи и расставлять их приоритеты – отдельная сложная тема, но даже сосредоточение внимания на нагрузке по обслуживанию в единицах конкретных работ, а не на единой горе «технического долга», позволит лучше спланировать решение этой проблемы.
Итого
Чем дольше мы откладываем работы по обслуживанию, тем менее гладкой и легкой будет разработка функций. Вместо того, чтобы заметать все эти задачи под ковёр под названием «технический долг», а затем время от времени прерывать разработку, чтобы разобраться с ним, мы можем отслеживать, какие конкретные элементы системы усложняют разработку функций, измерять их с точки зрения требуемого объёма усилий разработчиков, а затем согласовывать их выполнение как отдельных задач. Мы больше не считаем их непрозрачными и с неопределённой стоимостью. Вместо этого мы представляем их как чётко очерченные инвестиции в нашу способность эффективно создавать функции. Это помогает всем чётко понимать, что такое технический долг, а также увеличивает вероятность того, что:
- инженерам будет назначаться определённая работа по техническому обслуживанию,
- инженеры смогут выделить время для выполнения этой работы,
- работы по техническому обслуживанию, выбранные по итогам обзора реальных причин замедления разработки функций, на самом деле улучшат опыт разработки функций в будущем.
Источник: https://stackoverflow.blog/2023/02/27/stop-saying-technical-debt/
Хватит Говорить: «Технический Долг». Окончание
Начало
Чтобы решить эти проблемы, выберите что-то измеримое для оценки качества системы, например: нагрузка по обслуживанию. Сколько времени и усилий разработчики тратят на задачи, не связанные с добавлением или удалением функций? Если у нас 6 разработчиков, но половина работы приходится на обслуживание, то надо планировать выпуск функций, полагаясь только на 3 разработчиков. Мы также можем отслеживать это число и определять, насколько быстро оно растёт с течением времени. Чем быстрее растёт нагрузка по обслуживанию, тем больше разочарований мы можем ожидать. Нулевой рост означает, что мы всегда можем обслуживать систему с той же долей нашей команды инженеров.
Как бороться с ростом нагрузки по обслуживанию? С помощью хороших практик управления кодом: документирование систем, восстановление контекста из кода и проектирование будущих изменений. Мы редко вознаграждаем, признаём или учимся управлению кодом так, как мы делаем это в отношении навыков разработки.
Снижение нагрузки по обслуживанию делает код более удобным для сопровождения с течением времени. Это требует выделения отдельных задач обслуживания, отслеживания их происхождения и устранения этих проблем в источнике. Эти рутинные работы, подкреплённые эмпирическими данными, дают нам что-то конкретное для обсуждения на встречах о техническом долге.
Выполняем ли мы сейчас много рутинных обновлений библиотек или фреймворков? Может быть, нужно регулярно выделять время на них. Чем больше их накапливается, тем сложнее становится отлаживать взаимодействие между выпусками разных библиотек. И чем реже программисты их выполняют, тем меньше у них практики, что делает обновление более сложным и болезненным, когда оно становится обязательным.
Есть ли у нас заброшенные репозитории, и мы каждый раз выясняем, как внести в них изменения? Возможно, нужно приложить усилия для восстановления информации о том, как они работают. Когда кто-то из ключевых членов команды уходит, внезапно оказывается, что они знали много критической информации, которая нигде не была записана или систематизирована. Разработчикам необходимо заранее оценить и устранить ущерб, нанесённый общим знаниям команды, прежде чем перед дедлайном окажется, что нужно изменить незнакомые части кодовой базы.
Мы работаем с устаревшей унаследованной архитектурой, основанной на предположениях о предметной области, которые больше не соответствуют действительности? Может быть, нужно создать план перестройки архитектуры.
Как определять такие задачи и расставлять их приоритеты – отдельная сложная тема, но даже сосредоточение внимания на нагрузке по обслуживанию в единицах конкретных работ, а не на единой горе «технического долга», позволит лучше спланировать решение этой проблемы.
Итого
Чем дольше мы откладываем работы по обслуживанию, тем менее гладкой и легкой будет разработка функций. Вместо того, чтобы заметать все эти задачи под ковёр под названием «технический долг», а затем время от времени прерывать разработку, чтобы разобраться с ним, мы можем отслеживать, какие конкретные элементы системы усложняют разработку функций, измерять их с точки зрения требуемого объёма усилий разработчиков, а затем согласовывать их выполнение как отдельных задач. Мы больше не считаем их непрозрачными и с неопределённой стоимостью. Вместо этого мы представляем их как чётко очерченные инвестиции в нашу способность эффективно создавать функции. Это помогает всем чётко понимать, что такое технический долг, а также увеличивает вероятность того, что:
- инженерам будет назначаться определённая работа по техническому обслуживанию,
- инженеры смогут выделить время для выполнения этой работы,
- работы по техническому обслуживанию, выбранные по итогам обзора реальных причин замедления разработки функций, на самом деле улучшат опыт разработки функций в будущем.
Источник: https://stackoverflow.blog/2023/02/27/stop-saying-technical-debt/
👍6