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

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

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

• Менеджмент (техруки, менеджеры, консультанты и т.д.);
• Проектная инфраструктура (девопсы, архитекторы);
• Кодовая инфраструктура (архитекторы);
• Кодовая база (программисты, архитекторы);

Причины:

• неправильная оценка зрелости проекта;
• микроменеджмент;
• усложненная архитектура;
• следование "модным" тенденциям;
• пренебрежение технологией разработки;
• слабая команда;
• отсутствие опыта.

• Стратегическое планирование (цели);
• Тактическое планирование (задачи);
• Приоритеты;
• Оценка трудоемкости и управление ресурсами;
• Оптимизация задач (не пытаться охватить необъятное);
• Контроль сроков;
• Эволюция (растет проект, улучшаются методы управления, развивается система оценок эффективности);
• Технология разработки;
• Обучение (повышение квалификации сотрудников);
• Командные практики (парное программирование, ревью кода и т.д.);
• Справедливое распределение обязанностей и принцип "равенства квалификации";
• Ротация задач внутри группы (отсутствие узкой специализации, там где это возможно. Могут быть исключения.).

• Безопасность;
• Резервное копирование;
• Мониторинг;
• Логирование (аудит действий);
• CI/CD;
• Отказоустойчивость;
• Технология разработки;
• Версионная чистота;
• Полнота инфраструктуры для решаемых задач (dev/stage/prod).

• Версионная чистота;
• Реализован принцип наименьшей зависимости;
• Архитектурная изоляция (например, собственные обертки или архитектурные границы);
• Патентная, лицензионная чистота;
• Стратегия "замены";
• Исключены "золотые/божественные" сотрудники.Чеклист "Кодовой базы"
• документирование;
• проектирование;
• версионирование;
• статический анализ (ручной/автоматизированный);
• тестирование;
• моделирование;
• исследование.