Ниже приведен отрывок из нашей книги « Скрам: новичок ниндзя» , написанной М. Дэвидом Грином. Копии продаются в магазинах по всему миру, или вы можете купить их в электронном виде здесь .
Второй Standup
На второй день спринта владелец продукта и инженер по обеспечению качества снова присутствуют на стенде. Все инженеры присутствуют, и ни у кого нет никаких блокировщиков для историй, над которыми они работают. Поскольку мастер схватки собирается уволить команду, один из инженеров говорит.
«У меня есть быстрый вопрос о том, как эта история о щенках будет работать со страницами справки на сайте», — говорит инженер. «Я думал об этом вчера вечером, и это будет сбивать с толку людей в бета-версии, если на страницах справки нет ничего, что объясняло бы, что такое бета-версия и как вернуться на обычный сайт».
«Это хороший момент», — говорит владелец продукта. «Как вы думаете, это то, что мы можем справиться с планами для пользовательского заголовка?»
«Я не уверен», — говорит инженер. «Заголовок в настоящее время не структурирован для отображения по-разному на страницах справки».
«Это то, что вы думаете, было бы легко добавить?» — спрашивает владелец продукта.
«Я бы на это не рассчитывал», — говорит другой инженер. «Как сайт структурирован, страницы помощи обслуживаются отдельно от остального контента».
«Верно», — говорит первый инженер. «Это будет сложно».
«Нужна ли нам вся команда здесь для этого, — спрашивает мастер схваток, прерывая разговор, — или мы можем отключить это?»
«Я не знаю», — говорит владелец продукта.
«Да, мы можем отключить это», — отвечает первый инженер.
«Хорошо, отлично», — говорит мастер схваток. «В этом случае стойка окончена».
Когда остальная часть команды возвращается к своим рабочим столам, чтобы продолжить работу над своими проектами, мастер scrum переходит к владельцу продукта и двум инженерам, которые обсуждают страницы справки.
«Должны ли мы втроем обсудить это сейчас или мы хотим продолжить это позже?» — спрашивает мастер схваток.
«Думаю, я вижу, в чем проблема», — говорит владелец продукта. «Я могу написать историю, которая, как мне кажется, должна работать».
«Мы собираемся добавить это как новую историю?» — спрашивает мастер схваток.
«Мне кажется, что объем ползет ко мне», — говорит первый инженер.
«Нет, я думаю, что это соответствует критериям приемлемости оригинальной истории», — говорит владелец продукта. «Это страницы на сайте, и они должны обрабатываться так же, как и любые другие страницы на сайте».
«Давайте проверим критерии приемлемости и убедимся», — говорит мастер схватки.
Вместе четверо из них идут к компьютеру, поднимают доску схваток и смотрят на критерии приемлемости истории, как ее оценила команда. Фактически, критерии принятия говорят о том, что изменения в заголовке для поддержки бета-пользователей сайта щенков должны охватывать все страницы сайта, без различия страниц справки.
«Ну, это будет сложно», — говорит первый инженер.
«Нужны ли нам какие-либо дополнительные подробности о том, как это должно быть реализовано, как только мы получим обновленный текст от владельца продукта? «Или вы можете написать спецификации и добавить это задание в доску?»
«Я могу это сделать», — говорит первый мрачно, немного угрюмо. «Но, похоже, это может добавить больше усилий к истории, чем мы ожидали».
«Да», соглашается второй инженер. «Я не думаю, что мы оценили это с достаточным количеством очков».
«Ну, мы не можем сейчас изменить оценку», — говорит мастер схваток. «Просто еще один пункт данных. Мы должны будем делать то, что можем.
«Значит ли это, что вы не думаете, что сможете закончить эту историю к концу спринта?» — спрашивает владелец продукта.
«Посмотрим», — отвечает первый инженер.
Четверо из них смотрят на критерии принятия истории на мгновение. Затем мастер схватки спрашивает: «Хорошо, мы все хороши? Не забудьте рассказать владельцу истории о добавляемой задаче ».
Все они кивают и возвращаются на работу. Через несколько часов новое задание добавляется на доску объявлений инженером, который принял на себя эту ответственность, и доска выглядит следующим образом:
Рисунок 8.5. Sprint 11 Новая задача
Остальная часть спринта
К концу спринта большая часть команды погрузилась в историю о щенках, но больше ничего не было сделано. Проектирование завершило процесс взаимодействия с интерфейсным пользователем и активами изображений и работает с инженерами, чтобы обеспечить их надлежащую интеграцию.
Пока команда работает над кодом, QA разрабатывает тесты, необходимые для его проверки. QA также пару раз встречается с владельцем продукта, чтобы уточнить критерии приемки. В конце концов, каждая из задач перемещается по доске от In Progress к To Demo.
Примечание. Использование третьего инженера для проверки кода
Поскольку многие из задач в этой истории выполняются парами, для проверки кода должен быть задействован третий инженер. Не каждая команда требует, чтобы код, созданный парами, был проверен третьим инженером, но эта команда включила его в свое определение выполненного.
Несмотря на необходимость поддержки страниц справки, команде удается завершить и просмотреть весь код, чтобы удовлетворить их. Из-за необычных соглашений об именах, которые они должны принять, чтобы отличить этот код от остальной части сайта, во время проверок кода возникает некоторая путаница. Это немного замедляет разработку, но не настолько, чтобы помешать младшему инженеру, взявшему на себя ответственность за историю, передать ее в QA для окончательной проверки перед окончанием спринта.
Определение сделано для этой команды включает в себя как проверку кода и QA, так и принятие клиента. Поскольку QA была интегрирована с командой с самого начала, они строили набор тестов на протяжении всего спринта на основе критериев приемлемости.
В большинстве заданий для этой истории был подготовлен проверенный код, который можно тестировать независимо по мере выполнения. Теперь просто запустить интеграционные тесты и убедиться, что функции работают должным образом от начала до конца. Если история будет принята и отправлена в производство, эти тесты будут добавлены в универсальный пакет для сайта.