Портал №1 по управлению цифровыми
и информационными технологиями

Разработчики в одиночку не могут сократить технический долг

Технический долг накапливается с течением времени, и в какой-то момент может сделать приложение непригодным для поддержки. Это как бомба замедленного действия, которая, если ее не обезвредить вовремя, может привести к серьезным последствиям для клиентов и финансовому ущербу для организации.

Термин «технический» в названии  зачастую вызывает ощущение, что сокращение технического долга является исключительной ответственностью разработчиков. Конечно, команда разработки играет ключевую роль в рефакторинге кода и сокращении технического долга. Но рефакторинг не всегда ограничивается только кодом. Многие другие группы сотрудников должны играть свои связанные роли, чтобы обеспечить рефакторинг и сокращение технического долга.

Давайте попробуем поговорить о том, какие группы или отдельные роли в организации должны объединяться для сокращения технического долга.

IT-руководство

В истинном духе одного из принципов Agile - «Постоянное внимание к техническому совершенству» — IT-руководству необходимо осознавать, что «идеальное» или «отличное» решение сегодня может не соответствовать будущим требованиям с точки зрения скорости или надежности и может не соответствовать ожиданиям клиентов. Подобные компромиссные технические решения должны постоянно пересматриваться и улучшаться. 

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

Владелец продукта

Владелец продукта (Product Owner) играет ключевую роль в организации работы команды разработчиков. Он несет ответственность за сбор бизнес-требований и определение их приоритетов. При этом PO руководствуется в расстановке приоритетов соображениями ценности для бизнеса. Однако владельцу продукта следует не забывать, что приложение будет продолжать работать так, как ожидается, и предоставлять бизнес-ценность только в том случае, если оно построено на прочной основе. 

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

Заинтересованные стороны бизнеса

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

Архитекторы

При рефакторинге кода разработчик может проявить улучшения в архитектуре приложения. Архитекторы должны признавать необходимость рефакторинга архитектуры. Они должны быть готовы вкладывать усилия в анализ влияния изменений и соответствующим образом реорганизовывать архитектуру. 

При этом им следует убедиться, что изменения соответствуют общей архитектуре на уровне предприятия. В то же время, если они видят возможности для улучшения общей архитектуры, необходимо транслировать это сообществу архитекторов предприятия. Если это требует значительных изменений, то PO и стейкхолдеры со стороны бизнеса должны быть осведомлены о последствиях таких изменений.

Тестировщики

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

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

Команда эксплуатации

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

Если организация станет зрелой в практиках DevOps, это сотрудничество будет укореняться в их подходе к работе. Однако если команды находятся на ранних стадиях принятия DevOps, руководство департаментов Dev и Ops должно облегчить совместную работу, чтобы извлечь выгоду из усилий по рефакторингу.

Технический долг — это широкий термин, охватывающий все этапы цикла разработки IT-решения. Это понятие не ограничено только кодом.  IT и бизнес должны иметь комплексное end-to-end видение проблемы и периодически проводить рефакторинг приложения, чтобы уменьшить технический долг.

Оригинал статьи Developers Alone Cannot Reduce Technical Debt in a Silo, автор Равишанкар Н. (Ravishankar N.)

«DevOps: современный подход к организации работы ИТ»
Учебный курс про менеджмент, а не про технические практики

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

  • Рубрики

  •  
  • Авторы

  •  
  • Самое свежее

    • 3 стратегии, которые помогут вашей команде принять метрику потока
      Вам необходимо эффективно управлять рабочими процессами, чтобы иметь возможность постоянно предоставлять ценность своим клиентам. Именно здесь в игру вступают метрики потока. Метрики потока являются основной движущей силой оптимизации процессов.
    • Новая модель предоставления ИТ-услуг: почему вам нужно ориентироваться на продукт
      Традиционно ИТ-организации делят все предоставляемые ими услуги на три уровня: инфраструктура (инфраструктура как услуга), платформа (платформа как услуга) и приложения
    • Как DevOps-командам следует использовать метрики DORA
      С момента выхода в 2018 году книги «Accelerate: Наука о бережливом программном обеспечении и DevOps», показатели DORA, которые она представила, стали популярным
    • Лучше делать хоть что-то, чем не делать ничего
      На конференциях по всяким Agile и DevOps мы часто слышим слово «unlearn» — забудьте то, что вы знали ранее! Измените свои представления о мире! Всё устроено
    • VI форум «Управление данными — 2021»: наведите порядок в данных!
      23 сентября 2021 года издательство «Открытые системы» в шестой раз проведет в Москве масштабный форум «Управление данными — 2021», объединяющий всех, кто определяет стратегию работы с данными, воплощает ее в жизнь и управляет предприятием на основе объективных достоверных данных. Участники форума обсудят не только инновационные стратегии и бизнес-модели работы с корпоративными данными, но и конкретные архитектурные и технологические решения.
    • Простые уловки, как ускорить процесс разработки программного обеспечения
      С некоторыми вещами люди из бизнеса вынуждены соглашаться, и одна из них заключается в том, что никто не хочет сердить свою команду разработчиков. Часто они являются краеугольным
    • Почему каждая инициатива DevOps должна начинаться с оценки возможностей
      Внедрение практики DevOps идет полным ходом. Организации сосредоточены на том, как внедрить возможности DevOps в командах и как масштабировать DevOps в масштабах предприятия. Но важным аспектом любого пути масштабной трансформации является оценка возможностей команды или организации на этом пути.
    • Что такое процесс и что такое практика в ITIL®4
      Продолжаем публиковать короткие видеоролики, посвященные актуальным вопросам управления ИТ. Сегодня поговорим о том, что такое процесс и что такое практика в ITIL4. Это не переименование процессов в практики, это два отдельных понятия. Рассказывает Игорь Фадеев, ITIL 4 Managing Professional и ITIL 4 Strategic Leader, аккредитованный тренер по ITIL4.
    • Аудит. Что может быть скучнее?!
      На прошедшей неделе участвовал в аудите (в качестве объекта аудита). Большинство людей, проходивших аудит, подозреваю, разделяет это ощущение: «Бюрократия, формальности и т.п.»
    • Как технический долг вредит вашей команде программистов — и вашей безопасности приложений
      Техническая долг может серьезно повлиять на здоровье организации - и на психическое здоровье ваших разработчиков. Более половины из 200+ членов инженерных команд, опрошенных в рамках отчета Stepsize "Состояние технического долга в 2021 году", считают, что технический долг негативно влияет на моральное состояние их команд.
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT