Книга: Постигая Agile

Планирование и выполнение спринта с использованием историй, очков, задач и доски задач

Планирование и выполнение спринта с использованием историй, очков, задач и доски задач

Планирование спринта проводится, чтобы сформулировать развернутые ответы на два вопроса.

• Что команда поставит заказчику в этом спринте?

• Как команда сделает эту работу?

Мы только что продемонстрировали, как можно использовать очки историй и скорость команды для определения, что будет включено в спринт. Это распространенный способ, при помощи которого scrum-команды выполняют первую часть планирования спринта. Но каким образом они определяют ответ на второй вопрос?

Один из самых распространенных для scrum-команды способов спланировать свои действия – это добавить карточки индивидуальных задач разработки. Это могут быть любые задачи, которые выполняет команда: написание кода, создание дизайна и архитектуры, разработка тестов, установка операционных систем, проектирование и создание баз данных, развертывание программного обеспечения на рабочих серверах, проведение юзабилити-тестов и всех прочих действий, которые команды выполняют повседневно в процессе сборки и выпуска программного обеспечения.

Вот примерная последовательность действий команды.

1. Команда проводит вторую сессию по планированию спринта. Scrum-мастер берет первую историю и обсуждает с командой, что они должны сделать, чтобы ее выполнить.

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

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

2. Истории и их задачи группируются и добавляются в колонку «сделать» на доске задач.

Рис. 5.9. Карточка каждой пользовательской истории, включенной в спринт, группируется вместе с карточками своих задач и добавляется в колонку «сделать» доски задач.

3. Когда член команды завершает задачу и готов двигаться дальше, он перемещает карточку выполненной задачи в колонку «сделано». Затем он вытягивает следующую карточку из колонки «сделать», пишет на ней свое имя и клеит ее обратно на доску в колонку «в процессе». Если история все еще находится в колонке «сделать», то он также перемещает ее в колонку «в процессе» (но не пишет на ней свое имя, потому что кто-нибудь из коллег по команде может работать над задачами для той же истории).

Рис. 5.10. Каждый член команды одновременно работает только над одной задачей, указав свое имя на ее карточке и перенеся ее в раздел «в процессе» доски задач

4. По мере того как продвигается работа над спринтом, команда переносит задачи из колонки «сделать» в колонку «в процессе» и затем – в «сделано». Нередко члены команды обнаруживают, что им необходимо выполнить дополнительные задания, чтобы закончить историю. Когда такое происходит, новая задача заносится на доску, а член команды сообщает об этом на ежедневном scrum-митинге, чтобы все понимали ситуацию и могли помочь определить потенциальные проблемы.

5. Как только член команды заканчивает последнюю задачу в истории, он снимает карточку задачи с доски, проверяет, выполнены ли все условия, и переносит ее в колонку «сделано» так, чтобы она располагалась рядом со всеми своими задачами. (Но помните: история не считается «сделанной» до тех пор, пока владелец продукта не примет ее для передачи заказчику от имени компании!) Если он обнаружит, что один из критериев удовлетворенности не был выполнен, – он перемещает историю обратно в столбец «сделать» и добавляет задачи, позволяющие завершить эту работу и переместить историю в колонку «сделано».

Рис. 5.11. Когда член команды заканчивает задачу, он перемещает ее в раздел «сделано» доски задач и берет следующую задачу. И если все условия удовлетворенности выполнены, то карточка пользовательской истории тоже перемещается в раздел «сделано»

6. Спринт выполнен, когда его временные рамки исчерпаны. Однако при этом могут оставаться карточки историй и задач, находящиеся в столбцах «сделать» и «в процессе». Эти истории возвращаются назад, в бэклог продукта, и могут быть объявлены приоритетными в следующей сессии по планированию спринта[43]. При этом команда может уменьшить назначенное им количество баллов в зависимости от числа задач этой истории, которые остались невыполненными. История не засчитывается команде как выполненная, пока ее карточка и все карточки ее задач не будут перемещены в столбец «сделано».

В упоминавшейся книге по Scrum Кена Швабера Agile Project Management with Scrum ничего не говорится о пользовательских историях и очках историй. Многие команды узнали о них из других источников, например книги Майка Кона «Пользовательские истории. Гибкая разработка программного обеспечения» (о которой мы говорили в главе 4).

Есть много замечательных практик, которые команды используют, чтобы улучшить свой уровень владения Scrum. Это не должно вызывать удивления. Мы применяем прошлый опыт, чтобы улучшить текущие разработки. Если мы решим ограничиться тем, что один человек написал в своей книге, и откажемся расширять свои горизонты, то нет смысла искать пути совершенствования.

Именно поэтому многие команды используют дополнительные техники и методы, которые Кон назвал общепринятой практикой Scrum (Generally Accepted Scrum Practices – GASPs)[44]. Например, многие команды приходят к выводу, что ежедневные scrum-митинги более эффективны, если проходят в виде standup-совещаний (когда все участники стоят, а не сидят). Этот прием не относится к числу основных scrum-практик, но широко применяется scrum-командами.

Вспомните последний принцип Agile-манифеста:

Вы и ваша команда должны помнить об этом, когда проводите ретроспективные обзоры. Попробуйте найти пути для улучшений, не пытаясь изобретать велосипед. Если вы сталкиваетесь с проблемами в Scrum, то наверняка кто-то уже нашел их решение. Хороший наставник (например, такой как Эрик для Роджера и Ави) наверняка поможет найти решение, которое устранит проблему.

Оглавление книги