не принадлежит какому-то конкретному члену команды – она либо игнорируется вовсе, либо обязанности, связанные с этой ролью, распределяются между несколькими членами команды.
При подготовке к очередному спринту команда выполняет определенные действия. Владелец продукта инспектирует бэклог, чтобы убедиться, что пользовательские истории, запланированные к реализации в ходе очередного спринта, хорошо прописаны и понятны всем членам команды. Обычно он проводит установочные совещания (так называемые совещания по уточнению бэклога) совместно с ведущим разработчиком или менеджером по разработке.
Рисунок 12.1 дает наглядное представление о рабочем потоке, совещаниях и подведении итогов, согласно принципам Scrum.
Рисунок 12.1. Структура Scrum
Каждый спринт команда начинает с проведения совещания по планированию спринта, на котором принимается решение, какие пользовательские истории будут реализованы в ходе очередной итерации. Отобранные истории перемещают из бэклога продукта в бэклог спринта. Частью этого процесса является оценка масштаба каждой истории, которая осуществляется с использованием оценочных баллов, отражающих относительную трудоемкость реализации конкретной истории. Сам процесс оценки часто является скорее искусством, чем наукой. В разных источниках вы можете найти множество используемых систем начисления баллов. Некоторые из них позволяют присваивать истории любое количество баллов: 1, 2, 3, 4, 5, 6 и так далее. Распространенным подходом является использование ряда Фибоначчи, где допустимыми значениями являются числа: 1, 2, 3, 5, 8, 13 и так далее. Преимущество такого подхода заключается в том, что он лучше отражает различия между разными парами рядом стоящих оценок. Другой популярной системой, которая в еще большей степени отражает различия в оценочных значениях, является шкала, построенная на «степенях двойки»: 1, 2, 4, 8, 16 и так далее. Еще один популярный метод основан на «размерах футболки» и использует для оценки масштабов пользовательских историй обозначения, обычно применяемы к размерам одежды: S, M, L, XL. Истории, набравшие наибольшее количество баллов в любом из применяемых диапазонов оценок, имеют значительную степень неопределенности и должны быть разбиты на более мелкие истории (см. главу 6). Истории, которые слишком велики для того, чтобы их можно было завершить за одну итерацию, называют эпопеями. Прежде чем добавить их в спринт, они в обязательном порядке должны быть разбиты на части. Многие применяемые в Agile инструменты отслеживания позволяют использовать эпопеи для создания связанных историй и управления ими на протяжении нескольких итераций.
Если описанный оценочный подход выглядит для вас немного абстрактным, то это лишь потому, что он таковым и является, – по крайней мере, на первый взгляд. Его цель состоит в том, чтобы определить работоспособность команды, отслеживая, сколько баллов она способна отработать на каждой итерации. Данный показатель называют скоростью работы команды. При известной средней скорости команды этот показатель используется для планирования спринтов. Таким образом, несмотря на то что система балльной оценки поначалу кажется несколько оторванной от реальности, она успешно применяется для определения эмпирических значений. Чтобы рассчитать скорость работы, каждая пользовательская история должна быть оценена в числовом выражении (в случае применения в качестве оценок размеров футболки необходимо соотнести каждый размер с определенным количеством баллов).
На Рисунке 12.2 представлен пример того, как команда отслеживает свою скорость на протяжении нескольких итераций. По горизонтальной оси показана пронумерованная последовательность итераций. Вертикальная ось показывает количество отработанных баллов. На протяжении приведенных на рисунке 12 итераций скорость работы команды была переменной (от 22 до 40 баллов), что является нормой. Несмотря на подобную изменчивость, линия тренда показывает, что с течением времени команда неуклонно увеличивала скорость своей работы.
Рисунок 12.2. Скорость работы команды
Scrum-команды используют различные методы, позволяющие уменьшить степень неточности своих оценок и, таким образом, добиться более стабильной скорости выполнения работ. Например, часто применяется коллективное обсуждение и оценка историй, вместо того чтобы доверить эту функцию только одному из членов команды. Некоторые команды разрабатывают эталонный набор пользовательских историй, имеющих разный масштаб. Сравнение новых историй с эталонными помогает получить более точную оценку трудозатрат на их реализацию.
Покер планирования – популярная техника получения быстрой, но при этом надежной оценки пользовательской истории. Все члены команды получают набор карт, каждая из которых соответствует одному из возможных значений оценки (например, 1, 2, 3, 5 и 8 баллов). После обсуждения истории каждый участник независимо от других выбирает карту, соответствующую его оценке истории в баллах. Затем все участники одновременно вскрывают свои карты. Если в предъявленных оценках наблюдается относительный консенсус, это говорит в пользу их большей точности. Если в оценках имеются существенные расхождения, обсуждение истории продолжается с целью приближения к согласию. При этом каждую историю часто разбивают на набор задач по кодированию. Это позволяет гарантировать, что при оценке трудозатрат были объективно учтены все известные факторы. Кроме того, оценить масштаб каждой из небольших задач обычно легче, чем всю историю целиком. Объем таких задач некоторые команды измеряют все также в баллах, другие предпочитают оценивать их в часах работы. Иногда разработчики не утруждают себя оценкой масштаба отдельных задач, ограничиваясь оценкой на уровне истории.
По завершении планирования спринта члены команды должны иметь четкое представление о наборе пользовательских историй, которые им предстоит реализовать в ходе итерации. Далее они берут из бэклога истории с наивысшим приоритетом, при этом общее количество отработанных за спринт баллов должно соответствовать ожидаемой скорости выполнения. Для тех команд, в которых разработчики имеют различные наборы навыков, полезно убедиться, что каждая история закреплена за конкретным разработчиком, чтобы обеспечить правильную балансировку нагрузки членов команды во время спринта.
В ходе выполнения спринта команда проводит ежедневные оперативные совещания, которые называют стендапами, из-за того что их обычно проводят «на ногах», чтобы сделать более короткими. Такие совещания проходят, как правило, по утрам и включают в себя обсуждение планов на предстоящий рабочий день. Обычно они занимают не более 15 минут. Каждый член команды кратко описывает, что он сделал накануне, что планирует сделать сегодня, а также указывает на имеющиеся для этого помехи.
Реализация пользовательских историй происходит, начиная с верхней части бэклога спринта. При этом члены команды взаимодействуют между собой по мере необходимости. Существует множество Scrum-инструментов, помогающих командам управлять своей работой и отслеживать результаты. Среди наиболее популярных из них: JIRA Agile, Rally, VersionOne и Pivotal Tracker. Все они облегчают планирование спринтов и бэклогов, а также общее управление процессом. Члены команды используют их, в том числе, для отслеживания хода реализации каждой пользовательской истории, например, путем присвоения ей различных статусов готовности: «для разработки», «в разработке», «кодирование выполнено», «готово».
В целях отслеживания прогресса команды часто используют график выполнения спринта, который показывает, какой объем
