Все о SCRUM. Изучение, разработка, интеграция

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

• Продолжить разговор

Совокупность историй, их условий и приемочных тестов заменяют подробную функциональную спецификацию с существенным преимуществом: общение происходит напрямую.

Это не значит, что учет и отслеживание отсутствуют. В качестве ориентира следует использовать тесты, а не истории. Тестовый репозиторий постепенно дополняется и обновляется.

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

Чтобы подчеркнуть, что история принята, можно определить задачу и включить ее в таблицу задач спринта. А можно пойти дальше и поместить тесты в таблицу вместо задач: тогда Post-it®, связанные с историей, будут относиться к тестам или, в более широком смысле, к условиям приемки.

• Проверить как можно раньше

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

Для проверки необходимо запустить тесты на последней версии программного обеспечения. Если какие-то тесты ее не проходят, быстро вносится исправление (после добавления Post-it® в таблицу). Минимальная цель – пройти все тесты до окончания спринта. Более амбициозная цель – пройти их несколько раз в течение спринта, после каждого завершения истории или изменения в коде.

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

• Принять условие и завершить историю

На основе результатов выполнения тестов и с учетом проверок критериев завершенности Владелец продукта объявляет историю завершенной. В ином случае сообщает команде о том, что не так.

Рисунок 19.3 – История принимается не всегда

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

19.4 Техобслуживание

19.4.1 Фазы техобслуживания не существует

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

В Scrum этого разделения нет: сезоны продолжаются, Scrum-фреймворк и Agile-практики все так же применимы, тот же бэклог и, желательно, те же команды.

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

Можно продолжать работать в рамках Scrum, дополняя его техниками из Kanban, подробнее об этом в главе 20.

19.4.2 Управление ошибками

Определение ошибки зависит от проекта и точек зрения участников. Определение устранения ошибки, предложенное мною в главе 6 «Структура бэклога», не соответстует общепризнанному.

• В текущей истории

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

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

Так что он не считается ошибкой.

• В завершенной истории

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

Чем значительнее ошибка, тем сильнее она снижает полезность истории.

✓ Критическая ошибка затрудняет функционирование одной или нескольких историй, их полезность при этом становится нулевой.

✓ Серьезная ошибка ограничивает функционирование, полезность истории уменьшается.

✓ Незначительная ошибка означает, что история теряет часть своей ценности, ее использование затрудняется.