Документ архитектуры, если он существует, обновляется с каждым спринтом и заносится в критерии завершенности. Но важно качество архитектуры, и понятно это должно быть не из документа.
Качество архитектуры подтверждается кодом, а не документом.
Практика стихийного проектирования отражается в регулярных задачах, относящихся к проектированию. Во время спринта команда с этим сталкивается дважды.
✓ На этапе планирования спринта, а точнее, во время роения команда коллективно работает над проектированием истории. Результат работы развивается в процессе спринта и может быть изображен на диаграмме последовательности, показывающей взаимосвязи между компонентами. Или другим образом, подходящим участникам.
✓ На этапе разработки истории написание тестов в первую очередь (разработка через тестирование) подходит и для проектирования. Этот процесс выполняется одним разработчиком или в паре.
Во время спринта может потребоваться технический анализ. Такое исследование называется spike (в русском языке наиболее часто употребляется вариант «спайк» – ред.). Необходимость в его проведении выявляется на моменте доработки. Затем spike вносят в бэклог в соответствии с расставленными приоритетами.
В конце спринта, уже после спайка, команда подбирает решение и способна подготовить историю, что соответствует пункту спайк в паттерне разделение истории, представленном в главе 7.
19.3 Практики, относящиеся к тестированию
На данном этапе команда подтверждает, что история завершена с функциональной точки зрения. В седьмой главе мы с вами рассмотрели условия приемки и паттерн 6К.
Чтобы подготовить историю, Владелец продукта и команда во время доработки добавляют условия приемки.
История должна обладать условием приемки, а лучше несколькими (но не большим количеством). Каждому условию соответствует один или несколько приемочных тестов.
• Кто определяет тест?
Scrum ставит акцент на команде без привязки к конкретным ролям. В ней нет явной роли тестировщика, но это совсем не значит, что команда не проводит тестов! Некоторые по-прежнему придерживаются идеи, что тестирование выполняет заказчик. Это может побудить разработчиков делегировать все задачи Владельцу продукта или даже заинтересованным сторонам.
И это не лучшая идея: из-за обилия задач и компетенций Владелец продукта чаще всего не в состоянии брать на себя ответственность еще и за этот блок работы. Более того, этот этап выполняется коллективно и благоприятствует общению внутри команды.
В итоге не имеет значения, кто определяет тесты. Важно, чтобы все друг друга понимали и дело было сделано в нужное время. Это становится коллективной ответственностью.
⁃ Как определить тест?
Мы поговорили о BDD как о языке условия приемки. На конкретном примере перейдем к тесту приемки.
Дано: Коринна – владелец пса по имени Гэри и оформление регистровой родословной для собак породы бассет-хаунд, назначенное на 24 апреля и с 34 заявками на данный момент.
Когда: Коринна записывает своего двухлетнего пса породы бассет-хаунд Гэри на оформление регистровой родословной 24 апреля.
Тогда: запись Гэри принята и сообщение Вы успешно записаны на 24 апреля выслано Коринне и количество заявок выросло до 35.
Разница между условием приемки и приемочным тестом в том, что тест содержит значения, которые составляют пример. Вот почему мы говорим о спецификации на примере с набором историй и приемочных испытаний.
Все больше распространяются инструменты, ориентированные на BDD – такие как Cucumber – позволяющие облегчить переход к автоматизированному тестированию.
Тем не менее, BDD – это, прежде всего, подход, содействующий коммуникации между Владельцем продукта и разработчиками.
Во время спринта приемочные испытания можно выполнять по ходу разговора.
Приемочный тест проверяется как можно раньше. Как только все прошло проверку, история принята и считается завершенной. Для избежания регрессий во время и после спринта тесты должны быть повторно воспроизведены – отсюда важность автоматизации.
• Продолжить разговор
Совокупность историй, их условий и приемочных тестов заменяют подробную функциональную спецификацию с существенным преимуществом: общение происходит напрямую.
Это не значит, что учет и отслеживание отсутствуют. В качестве ориентира следует использовать тесты, а не истории. Тестовый репозиторий постепенно дополняется и обновляется.
Во время спринта часто бывает, что тесты меняются, завершаются, иногда даже добавляются новые, особенно после разговоров с Владельцем продукта.
Чтобы подчеркнуть, что история принята, можно определить задачу и включить ее в таблицу задач спринта. А можно пойти дальше и поместить тесты в таблицу вместо задач: тогда Post-it®, связанные с историей, будут относиться к тестам или, в более широком смысле, к условиям приемки.
• Проверить как можно раньше
Разработка истории происходит быстро во время спринта. В группе из нескольких человек она длится от одного до трех дней.
Для проверки необходимо запустить тесты на последней версии программного обеспечения. Если какие-то тесты ее не проходят, быстро вносится исправление (после добавления Post-it® в таблицу). Минимальная цель – пройти все тесты до окончания спринта. Более амбициозная цель – пройти их несколько раз в течение спринта, после каждого завершения истории или изменения в коде.
Чтобы избежать регрессии, для каждой новой версии следует повторять все тесты. По этой причине следует подумать об их автоматизации.
• Принять условие и завершить историю
На основе результатов выполнения тестов и с учетом проверок критериев завершенности Владелец продукта объявляет историю завершенной. В ином случае сообщает команде о том, что не так.
Рисунок 19.3 – История принимается не всегда
Владелец продукта может делегировать это, если команда использует роение или если он в данный момент недоступен и не может сделать это быстро.
19.4 Техобслуживание
В крупных организациях обычно разделяют процессы разработки продукта и обновлений после ввода в эксплуатацию. Фаза техобслуживания наступает после первичной разработки. При этом команды, процедуры и инструменты чаще всего отличаются.
В Scrum этого разделения нет: сезоны продолжаются, Scrum-фреймворк и Agile-практики все так же применимы, тот же бэклог и, желательно, те же команды.
Но если работы стало меньше, размер команды, скорее всего, тоже уменьшится. Иногда техобслуживание передается специализированной команде, которая занимается несколькими проектами. Ключевыми моментами этого процесса являются управление ошибками и запросы на изменения. Как только они поступают в поток, команда переходит на Kanban.
Можно продолжать работать в рамках Scrum, дополняя его техниками из Kanban, подробнее об этом в главе 20.
Определение ошибки зависит от проекта и точек зрения участников. Определение устранения ошибки, предложенное мною в главе 6 «Структура бэклога», не соответстует общепризнанному.
• В текущей истории
Дефект, который был обнаружен в истории, находящейся в разработке, является условием непринятия: история не завершена. Участники команды, работающие над историей, просто добавляют задачу, необходимую для его исправления.
Этот дефект не помещается в бэклог, не говоря уже об использовании инструмента отслеживания ошибок: было бы пустой тратой времени и сил.
Так что он не считается ошибкой.
• В завершенной истории
Случается, что ошибка обнаруживается в истории, которая была разработана в предыдущем спринте и на данный момент считается завершенной. А зря, так, к сожалению, часто бывает. Под эту категорию также попадают ошибки в частях продукта, разработанных до того, как в проект был внедрен Scrum.
Чем значительнее ошибка, тем сильнее она снижает полезность истории.
✓ Критическая ошибка затрудняет функционирование одной или нескольких историй, их полезность при этом становится нулевой.
✓ Серьезная ошибка ограничивает функционирование, полезность истории уменьшается.
✓ Незначительная ошибка означает, что история теряет часть своей ценности, ее использование затрудняется.
Формально, если условия приемки проверены, критическая или серьезная ошибка означает регресс и требует немедленного исправления и анализа причин ее возникновения. Этот процесс никак не отражается в бэклоге.
Если у истории отсутствует условие приемки, это не ошибка, а новая пользовательская история. В бэклог вносятся только незначительные ошибки, которые не требуют дополнительного условия принятия.
Ошибки, отраженные в бэклоге, обрабатываются в соответствии с рабочим процессом: они дорабатываются и упорядочиваются. Владелец продукта должен решить, является ли исправление (некритической) ошибки более важным, чем разработка новой пользовательской истории.
• Ошибка в существующем коде
Если команда внедрила технику разработки через тестирование, она сначала пишет модульные тесты, которые воспроизводят ошибку (красный этап), а затем пишут код для прохождения тестов (зеленый этап). Таким образом, команда улучшает общее качество ПО.