Планирование спринта

Статья
02/20/2013

Автор Митч Лейси.Владелец, Mitch Lacey & Associates, Inc, консультационная фирма, специализирующаяся на принятии и усовершенствовании гибкого подхода и Scrum.

Январь 2012 г.

Планирование спринта не обязательно должно быть сложной задачей.Это часто весело и приятно для Scrum-команды устанавливать дух товарищества, совместной работая надо ответом на вопрос "Что мы можем сделать?" В этой статье авторы приводят примеры и описывают стратегии для поддержания эффективности планирования спринтов, а также описывают возможные решения распространенных проблем, возникающих при планировании спринта.

Применение

Управление жизненным циклом приложений; Team Foundation Server.

Содержание этой статьи

Введение
Прогнозирование против принятия обязательств
Что такое планирование спринта
Как мы достигаем этого?
Неполадки общего характера
- Сценарий: команда не может взять на себя обязательства по всем описаниям функциональности, которые запросил владелец продукта.
- Сценарий: владелец продукта приходит неподготовленным.
- Сценарий: часть 1 выходит за свои временные рамки.
- Сценарий: Часть 2 превышает его временные рамки.
- Сценарий: владелец продукта не может присутствовать.
- Сценарий: у команды нет необходимых ей критериев принятия.
- Сценарий: владелец продукта не знает, что означает готовая работа.
- Сценарий: координатор команды или владелец продукта оценивают оценки/работу команды и влияют на них.
Заключение

Мы не планируем.Мы делаем Scrum, поэтому просто исполняем.

Я постоянно это слышу.Люди думают, что Scrum и гибкая разработка означают никакого планирования, никаких оценок, никаких собраний, вообще ничего!Трудно представить себе что-то дальше от истины.Мы Планируем на различных уровнях в гибком проекте: ежедневный план или ежедневное рабочее совещание, еженедельные планы (спринт или итерация, невыполненная работа), план выпуска (невыполненная работа по продукту) и потенциально что-то еще.

Давайте сосредоточимся на планирование спринта.

Прогнозирование против принятия обязательств

Летом 2011 г. Кен Швабер и Джефф Сазерленд откорректировали свой Справочник по Scrum.При этом они удаляют одно давно известное Scrum поведение, являющееся обязательством, которое рабочая группа берет на себя перед владельцем продукции и клиентами.Обязательство было заменено прогнозом.Они говорят, что команды могут прогнозировать свою работу, однако не придерживаются этого.

Я понимаю их логику, однако предпочитаю обязательство по следующим причинам:

При обязательстве выполнять что-либо команда вынуждена мыслить иначе, чем при прогнозировании.Если команда делает прогноз, подразумевается, что невыполнение всех требований, о возможности выполнения которых они говорили, является приемлемым поведением.Хотя группы могут учиться на прогнозах, в итоге получая меньший разброс оценки, я нахожу, что команды, которые прогнозируют, дольше уменьшают разброс по сравнению с командами, которые берут на себя обязательства.
Прогнозирование или оценка подходит для невыполненной работы по продукту.Однако при перемещении командой описаний функциональности из списка невыполненной работы по продукту в список невыполненной работы спринта и разбиении их на меньшие части добавляется другой уровень детализации, выявляющий небольшие детали, которые позволяют им задать себе вопрос "можем ли мы направить свои усилия на это?. Прогнозирование попадает под риск возвращения в ленивое состояние, если команда вместо этого скажет "нам требуется лишь прогнозировать, все в порядке, если мы пропустим что-либо, мы сможем разобраться со всем этим позже".

Чтобы получить ясную картину, представьте, если бы вы сказали супруге, супругу или партнеру: «Я прогнозирую, что мы будем вместе 10 лет» или «Я обязуюсь быть с тобой» – это бы было неплохо.

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

Что такое планирование спринта

Мы созываем собрание по планированию спринта для планирования что команда будет построить в предстоящем спринте и как команда построит это.Хотя бы ссылаемся на него, как на собрание по планированию спринта, он фактически состоит из двух очень разных частей.Часть 1 посвящена тому, команду просят построить; на ней присутствуют и владелец продукта, и команда.Часть 2 посвящается тому, как команда планирует построить требуемую функциональность.Несмотря на то, что вся команда должна находиться в части 2, присутствие владельца продукта не обязательно.Если по какой-либо причине владелец продукта не присутствует на второй части, владелец продукта должен оставаться доступным для вопросов.

В первой части собрания по планированию спринта у владельца продукции имеется возможность описать нужный набор описаний функциональности рабочей группе.Это сеанс глубокого погружения в части описаний функциональности что.Владелец продукта представляет описания функциональности, показывает, как взаимодействуют компоненты, и проходится по интерфейсу.Кроме того, они могут просматривать инфраструктуру или элементы архитектуры.Цель — наполнить коллективный разум членов команды информацией, достаточной для того, чтобы они могли начать понимать, как создавать функциональность.Команда запросит различные вопросы для сбора сведений для собрания как. Такие вопросы:

«Каковы условия приемки всех этих описаний функциональности?»
«Какие источники данных, по вашему мнению, используется?»
«Как должен выглядеть интерфейс для данного компонента?»

Во время части 2 планировочного собрания спринта группа переносит свое внимание на построение списка невыполненной работы спринта — списка описаний и задач, которые необходимо выполнить во время спринта.Для построения Невыполненной работы, команда разбивает каждое описание функциональности, которое владелец продукта запросил, до уровня задач; каждая задаче получает почасовую оценку.В конце части 2, команда определяет, какие описания функциональности она может принять для выполнения во время спринта.

Совместно, две части планировочного собрания спринта могут занимать от двух до восьми часов.Общее правило, которым я пользуюсь, состоит в том, что каждая часть должна занимать час на каждую неделю продолжительности спринта.Это значит, что если длительность спринтов у меня составляет неделю, собрание займет в сумме два часа (один час на часть 1 и один час на часть 2).Если, с другой стороны, разбить работу на набольшие части, выполняемые в течение 4 недель, общая продолжительность собрания составит 8 часов (4 часа на первую часть и 4 часа на вторую часть).

Как мы достигаем этого?

Если команда оставляет собрание по планированию спринта привязанным к выполнению списка описаний функциональности, команда выполнила цель планирования спринта.Однако достижение командой точки, в которой каждый член команды будет чувствовать себя комфортно, выполняя эти обязательства , требует некоторого предварительного планирования и содействия.

На владельца продукта во время планирования спринта возлагается одна задача: приходить на собрания, будучи способным изложить набор описаний требуемой функциональности.Цель команды — понять описания функциональности с точки зрения владельца продукта, усвоить видение владельца продукта.Координатор Scrum должен убедиться, что команда запрашивает достаточно вопросов и записывает все результирующие данные, включая условия приемки, эскизы и любые предположения.Координатор Scrum должен также дать владельцу продукта знать, что команда может иметь дополнительные вопросы после того, как он начнет разбивать вопросы на задачи.Хотя владелец продукта представляет описания функциональности, суммы баллов по которым приблизительно соответствуют первоначальной скорости группы, команда в конечном счете решит, может ли она, в действительности, принять все описания функциональности в заданном спринте на основе того, что она узнает во время частей 1 и 2 на собрании по планированию спринта.

После того как команда получала все данные от владельца продукта, она должна разбить описания функциональности по задачам и создать список невыполненных работ по спринту, который включает все описания функциональности, примечания, условия приемки, задачи и оценки для указанного спринта.Существует много способов сделать это, я использую следующий метод, который использует преимущества идей всех участников команды и предоставляет каждому голос в декомпозиции задач.

Пусть координатор команды или координатор собрания считает функциональное описание и спросит "Все ли его поняли?". Команда должна понять, поскольку она только что потратила время на его обсуждение с владельцем продукта.Если кто-либо в команде не понимает, потратьте некоторое время на возвращение к описанию, задавая любые необходимые вопросы владельца продукта.
Далее, пусть каждый член команды возьмет пачку стикеров.Попросите, чтобы каждый участник команды написал одну задачу на каждой наклейке и бросил ее в середину стола.
- Так как каждая наклейка бросается в середину стола, распределитель объявляет задачу.Если написано "обновить сохраненную процедуру", это же произносится вслух.Это важно, поскольку оно будет создавать идеи и заставлять других говорить, "О да, и нам нужно обновить источник данных". В этот момент кто-нибудь напишет на бумажке "обновить источник данных" и наклеит ее в середину.Это действие мозгового штурма фактически вычищает все связанные задачи.В данный момент можно не беспокоиться о дубликатах.Наклеивание всех бумажек задач обычно требует около 5 —10 минут на описание функциональности.
Когда все наклейка на столе, пора сортировать их.Наклейте их все на стену, отойдите и посмотрите — сколько стикеров получилось!Начните с выявления дубликатов; наклеивайте друг на друга все стикеры, которые кажутся дубликатами.Затем поищите задачи, которые как бы сочетаются, либо потому, что они похожи, либо потому, что зависят друг от друга.Например, если у двух наклеек схожее отношение, поместите их вместе, но сместите их, как показано на следующей иллюстрации:

Если две задачи настолько тесно связаны, что они почти идентичны, наложите их друг на друга практически полностью, как показано ниже:

При сортировке наклеек команда может отбраковать список задач и визуализировать отношения между оставшимися.
Если задачи отсортированы, пора оценивать.Я использую метод планирования покера для оценки задач с единственным отличием: числа на картах представляют часы вместо баллов.Я делаю это, поскольку люди склонны уделять слишком большое внимание ненужным деталям, относящимся к часам, особенно в больших задачах.Есть Серьезное основание для их опасений.Слишком часто, компании использует оценку как палку, чтобы погонять команду.«Вы сказали, что это займет 8 часов, а это заняло 12.Что неправильно?» или «вы сказали, что оно займет 8 часов, а оно заняло только 4.Вы заполняете свои оценки".

Так же как карты помогают поддерживать абстрактность оценок точек описаний, использование карт для оценки задач обеспечивает свободу выбора из фиксированных чисел. При этом в результате гарантированно придется делать выбор.Он также исключает горячие споры об оценке задачи - 6 часов, 6,5 часов или 7 часов.

Какова бы ни была окончательная оценка, запомните, что оценка производится командой, и предназначено для использования командой, только, чтобы помочь повысить ее уверенность и определить, может ли она выполнить работу, которую владелец продукта попросил, исходя из скорости.Оценки задач — это не показатели и не должны использоваться в качестве таковых.Никогда не используйте оценки как оружие, направленное против команды.
Теперь, когда задачи оценены, команда должна определить, может ли она взять еще работу.Чтобы сделать это, необходимо знать мощность команды, всего часов, которые имеет команда в течение спринта.Определение производительности будет легким при наличии полностью вовлеченной команды, но усложнится, если команда состоит из лиц с частичной занятостью, которые распределяются на несколько проектов.Попросите, чтобы каждый написал число часов, в течение которых он сможет работать над проектом в день (или всего за спринт).Сложите все числа, чтобы получить общее количество часов, доступных для команды.Предположим, емкость команды - 200 часов.Если при оценке суммы задач по описанию функциональности прогнозируется, что на это уйдет 30 часов, спросите команду: "Можем ли мы взять больше работы?". На этом раннем этапе очевидным ответом будет "да".

Поскольку необходимо заполнить больше производительности, перейдите к следующему описанию функциональности и повторите шаги от первого до пятого.

(Дополнительные сведения о том, как выполнять эту задачу с помощью Team Foundation Server см. в разделе Гибкое планирование и итерации).

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

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

Одним из способов перевести вопрос "сколько наливать" в числовую плоскость является учет увеличения размера плана.Для измерения увеличения размера плана фактические затраченные часы сравниваются с первоначальными оценками.Предположим, например, что наша команда имеет доступных емкость 200 часов.Команда берет обязательство на предположительно 190 часов, на основе оценок.В конце спринта команда вычисляет, что эти описания содержали 240 фактических рабочих часов, что привело в результате к увеличению размера плана на 20 %.

Команда, которая находит это расхождение, должна потратить некоторое время во время ретроспективы, расследуя причины:

Слишком много задач открываются во время выполнения, которые не были указаны во время планирования?
Команда недооценивает свои задачи в соответствии с текущим набором навыков?
Команда переоценила свою производительность?
и т. д.

Команда должна также рассмотреть плановый рост размера во время следующего собрания по планированию спринта, когда определяют, могут ли они взять обязательство по описанию функциональности.Возвращаясь к нашему примеру, если команда все еще оценивает объем 200 часов, команде следует вычесть 20%, чтобы компенсировать "ожидаемый" рост размера плана на основании прежних данных.Иначе говоря (хотя бы для этого спринта) во избежание утечек когда рабочая группа нарабатывает 160 часов, она должна объявить себя работающей на полную мощность.

Рассмотрение увеличения размера плана — один из способов определения того, насколько полным должен быть спринт.Помните, однако, что цель не должна в точности соответствовать возможностям.Скорее цель состоит в том, чтобы команда чувствовала себя уверенно, беря на себя обязательства по соответствующему количеству описаний функциональности — количеству, которое "подгоняет" команду, но не перегружает ее.Увеличение размера плана — не более чем способ приблизительно определить необходимое наполнение следующего спринта, если все остальные факторы остаются равными.

Когда все описания функциональности оценены или все время употреблено описаниями функциональности, вернитесь к владельцу продукта и сообщите Задел работы спринта, который обещает выполнить команда.Спринт начинается сейчас — приступайте к работе!

Неполадки общего характера

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

Сценарий: команда не может взять на себя обязательства по всем описаниям функциональности, которые запросил владелец продукта.

Следует ожидать, что это периодически будет происходить.Пока команда может создать резервную копию задачи с данными из шагов 4 и 5 выше в этом разделе, владелец продукта должен быть доволен.Необходимо послеживать, чтобы убедиться, что это невзятие на себя обязательств не является результатом переполнения или крупных задач.Координатор Scrum должен подробно рассматривать оценки, которые кажутся слишком консервативными, чтобы убедиться, что они точны.Владелец продукта должен подвергнуть сомнению любую задачу с двузначной оценкой.Любая задача, которая по расчетам требует больше времени, чем 2 рабочих дня, должна быть разделена на более мелкие задачи и переоценена.Это справедливо для всех проектов, но особенно трудно для команд, выполняющих однонедельные или двухнедельные спринты.

Сценарий: владелец продукта приходит неподготовленным.

Одной из ценностей Scrum является уважение.Невежливо приходить на собрание неподготовленным.Итак, что должна делать команда, если владелец продукта приходит без информации, которая нужна команде?Хотя одним вариантом является отложить собрание до тех пор, пока владелец продукта не будет готов, это вызывает такое же поведение— избегайте этого.Другим вариантом является отмена спринта.Хотя это может сработать, это крайний случай.

Я считаю, что лучшее решение будет двояким.Во-первых, список невыполненных работ по продукту должен быть как-либо упорядочен по приоритету, чтобы в случае отсутствия у владельца продукта определенного набора описаний функциональности команда и владелец продукта могли просто обсудить описания функциональности в порядке приоритета, пока они не достигнут точки, в которой по их мнению они обеспечат производительность или превысят ее.Команда может затем принять решение о точном обязательстве во время части 2 собрания, как обычно.

После собрания Координатор команды должен работать, чтобы понять, почему владелец продукта не был подготовлен.Если проблема заключалась в недостаточной вовлеченности, координатор Scrum может указать владельцу продукта на важность прихода на собрание подготовленным и с набором описаний функциональности.С другой стороны, если проблема в том, что владелец продукта не смог подготовиться (допустим, рабочая группа не оказала помощи), ScrumMaster также должен помочь в разрешении этих проблем.

Сценарий: часть 1 выходит за свои временные рамки.

Другое значение – фокус.Если часть 1 собрания затягивается, это является признаком недостаточной концентрации.Иногда владельцу продукта не хватает фокуса из-за недостаточной подготовки или приоритизации либо попытки пояснить слишком большое количество описаний функциональности.В других случаях нехватка фокуса может быть связана с тем, что команда переводит обсуждение вопроса "что" на специфику — "как".

Координатор Scrum должен помочь двигаться, настаивая, что владелец продукта нарисовал все описания функциональности, которые не могут быть полностью объяснены, и чтобы команда записала подробные обсуждения реализации из части 1.Одним из простых способов избежать неконкретного обсуждения является использование секундомера или таймера.

Сценарий: Часть 2 превышает его временные рамки.

Снова, фокус.Если участники рабочей группы склонны говорить слишком много, ограничение продолжительности обсуждения — это все, что требуется, чтобы вернуть совещание на нужные рельсы.Принесите песочные часы и сохраните диалоги на минуту или две между оценками задач.Целью является точность, но не 100-процентная точность.

В других случаях нехватка фокуса во время части 2 является симптомом недостаточной чистки невыполненной работы во время выполнения спринта.Очистка — это время, когда команда может взглянуть на будущие описания функциональности и поработать с владельцем продукта для добавления описаний функциональности или пиков для утверждения направлений конструирования или рассмотрения вопросов архитектуры.Без регулярной чистки невыполненной работа по продукту, планирование невыполненная работа по спринту будет неудобным и тягостным.

Сценарий: владелец продукта не может присутствовать.

Если владелец продукта не может присутствовать на собрании по какой-либо причине и не назначил представителя, действуйте так, как будто владелец продукта пришел на собрание неподготовленным.Проработайте верхние элементы и берите за них максимальные обязательства.Может быть соблазн изменить время собрания, чтобы оно подходило под расписание владельца продукта.Не рекомендуется.Перенос собрания — это удовлетворение потребности одного человека за счет других.Не стоит того.

Сценарий: у команды нет необходимых ей критериев принятия.

I всегда советую командам задавать владельцу продукта во время первой части вопрос: "Каковы условия приемки для этого?" или "Что нам необходимо сделать, чтобы вы приняли работу?". Если этого нет во второй части, когда команда определяет задачи, у команды не будет ни малейшего понятия о том, как довести описание функциональности до закрытия.Если команде приходится делать догадки на основании того, что она слышала в части 1, команда подвергается риску того, что владелец продукта решит в конце спринта, что описание не завершено.Запрашивайте условия приемки в начале для каждого описания функциональности.Координаторы Scrum должны учить своих владельцев продуктов предоставлять эти данные.

Сценарий: владелец продукта не знает, что означает готовая работа.

Как команда стремится получить условия приемки, владелец продукта хочет актуальное описание того, что команда подразумевает под словами "описание функциональности готово". Список готовых частей должен регулярно обновляться и быть доступен владельцу продукта в любое время.Устаревшей список выполненной работы усложняет планирование, так как нет общего понимания того, как должна выглядеть выполненная работа.Будьте уверены, что обновление списка готовой работы является частью каждого пересмотра или ретроспективы спринта.

Сценарий: координатор команды или владелец продукта оценивают оценки/работу команды и влияют на них.

Владелец продукта может присутствовать на части 2 собрания, однако его роль в части 2 должна быть ограничена разъяснениями требований или ответами на конкретные вопросы.Владелец продукта ни в коем случае не должен вмешиваться в обсуждение командой того, как реализовывать описание, и не имеет права голоса при оценке задачи.Эту работу владелец продукта должен доверить команде.

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

Планирование спринта не обязательно должно быть сложной задачей.Это часто весело и приятно для Scrum-команды устанавливать дух товарищества, совместной работая надо ответом на вопрос "Что мы можем сделать?" Помните, если оказывается, что совещания проходят очень долго, это, скорее всего, связано с проблемами основной причины.Если вы являетесь координатором Scrum, обеспечивайте концентрацию внимания на собрании, следя за тем, чтобы владелец продукта и команда приводили в порядок список невыполненных работ по продукту.Помогите владельцу продукта подготовиться, разработав условия приемки описания функциональности до готовности перед собранием.Наконец, помогайте удержать внимание владельца продукта и команды на рассматриваемой задаче, определяя, что они могут посвятить спринту.