Есть ли связь между техническим долгом и скоростью?

TL;DR

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

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

Основная проблема с техническим долгом заключается в том, что он невидим. Закон прозрачности CodeGnome℠ гласит: «Никакой невидимой работы никогда!» Видимый долг не уменьшит вашу скорость, но может снизить скорость, с которой могут быть реализованы новые функции. Невидимая работа будет тормозить скорость, что является ранним предупреждением о том, что может существовать неизвестная или неожиданная техническая задолженность, которая должна быть выявлена ​​и решена всей Скрам-командой.

Определение технического долга

В настоящее время Википедия определяет технический долг следующим образом (выделено мной жирным шрифтом):

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

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

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

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

Технический долг и скорость

Скорость — это гибкая метрика, которая в первую очередь измеряет способность к работе , которая может быть выполнена за одну итерацию. Основная идея состоит в том, что исторические измерения могут быть сглажены (часто путем выражения скорости в виде диапазона или скользящего среднего) для получения достаточно точных (например, «достаточно хороших») краткосрочных прогнозов.

Обычно существует два класса технического долга: видимый и невидимый. Два класса сравниваются ниже.

Видимый и известный технический долг

Velocity не измеряет напрямую технический долг. Если вы явно отслеживаете свой технический долг и делаете его видимым как работу в Бэклоге Продукта (как вы и должны), то первичные затраты на технический долг часто будут проявляться как:

1. Увеличение возможностей команды для «выплаты долга» в виде рутинной работы и явного рефакторинга по мере увеличения долга, как правило, за счет новых функций.
2. Общее увеличение размера оценок команды с учетом неявного рефакторинга и дополнительного резерва, необходимого для управления эффектами домино долга.
3. Явное (хотя и не обязательно реальное) снижение ценности для заинтересованных сторон с каждой следующей итерацией, поскольку все больше и больше возможностей команды тратится на «выплаты долга», необходимые для разработки функций или предотвращения краха проекта под тяжестью технического долга.

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

Невидимый или неизвестный технический долг

Стоимость невидимого долга — или, что еще хуже, неизвестного технического долга — часто оплачивается в виде неожиданного снижения производительности. Если сопротивление производительности становится достаточно большим и остается невидимым достаточно долго, это в конечном итоге приводит к:

1. Растущая неспособность точно прогнозировать мощность.
2. Возрастающее количество итераций, которые не достигают целей команды или заинтересованных сторон.
3. Потеря доверия заинтересованных сторон к команде.
4. Общая потеря доверия к системе управления проектами.

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

Общие советы

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

1. Используйте скорость для измерения усилий , а не ценности для заинтересованных сторон.
2. Используйте скорость для прогнозирования возможностей команды , а не потенциальную ценность.
3. Как можно скорее выявляйте технический долг во время каждой итерации, в том числе при планировании спринта, уточнении невыполненной работы и обзоре спринта.
4. Держите известный технический долг в поле зрения Команды Разработки, Владельца Продукта и заинтересованных лиц в любое время.
5. Берите технический долг только преднамеренно, с осознанного согласия всей Скрам-команды (и, в идеале, с заинтересованными сторонами). Вы все должны будете вернуть его вместе!
6. Отслеживайте всю известную работу (включая технический долг) как элементы в Бэклоге Продукта.
7. Просматривайте свой Бэклог Спринта в конце каждого Спринта, чтобы выявить новые источники технического долга.
8. Не делайте различий между рутинной работой, ошибками, функциями и т. д. в ваших необработанных измерениях скорости, поскольку все они требуют времени, усилий и ресурсов от команды.
9. Проанализируйте неожиданное увеличение времени, усилий и ресурсов, так как это может быть результатом невидимого технического долга.
10. Ищите невидимый технический долг всякий раз, когда не удается достичь цели спринта или когда скорость неожиданно падает.

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

Отслеживайте всю работу, которая потребляет ресурсы команды (включая то, что вы классифицируете как технический долг), как первоклассный элемент в вашем Бэклоге Продукта. Как и в случае с финансовым долгом, у вас гораздо меньше шансов «разориться», если вы внимательно следите за своими расходами и избегаете обременительных процентных платежей.

В зависимости от того, как вы хотите справиться с техническим долгом, зависит, повлияет ли он на вашу скорость. Насколько я вижу, у вас есть несколько вариантов:

1. Не выделяйте баллы за технический долг в отдельную «проблему».

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

2. Выделить баллы за технический долг в отдельной «проблеме»

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

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

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

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

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

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

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

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