9. Метрики

Организации ОБЯЗАНЫ установить базовые значения, проведя измерения в течение минимум 3 Инкрементов, прежде чем определять целевые показатели. Целевые показатели индивидуальны для организации, а не универсальны.

9.1 Обязательные (ОБЯЗАТЕЛЬНО)

Дефект после завершения — это баг, явно привязанный к завершённой задаче, которая его породила. Связь ОБЯЗАНА фиксироваться в трекере задач.

9.2 Рекомендуемые (РЕКОМЕНДУЕТСЯ; ОБЯЗАТЕЛЬНО в Командная+)

Manual Intervention Rate вычисляется из зафиксированных Обходов шлюза, а не из самооценки. Section 8.6(j) делает прямое изменение артефакта Обходом шлюза, который ОБЯЗАН фиксироваться, поэтому граница «ручного вмешательства» задана нормативно и больше не оставляется на определение каждой организации.

Отношение к частоте Обходов шлюза: 8.6(i) эту величину рекомендует, а не требует, поэтому организация может держать настоящую метрику и без неё, а способ её вычисления настоящий Стандарт не задаёт. Из определений следует вложенность СОБЫТИЙ, а не долей: изменение, зафиксированное по 8.6(j), есть Обход шлюза по 8.6(h), поэтому всякая такая запись принадлежит и той совокупности, из которой берётся частота Обходов, тогда как обратное неверно — в ту совокупность входят и допуски объявленного эффекта любого другого шлюза. Стоят ли в том же отношении сами доли, зависит от знаменателя, который организация даёт частоте Обходов и который 8.6(i) оставляет на неё: они сравнимы там, где этот знаменатель — задачи, единица настоящей метрики, и не сравнимы иначе. Величины на разных знаменателях отвечают на разные вопросы, и складывать их или выдавать одну за вложенную в другую НЕ ДОЛЖНО.

NOTE: Запись, которую считает настоящая метрика, делает та сторона, которая действовала. Поэтому метрика есть мера того, что зафиксировано, и организации НЕ ДОЛЖНЫ предъявлять её как меру того, что произошло.

Незафиксированное изменение в неё не попадает, и ничто в настоящем стандарте не обнаруживает такое изменение автоматически. Там, где требуется уверенность в самой величине, она даётся сличением изменений, зафиксированных в системе контроля версий, с записями шлюза о допуске (8.6(g)): всякое изменение в области Задачи должно попадать под допуск, зафиксированный шлюзом, а изменение, которое не попадает, есть либо незафиксированный допуск, либо необъявленный Обход. Авторство вопроса не решает — 8.6(j) делает маршрутом происхождение содержимого, а не то, какой процесс записал файл, поэтому сличение того, кто что закоммитил, слепо ровно к тому случаю, ради которого пункт написан. Это аудит, который проводит организация, а не свойство метрики.

Adversarial Detection Rate (ADR) показывает, сколько критических находок приходится на одну задачу, прошедшую состязательное ревью L3 (Section 10.15). Целевой показатель: организациям РЕКОМЕНДУЕТСЯ стремиться к ADR < 0.5 (менее одной CRITICAL-находки на две проверенные задачи). ADR, равный 0, может означать как отличное качество вывода AI, так и поверхностное ревью — организациям РЕКОМЕНДУЕТСЯ уметь различать эти два случая.

Для вычисления ADR «L3_reviewed_tasks» означает задачи, прошедшие Состязательное ревью L3. Задачи, не получившие ревью L3 (например, задачи низкого риска, где L3 было пропущено согласно Section 10.15), исключаются из знаменателя. Это обеспечивает, что ADR отражает эффективность ревью, а не охват ревью.

Калибровка целевого показателя Knowledge Capture Rate: по мере накопления базы знаний темп появления новых записей закономерно снижается. Организации с устоявшимися базами РЕКОМЕНДУЕТСЯ устанавливать целевые показатели KCR с учётом этого эффекта. Показатель 1.0 (одна запись на задачу) уместен для новых проектов. Для зрелых проектов (>500 задач) показатель 0.33 (одна запись на три задачи) лучше соответствует реальному темпу обнаружения новых знаний. Организации ОБЯЗАНЫ документировать обоснование своего целевого показателя KCR.

9.3 Сбор

Метрики 1–5, 8 и 9 ОБЯЗАНЫ автоматически формироваться из данных трекера задач и журнала сессий. Метрика 8 выводится из зафиксированных Обходов шлюза по 8.6(j) и отдельного акта отчётности не требует. Метрики 6–7 требуют интеграции с системой учёта затрат. Cost Predictability требует оценки Менеджера потока на Ретроспективе инкремента.

Метрика 10 (ADR) ОБЯЗАНА собираться из находок состязательного ревью, зафиксированных при ревью L3 (Section 10.15). Организации ОБЯЗАНЫ вести запись находок ревью по задачам, классифицированных по уровню серьёзности, для вычисления ADR.

При вычислении метрик ОБЯЗАНЫ учитываться все задачи — без отбрасывания данных за определённые периоды и без фильтрации исторических записей. Организации НЕ ДОЛЖНЫ исключать задачи из расчёта метрик на основании даты создания, статуса миграции или версии инструментария. Обоснование: фильтры по периодам усложняют систему и затрудняют поддержку, а также маскируют проблемы качества данных; сверх того они делают цифру непроверяемой, потому что совокупность, по которой она посчитана, перестаёт быть той совокупностью, которую держит трекер. Накопительная величина от ранних данных сама собой не избавляется: эти задачи сохраняют тот вес, который даёт им их доля в итоге, а доля убывает лишь по мере роста итога — но не оттого, что сменился инструментарий. Там же, где именно смена инструментария и делает ранние данные непредставительными, ожидание цифру не исправляет. Это довод назвать ограничение, а не отфильтровать его. Если ранние данные заведомо ненадёжны (например, ручные записи до автоматизации), это ОБЯЗАНО быть задокументировано как известное ограничение, а не отфильтровано.

Cost Predictability (метрика 6) требует фиксации запланированной стоимости до начала реализации. На практике оценка стоимости задач с участием AI ненадёжна: время выполнения недетерминировано, ценообразование моделей варьируется. В Командной конфигурации (Team) Cost Predictability ОБЯЗАН отслеживаться, но в первые 3 Инкремента базовые значения могут быть предварительными. В Корпоративной конфигурации (Enterprise) Cost Predictability ОБЯЗАН отслеживаться с установленными базовыми значениями. Cost per Task (метрика 7) является более практичной альтернативой для управления стоимостью на ранних этапах внедрения.

Работа с несколькими агентами и параллельными сессиями: когда несколько AI-агентов работают одновременно, метрики на уровне сессии (пропускная способность, длительность, стоимость) отражают результативность отдельного агента, а не совокупный выход команды. Организации с мультиагентными конфигурациями РЕКОМЕНДУЕТСЯ дополнительно отслеживать агрегированные метрики на уровне Инкремента. Токены и стоимость в мультиагентных сценариях РЕКОМЕНДУЕТСЯ учитывать по каждому агенту, а сводные итоги — быть доступны для отчётности на уровне Инкремента.