->
Когда я работал в Symantec, я заметил, что для определения *уровня* качества, достигнутого (предположительно) к дате поставки, используется множество показателей. Но не было собрано никаких показателей, ни в процессе, ни ретроспективно, чтобы измерить *стоимость* достижения этого качества.
Другими словами, насколько эффективно это качество было достигнуто за время существования проекта. Ваш продукт мог поставляться с высоким качеством, но требовалось ли для его достижения столько же времени и усилий? Это вопрос эффективности, а не качества как таковой, но они очень тесно связаны.
Они пересекаются, потому что одной из основных причин, по которой проекты программного обеспечения так часто значительно отстают от установленного графика, и это часто возникает как неожиданный «подводный камень» на заключительном этапе проекта, является низкое качество кода. Качество не только исходного кода, но и всего проекта.
Другая причина, которая на самом деле является просто неизбежным следствием низкого качества кода, — это дефекты, требующие многократных циклов исправления, охватывающих несколько прогонов тестов или спринтов, прежде чем дефект будет действительно устранен. Если все.
Причины отказа
Эти бесконечные итерации исправления, тестирования и повторного сбоя добавляют бесчисленное количество человеко-недель почти к каждому программному проекту. Тем не менее, что интересно, эта модель отказа не фиксируется однозначно ни в одном другом проекте или показателях качества, которые я видел. Потому что, как отмечалось выше, все эти метрики являются моментальными снимками во времени и поэтому не отражают это явление.
Мне пришло в голову, что есть простой способ зафиксировать эту модель отказа. Я придумал показатель, который назвал «Время достижения качества» или TTQ. Сама метрика довольно проста. Это работает следующим образом:
Для каждого прохождения теста (как бы оно ни было определено) отслеживайте не только количество пройденных или неудачных тестов, зато сколько тестов пройдено с первой попытки. И сколько требовалось двух, трех и более попыток, прежде чем те же тесты наконец-то прошли.
Эта метрика является очень хорошим индикатором исходного качества кода с одной стороны. Потому что чем выше качество кода, тем меньше раз вам придется проверять его, прежде чем он будет пройден. И наоборот. Эта метрика намного точнее, чем количество ошибок и тенденции.
Это также невероятно полезная метрика для отслеживания проектов. Например, если ваш первый тест прошел 70 % тестов, а 30 % не прошли, вы можете разумно предположить, что ваш проект все еще находится в соответствии с графиком. Но если, скажем, с первого запуска прошло только 20% ваших тестов, то, говоря техническим языком, Девушка, у вас проблемы! ”
Потому что это означает, что вы на самом деле не выполнили успешный первый проход. И это время необходимо повторно добавить к будущему пропуску в качестве долга качества.
Метрика TTQ чрезвычайно полезна в качестве того, что я люблю называть метрикой «tripwire». Если вы будете использовать его постоянно, он предоставит очень точные данные, которые позволят продакт-менеджеру определить, сходит ли проект с рельсов, задолго до того, как поезд действительно покинет рельсы.
Это означает, что упреждающие меры могут быть приняты гораздо раньше, чтобы вернуть ситуацию под контроль. Избегайте смущающих признаний, очень поздно в игре, что график проекта в клочья. Другими словами, используйте порог TTQ, чтобы определить, является ли проект все еще зеленым, желтым или вот-вот станет красным. Сделайте его неотъемлемой частью самого статуса проекта.
Потому что давайте смотреть правде в глаза, одной из постоянных патологий в усилиях по разработке программного обеспечения является упорное отрицание того, что что-то идет не так, и, по большому счету, когда это только становится очевидным, так оно и есть. Все боятся, что их заклеймят как «негативных», или что они просто слишком ленивы или не хотят что-то исправлять. Как не «командный игрок». Параллель с неблагополучными семьями неприятно очевидна.
Это отрицание и подавление того, что, как всем известно, происходит на самом деле, приводит к отказу признать, что проект далеко-далеко от графика до самой последней минуты. Когда это уже нельзя будет скрыть от высшего руководства. Нежелательный сюрприз, который это создает для них, только подрывает, иногда навсегда, их веру в собственные команды разработчиков. И кто может обвинить их?
Но если вы постоянно включаете TTQ в свои показатели и управление проектами…и действовать в соответствии с тем, что эта метрика говорит вам— этого можно избежать. Это обезличивает решение признать риски, связанные со сроками и качеством, которые накапливаются в проекте на его самых ранних этапах. Это становится очень резким и сухим, вопрос чисел. Не вопрос личного героизма, часто дорого обходившегося человеку.
Метрика TTQ
Метрика TTQ также очень полезна для ретро/после смерти проекта. Это позволит команде точно определить, какие участки кода были и оставались слабыми на протяжении всего проекта. И, соответственно, насколько эффективна команда в обеспечении качества как такового. Или как дорого.
Этого вопроса обычно избегают в ретро-проектах. Отчасти потому, что у команд нет концептуального словаря, чтобы сформулировать его, а отчасти потому, что указывать постоянно низкое качество кода со стороны инженеров часто является политически чувствительным.
TTQ обеспечит невероятную прозрачность и предсказуемость ваших проектов практически без затрат времени и усилий, поскольку это просто метаанализ показателей, которые вы уже собираете. Я использую его в своих проектах обеспечения качества в течение двух десятилетий, и он получил широкое признание среди менеджеров проектов, которых я этому обучал, по всем причинам, отмеченным выше.
Попробуйте, и вы убедитесь в этом сами. Это действительно изменит правила игры для вашей команды. Как всегда, удачи.
