Как оценить технический долг

technical debtОчень многие разработчики уже используют термин технический долг (Technical debt), который придумал однажды Ward Cunningham. Некоторые даже считают размер технического долга  посредством автоматизированного анализа исходников. Однако, несмотря на красоту метафоры, как всегда есть два вопроса, не имеющие внятного ответа: относительно чего считать технический долг и каковы условия его обслуживания.

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

Полнота функциональных и нефункциональных требований. Прям в соответствии с IEEE 830-1998, наивно утверждающем, что требования бывают полные, непротиворечивые, однозначно трактуемые, верифицируемые, модифицируемые, корректные, упорядоченные по важности и т.д. Требования, действительно, являются основным источником проблем. Администраторы, эксплуатирующие ПО, думают, что причина багов в плохом тестировании. Тестировщики – в кривизне рук разработчиков. Разработчики считают источником всех бед своих предшественников, оставивших им в наследство плохой код или, если разработка ведется с нуля, авторов средств разработки и библиотек. Но мы с вами знаем, что все началось чуть раньше, незадолго до большого взрыва. И началось с требований. Ну а если говорить серьезно, оценить качество требований в конкретном контексте довольно просто. Например, для корпоративного приложения идентификацию действующих лиц следует считать достаточно хорошей, если все они привязаны к списку функциональных ролей сотрудников. У вас нет такого списка? А на основании чего вы группы в AD заводите? Точно так же полнота описания фунционала определяется глубиной альтернативных сценариев в use-case-ах, а нефункциональные требования – своим наличием и привязкой к шагам этих сценариев. В общем, дело техники. В организации, где я недавно работал, требования согласовывали человек восемьдесят(это самый короткий список тех людей, которых нельзя было не включать в согласование). Уверен, что большинство их них не могут внятно объяснить,  в чем заключается смысл такого согласования. Чтоб архитектор не попадал в эту же категорию согласующих, он должен внятно рассказывать, что читает требования для оценки их неполноты и определения размера технического долга.

Второй костыль – интегрируемость в корпоративный ландшафт. В первую очередь речь идет о наличии локальных справочников и функций повторного ввода основных данных (клиентов, услуг, ресурсов, сотрудников и т.п.). Собираетесь завести локальный справочник сотрудников или офисов вашей компании – получайте технический долг равный стоимости синхронизации этих справочников с другими системами. Не забудьте, что интеграция данных процесс сложный и дорогой, требующий их очистки и проверки целостности. А ручная интеграция требует не только сотрудников, которые будут копипастить, но и механизмов контроля и исправления ошибок. В общем, можно сразу закладываться на метод двух пар глаз. Второй технический долг, возникающий при интеграции это наличие, вернее отсутствие, программных интерфейсов. Считать очень просто. Нет у приложения готового API, значит в течении 2-х лет вы вынуждены будете написать еще одно такое же приложение, а 3-ий год потратить на их интеграцию.

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

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

На самом деле, «выплата процентов по техническому долгу» — это статья наших расходов, по которой мы можем учитывать все неожиданные превышения сроков и стоимости в ходе развития и эксплуатации решения. Её надо не предсказывать, а регулярно считать.

Еще несколько интересных мыслей на тему в Talks | Philippe Kruchten

Реклама

2 Comments

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

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s