Трассировка и изменения
Вопросы про управление требованиями довольно чётко отделяют джуна от мидла. Джун умеет собирать требования, мидл умеет ими управлять, когда их триста и они меняются каждую неделю.
Стержень: у требования есть идентификатор и связи вверх - к целям - и вниз, к реализации и тестам. На этих связях держится оценка влияния и вся работа с изменениями.
// Формулировки: «что такое матрица трассировки?», «как оценишь влияние правки?», «что такое расползание объёма?»
Идентификатор и базовая версия
Идентификатор превращает абзац текста в объект, на который можно сослаться. Тест-кейс ссылается, задача ссылается, письмо и протокол встречи ссылаются. Без идентификатора ссылаются на номер страницы или на фразу - и то и другое поедет при первой же правке документа.
Базовая версия - это согласованный срез набора требований, зафиксированный на определённую дату. С этого момента любая правка идёт через процедуру с оценкой влияния. Без такого среза невозможно отличить уточнение от расширения объёма, и спор «мы так не договаривались» становится принципиально неразрешимым: сравнить не с чем.
// Отсутствие версий бьёт не сразу, и в этом коварство. Первые месяцы всё прекрасно. Больно становится через год на разборе инцидента, когда надо показать, каким требование было на дату приёмки, а в вики лежит только текущая редакция и история правок без объяснений.
- базовая версия
- зафиксированный согласованный срез требований на дату. Точка отсчёта, относительно которой считаются все последующие изменения
Связи вверх и вниз
Связь вверх ведёт к бизнес-цели и отвечает на вопрос «зачем это вообще существует». Она нужна не для красоты: когда объём режут, требования без связи вверх режут вслепую - либо выкидывают нужное, либо годами тащат то, что давно потеряло смысл.
Связь вниз ведёт к коду и тестам и даёт сразу две вещи. Первая - оценка влияния: при правке видно, что именно придётся трогать. Вторая - контроль покрытия: требование, на которое не ссылается ни один тест, видно с одного взгляда на матрицу.
Полезен и обратный ход, снизу вверх. Код и тесты, за которыми не стоит ни одного действующего требования, - это осиротевшая функциональность. Её поддерживают, тестируют и боятся трогать, а зачем она нужна, уже никто не помнит.
// Матрица трассировки звучит тяжеловесно, но на практике это просто таблица связей. Её ценность не в самом факте существования, а в том, что по ней за пять минут отвечают на вопрос «что сломается, если мы это поменяем».
Изменения и расползание объёма
«Мелкость» правки определяется не длиной формулировки, а числом связей, которые она тянет. Смена одного значения в справочнике выглядит как правка на одно слово, а задевает интеграцию с внешней системой, три отчёта и десяток тестов.
Расползание объёма - это новая функциональность вне согласованных целей при неизменных сроках и бюджете. От уточнения оно отличается одним признаком: уточнение выводится из исходных целей, а расползание приносит новую цель, о которой не договаривались.
Лечится оно не отказом, а видимостью. Каждое добавление проходит оценку влияния и явный пересмотр плана: вот что меняется, вот сколько это стоит, вот что придётся подвинуть. Тогда решение принимает тот, кто за него платит, - а это и есть его работа, не твоя.
// Отдельно стоит фиксировать причину каждого изменения, а не один лишь факт. Через полгода никто не помнит, почему требование выглядит именно так, и его начинают «чинить» обратно - иногда прямо в нарушение того самого регламента, ради которого его и правили.
Как отвечать: «Заказчик просит мелкую правку в согласованном требовании. Твои действия?»
Сначала оцениваю влияние по связям: смотрю, какие смежные требования, какие части системы и какие тесты завязаны на это место. Мелкая по тексту правка часто тянет за собой интеграцию и отчётность, и разговор о трудоёмкости надо вести на конкретном списке затронутого, а не на ощущениях - список гораздо убедительнее любых оценок «на глаз». Дальше несу результат владельцу требования: вот что меняется, вот сколько это стоит по срокам, вот что придётся подвинуть. Решение принимает он, я его фиксирую вместе с причиной, чтобы через полгода было понятно, откуда это взялось. Отказывать не стал бы: набор фиксируют не ради запрета изменений, а ради того, чтобы они шли через понятную процедуру и никого не удивляли.
Ответ показывает процедурное мышление: аналитик не решает за бизнес и не саботирует изменения, но даёт основу для решения. Последняя фраза снимает типичное возражение про бюрократию.
На чём валятся
- −− Ведут требования без версий и потом не могут доказать, что именно принималось на дату приёмки.
- −− Оценивают правку по объёму текста, а не по числу связей, которые она тянет.
- −− Считают базовую версию запретом на изменения и вступают в конфликт с заказчиком на пустом месте.
- −− Поддерживают только связь вниз: непонятно, зачем требование нужно и что сломается при его отмене.
- −− Не фиксируют причину изменения - через полгода требование «чинят» обратно, не понимая, зачем оно такое.
Проверьте себя
Пять вопросов из банка по этой подтеме. Всего их 12, остальные разбираются в тренажёре.
- Зачем нужна трассировка вниз — от требования к тестам?A)Чтобы видеть требования без единой проверкиB)Чтобы посчитать стоимость тестированияC)Чтобы распределить тесты между тестировщикамиD)Чтобы автоматически сгенерировать тест-кейсы
показать ответ и разбор
+A)Чтобы видеть требования без единой проверки// разбор: Связь вниз закрывает вопрос покрытия: требование без единого теста — кандидат в непроверенную функциональность, и такие дыры видно сразу. Обратный ход тоже полезен: тест, не привязанный ни к одному требованию, часто оказывается проверкой давно отменённого поведения.
- Заказчик просит «мелкую правку» в согласованном требовании. С чего начать?A)Внести правку сразу, раз она мелкаяB)Отказать: набор уже зафиксированC)Оценить по связям, что именно затронутоD)Отложить до следующего релиза без обсуждения
показать ответ и разбор
+C)Оценить по связям, что именно затронуто// разбор: «Мелкость» правки определяется не размером формулировки, а числом связей, которые она тянет. Смена одного справочного значения способна затронуть интеграцию, отчётность и десяток тестов. Оценка влияния по матрице трассировки превращает спор о трудоёмкости в разговор о конкретном списке затронутого.
- Какой признак указывает на scope creep, а не на нормальное уточнение?A)Формулировка требования стала длиннееB)Команда переоценила часть историйC)Заказчик задаёт много вопросов на демонстрацииD)Объём растёт вне целей, а план прежний
показать ответ и разбор
+D)Объём растёт вне целей, а план прежний// разбор: Уточнение раскрывает то, что уже подразумевалось целью, и объём от него меняется мало. Расползание — это новая функциональность, которую не выводят из согласованных целей, причём сроки и бюджет остаются прежними «по умолчанию». Лечится не отказом, а видимостью: каждое добавление проходит оценку влияния и пересмотр плана.
- Требование отменили, но связанный с ним код остался в системе. Как это обнаруживается?A)По росту числа дефектов в этой части системыB)Обратной трассировкой от кода к требованиямC)Нагрузочным тестированиемD)Ревью архитектуры
показать ответ и разбор
+B)Обратной трассировкой от кода к требованиям// разбор: Ход снизу вверх ищет осиротевшие артефакты: функцию, которую никто не заказывал, и тесты, защищающие отменённое поведение. Такой код опасен вдвойне — он поддерживается, тормозит изменения и иногда срабатывает в проде, воспроизводя логику, от которой бизнес давно отказался.
- Почему двусторонняя трассировка дороже односторонней, но чаще окупается?A)Она требует специального инструмента с лицензиейB)Она заменяет собой регрессионное тестированиеC)Она автоматически поддерживается системами контроля версийD)Отвечает и на «что сломается», и на «зачем это»
показать ответ и разбор
+D)Отвечает и на «что сломается», и на «зачем это»// разбор: Связь вниз даёт оценку влияния при правке, связь вверх — обоснование при сокращении объёма и чистку мёртвого кода. Поддерживать обе дороже: связи надо обновлять при каждом изменении. Окупается там, где система живёт годами и меняется постоянно, и почти не окупается на коротком проекте с известным финалом.
дальше
Теорию прочитали. Навык ставится повторением
В Сеньорчике эта подтема идёт в ежедневных сессиях: движок возвращает её, пока ответы не станут уверенными, и ведёт прогресс отдельно по каждой подтеме. Теория внутри тоже бесплатна, лимит только на количество вопросов в день.