Ниже приведен отрывок из нашей книги « Скрам: новичок ниндзя» , написанной М. Дэвидом Грином. Копии продаются в магазинах по всему миру, или вы можете купить их в электронном виде здесь .
В последней главе мы познакомились с миром владельца продукта и прошли через процесс разработки и создания истории для команды. Мы увидели, как были собраны требования, как было создано отставание по продукту, и как ожидания внутренних и внешних клиентов, а также других заинтересованных сторон, превратились в четко определенные истории для команды.
Затем мы рассмотрели, как истории представляются команде, и как команда оценивает их. Мы наблюдали за тем, как команда провела переговоры с владельцем продукта, чтобы убедиться, что то, над чем они будут работать, имело смысл и могло быть завершено в спринте.
Теперь пришло время следовать этой истории через спринт. В этой главе мы увидим, как команда делит большую историю, подобную той, которую мы обсуждали, на более мелкие задачи, и распределяет их так, чтобы все они могли быть обработаны и завершены. Мы увидим, как рассматриваются все аспекты этой истории, пока они не соответствуют определению «сделано».
Наконец, мы увидим, как команда проходит демонстрационный процесс с владельцем продукта, и, если повезет, возможно, история будет принята в конце спринта. В любом случае, на ретроспективе наверняка будет много чего обсудить. Давайте выясним, что происходит.
Работа через историю
К тому времени, когда совещание по планированию закончилось, команда взяла на себя обязательство по новому отставанию в спринте. Как вы, возможно, помните, доска объявлений в настоящее время выглядит так:
Рисунок 8.1. Спринт 11 Первоначальное отставание
Новая история создания тестовой версии сайта для поддержки щенков, помеченная 11-1, стоит в списке приоритетов, но она немного ниже, чем у некоторых историй, которые все еще находятся в стадии разработки с предыдущего спринта, но не были принято еще. Это компромисс, к которому стремится владелец продукта, чтобы команда не теряла импульс на истории, которые почти завершены.
Принимая собственность
На следующее утро команда проводит первый заезд нового спринта. Как обычно, команда идет по кругу, каждый инженер сообщает о том, что они сделали с момента последнего включения, что они планируют делать до следующего перехода, и есть ли у них какие-либо блокировщики. У первых трех инженеров все еще есть работа по очистке из историй, которые они не смогли закончить в предыдущем спринте, и у них нет блокировщиков. Но у четвертого инженера, самого младшего в команде, не осталось никакой работы, и он готов взять новую историю.
«Похоже, я получу большой,» нервно говорит младший инженер. Есть некоторая шутливая аплодисменты от остальной части команды.
«Хорошо, мы пишем ваше имя», — говорит мастер схваток.
«Думаю, я начну проверять это, — говорит младший инженер, — но мне нужна помощь. Кто-нибудь хочет со мной спариться?
«Конечно, мы можем работать вместе», — говорит следующий инженер.
«Отлично», — говорит мастер схваток. «Итак, вы двое — команда, и вы работаете над этой историей. Есть еще блокираторы?
«Просто обычное чувство запугивания», — говорит младший инженер. «Но я думаю, у нас это есть».
Определение задач
Первое, что нужно сделать, если взять большую историю, это поставить ее на место. Это означает определение отдельных подзадач, над которыми можно работать параллельно, чтобы история не попала в ловушку одного человека. Некоторые команды предпочитают разбивать истории на задачи во время совещания по планированию, но эта команда решила, что ответственный за историю также будет отвечать за выполнение задач.
В зависимости от предпочтений команды, задачи могут быть написаны как истории, или они могут быть написаны как технические спецификации, более подходящие для обмена идеями между инженерами. Задачи также могут быть введены в ряд систем слежения за доской объявлений, чтобы их можно было отслеживать и назначать разным людям в процессе разработки, проверки и контроля качества.
Пара инженеров, ответственных за историю о щенках, прорабатывает подэлементы, которые будут необходимы для того, чтобы история стала реальностью. Это займет несколько часов, и им нужно пару раз позвонить владельцу продукта, чтобы уточнить вопросы. К тому времени, как они закончили, они выполнили более шести заданий, каждое из которых нужно будет выполнить, прежде чем история сможет перейти в QA для окончательного тестирования.
Вместе они пишут описания задач и добавляют их в электронную доску объявлений, которую разделяет команда. Еще одним преимуществом наличия задач на доске является то, что члены команды, которые не несут прямой ответственности за всю историю, все же могут взять на себя ответственность за задачу, поэтому работа может быть выполнена более эффективно. Это также имело преимущество в распространении знаний о том, как история реализована в команде.
Когда они завершают добавление новых задач на доску, это выглядит примерно так:
Рисунок 8.2. Спринт 11 с заданиями
Инженер, который стал владельцем истории, предупреждает QA о состоянии задач. Поговорив с QA, они обсуждают план тестирования и выбирают некоторые стандарты того, как тесты должны оцениваться, чтобы соответствовать критериям приемлемости оригинальной истории. В этом случае принято решение, что QA будет участвовать в тестировании фрагментов истории, пока все компоненты находятся в стадии завершения. Заблаговременное участие в QA дает им возможность начать писать тесты как можно раньше.
Отслеживание прогресса
Как только все задачи определены, исходная пара определяет приоритетный порядок задач и решает, какую задачу, по их мнению, необходимо выполнить в первую очередь, чтобы поддержать разработку остальных задач. Между ними они чувствуют, что у них есть навыки, необходимые для выполнения первой задачи, поэтому они назначают себя для этой задачи и приступают к разработке необходимого кода без вызова дополнительной помощи.
На этом этапе они перемещают первое задание для истории о щенках в столбец «В процессе»:
Рисунок 8.3. Спринт 11 Первое задание
Чуть позже один из других инженеров в команде завершает историю, проверяет ее с помощью QA, чтобы убедиться, что она завершена, и затем может начать работу над новыми историями. Инженер проверяет доску и видит, что некоторые новые задачи из этой высокоприоритетной истории еще не начаты. После проверки с первой парой, чтобы убедиться, что между задачами не будет совпадений, инженер вступает во владение следующей задачей с наивысшим приоритетом в главном материале, обновляет доску объявлений и приступает к работе.
Когда выполняется второе задание, доска объявлений выглядит примерно так:
Рисунок 8.4. Спринт 11 Второе задание
Владелец продукта также следит за тем, чтобы поработать над копией для истории о щенках и проверить в Design на предмет состояния активов. Теперь самое время проверить доску схваток и посмотреть, что происходит.
Одна история, которая находилась в процессе разработки и еще не завершена в последнем выпуске, теперь указана как готовая к демонстрации. Новая история создания версии сайта для щенков началась, была разделена на шесть задач, и две из этих задач уже выполняются. Владелец продукта делает пометку, чтобы проверить статус задач после завтрака.
До конца дня мастер схватки проверяет статус историй на доске. Новые задачи были добавлены, и формат чистый, что означает, что команда, работающая над историей о щенках, правильно выполнила существующие соглашения. Кажется, нет необходимости прерывать инженеров, которые работают над их историями.
Первый Standup
На следующий день на ежедневной скамье подсудимых инженер QA, ответственный за историю с сайтом для щенков, принимает к сведению статус всех заданий. Владелец продукта также присутствует.
Примечание: посещение QA в Standups
Некоторые команды рассматривают QA как членов основной команды, но для команды WithKittens QA не требуется активно участвовать во всех командных действиях. Люди, не являющиеся членами команды, должны решать, будут ли они присутствовать на турнире. WithKittens QA посещает стенды только тогда, когда их предупреждают, что могут обсуждаться новые задачи или истории. Владелец продукта любит, когда это возможно, находиться на всех постах. Конечно, ни QA, ни владелец продукта не говорят до тех пор, пока все инженеры команды не сообщат об их статусе. Даже тогда мастер схватки ограничивает их заявлениями, актуальными для всей команды.
Первым должен сообщить младший инженер, отвечающий за историю о щенках, который объясняет, как они разбили историю на задачи и как они начали работать над первым заданием.
«Мы будем благодарны за любые отзывы о разбивке задач», — говорит младший инженер. «Я думаю, что мы рассмотрели все критерии приемлемости, но чем больше у нас на это взгляда, тем лучше я буду себя чувствовать».
«Таким образом, вы будете работать над этой задачей до конца дня?» — спрашивает мастер схваток.
«Да, я думаю, что мы будем.»
«Есть ли какие-нибудь блокираторы?» — спрашивает хозяин схватки.
«Я так не думаю», — отвечает младший инженер.
«Нет, я не думаю, что у нас есть какие-либо блокираторы», — соглашается другой инженер в этой истории. «Мы должны работать над этим, по крайней мере, до завтра».
«Отлично», — говорит мастер схватки, делая пометку, чтобы выполнить запрос обратной связи, и затем продолжается по кругу, пока все не сообщат. Затем команда увольняется, и инженеры возвращаются к своим различным проектам.
После запуска владелец продукта регистрируется с мастером схваток и людьми, работающими над заданиями для истории о щенках, и сообщает им, что проектная работа была начата, и обновления копий, которые они обсуждали на совещании по планированию, находятся в репозиторий. Ни одна из задач, требующих средств проектирования, еще не была начата. Основываясь на обновлениях из стенда, они, вероятно, не будут запущены, пока у дизайнера не будет все готово.