Ваш трекер задач и платформа контроля версий содержат большую часть матрицы прослеживаемости требований, которую хочет видеть аудитор, но в форме, которую никто в вашей организации не может запросить.
Во вторник аудитор задает простой вопрос. Какое требование привело к созданию кода в релизе 4.2? Кто подтвердил, что он работает? Вместо того чтобы получить ответ из Jira и GitHub, кто-то тратит два дня на восстановление истории по объединенным (merged) pull request'ам и старым примечаниям к релизу. Это все равно будет лишь лучшим предположением, высказанным с полной уверенностью.
Вам нужна матрица прослеживаемости требований. Она связывает каждое требование с работой, которая его реализует, а затем прослеживает каждый доставленный артефакт до причины его существования. Ее цель — сделать вопрос аудитора скучным.
В большинстве инженерных организаций она делает обратное, потому что кто-то должен поддерживать ее в актуальном состоянии вручную. Эта ручная работа не масштабируется, и никого еще не повысили за ее обновление. Тем временем ваш процесс разработки уже создает связи, необходимые матрице, внутри систем, за которые вы уже платите, где никто не может их запросить.
Что должна была делать матрица
Изображение создано с помощью ИИ
Задача матрицы — связать причину изменений с задачей (issue) и pull request'ом, которые их внесли. Она также связывает эту работу с результатами тестирования и утверждением, которые ее проверяли. Она отвечает на два вопроса. Учитывая требование, что доказывает, что оно было выпущено? Учитывая diff, какая бизнес-причина его оправдывает?
Первый вопрос важен не только для аудита. Команда, которая может проследить требование до работы, стоящей за ним, быстрее разберется в незнакомом коде.
Но к матрице обычно относятся как к аудиторской документации. Когда это происходит, она никогда не получает бюджет. Она ведется в оставшееся время, а это время постоянно не находится.
Исследования показывают, что недостаточное финансирование прослеживаемости обходится дороже, чем экономия на ней. В одном исследовании участникам давали реальные задачи по сопровождению незнакомых проектов. Некоторые задачи включали ссылки прослеживаемости между требованиями и кодом. Участники, которые могли следовать по этим ссылкам, в среднем заканчивали на 24% быстрее и создавали на 50% более правильные решения.
Более быстрая работа высвобождает ресурсы, а ресурсы определяют, что ваша команда может взять на себя. Оказывается, прослеживаемость — это функция продуктивности, одетая в костюм соответствия требованиям.
Цепочка, которую оставляет ваш рабочий процесс
Отложите в сторону матрицу, которую нужно вести вручную, и проследите изменения в вашей организации. Каждая передача ответственности оставляет след, хочет этого кто-то или нет:
- Требования поступают из обязательств перед клиентами или нормативных актов.
- Задача в Jira или Azure DevOps называет требование.
- План реализации находится в описании задачи или связанном документе с дизайном.
- Коммиты в ветке ссылаются на задачу по номеру.
- CI запускает модульные и приемочные тесты для этих коммитов.
- Рецензент одобряет или отклоняет pull request, официально, с отметкой времени.
- Pull request объединяется и, при выполнении ключевого слова закрытия, закрывает задачу, которую он называл.
Требование к задаче, к плану, к коду, к тестам, к проверке, к слиянию.
То, какая часть этой цепочки хранится в ваших платформах, зависит от команды. Одна команда пишет fixes #4127 в каждом коммите. Другая ставит PROJ-4127 в заголовок pull request'а. Третья использует только имя ветки, например adam/auth-timeout-fix, потому что техлид уверен, что имя ветки говорит само за себя. Это не так.
Эти ссылки не объединяются, если ваши команды не используют один и тот же шаблон. GitHub, например, принимает несколько ключевых слов для закрытия. Выбор того, которое использует каждая команда, и принудительное его использование с помощью обязательной проверки статуса — это решение на текущий квартал. Это скучное решение, поэтому его постоянно не принимают.
Объем работы агентов разрушает матрицу, которую ведут вручную
Теперь добавьте в этот процесс агентов по написанию кода. Количество веток и pull request'ов растет, в то время как человеческая память о том, почему произошло каждое изменение, остается слабой. Матрицу, которую ведут вручную, перестают обновлять, потому что кто-то должен открыть ее и добавить ссылку. У этого «кого-то» есть релиз, который нужно выпустить, и матрица проигрывает этот спор каждый раз.
Изменения, созданные агентом, ставят перед вами три вопроса. Кто проверял работу? Где хранится план реализации агента? Какой автор Git или автор pull request'а идентифицирует агента и человека, который им руководил? Общая учетная запись бота не отвечает ни на один из этих вопросов, хотя в логе коммитов она выглядит аккуратно.
Честное возражение заключается в том, что эта цепочка доказывает хранение, а не правильность. Текст коммита вроде fixes #4127 доказывает только то, что кто-то набрал номер. Тесты и проверка все еще отвечают за вопрос правильности. GitLab, например, сбрасывает одобрения по умолчанию, поэтому push агента их обнуляет.
Проверка прослеживаемости: выберите один объединенный pull request. Работая только с Jira и GitHub, назовите требование, которому он служил. Затем назовите человека, который его одобрил. Если вам приходится спрашивать разработчика, значит, этой записи не существует.
Ваш срок хранения CI удаляет доказательства по таймеру
Объем работы агентов — не единственные часы, отсчитывающие время для цепочки доказательств от задачи до слияния. Если вы поставляете ИИ-систему с высоким уровнем риска на рынок ЕС, Приложение IV Закона ЕС об ИИ требует техническую документацию с логами тестов и отчетами, датированными и подписанными ответственными лицами, а Статья 11 требует, чтобы она оставалась актуальной.
Поддержание актуальности в соответствии с таким правилом предполагает, что доказательства все еще существуют. Запуски тестов и одобрения стоят ровно столько, сколько хранят ваши платформы. Большинство хостинговых CI-платформ удаляют логи рабочих процессов и отчеты о тестах после стандартного периода хранения, который никто в вашей организации не выбирал.
GitHub — это наглядный пример. Он хранит логи 90 дней, с возможностью настройки до 400 дней в приватных репозиториях. Отчет JUnit и лог рабочего процесса для мартовского релиза могут исчезнуть к июню, если кто-то не изменил настройку, которая ни разу не обсуждалась на планировании.
Спустя месяцы служба безопасности вашего крупнейшего клиента запрашивает запись о проверке одного релиза. Задача и pull request все еще на месте. Запуск теста был удален через 90 дней после того, как он был пройден, а рецензент, одобривший код, уволился. Вы подтверждаете работу, которую больше не можете показать, что является запоминающейся позицией для переговоров о продлении контракта.
Прослеживаемость — это проблема чтения
Хранение сохраняет доказательства; поиск их — другая проблема. Большинство программ прослеживаемости терпят неудачу на стороне записи, с которой ваш рабочий процесс уже справляется. Чего не хватает вашей организации, так это пути чтения.
Один запрос должен давать ответ: покажите мне требование REQ-128, задачу, которая его реализовала, и pull request, который его объединил. Затем покажите тесты, которые были пройдены, и рецензента, который их одобрил.
Цепочки поставок программного обеспечения уже рассматривают машинные записи как доказательство. Происхождение SLSA заставляет платформу сборки записывать, как был создан артефакт. Написанные человеком утверждения о сборке остаются утверждениями; машинные записи несут в себе собственное доказательство.
Ваш рабочий процесс оставляет такие же записи. Создание пути чтения означает запланированную задачу, которая вызывает API Jira и GitHub, а затем сохраняет ID задач и отметки времени одобрения.
Увеличьте окно хранения артефактов CI на этой неделе, прежде чем планировать эту задачу. В приватном репозитории эта единственная настройка дает еще 310 дней доказательств, что является лучшей отдачей от одного клика мышкой, которую вы получите в этом квартале.
Изучите Progress Forge Orchestration
Превратите разработку с использованием ИИ в повторяемый инженерный процесс, управляя агентами кодирования, которые вы уже используете, с помощью структурированных и настраиваемых рабочих процессов разработки — от рабочей задачи до пулл-реквеста.
Ваши агенты кодирования выполняют работу. Вы контролируете процесс. Forge управляет им.
Попробуйте Forge прямо сейчас
