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

Статья
06/10/2015

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

Январь 2012 г.

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

Применение

Application Lifecycle Management; Team Foundation Server

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

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

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

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

Сфокусируемся на планировании спринта.

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

Летом 2011 г. Кен Швабер (Ken Schwaber) и Джефф Сазерленд (Jeff Sutherland) отредактировали свое Руководство по Scrum. В новой версии они избавились от одной давно устоявшейся в Scrum практике, а именно обязательства, которое группа берет перед владельцем продукта и клиентами. На смену обязательствам пришли прогнозы. Они говорят, что группы могут прогнозировать свою работу, но не брать на себя обязательства по ней.

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

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

Представьте, что вы сказали бы жене или мужу: "Я прогнозирую, что мы будем вместе десять лет", а не "Я связываю с тобой свое будущее" — это точно ничем хорошим бы не закончилось.

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

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

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

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

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

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

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

Как этого добиться?

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

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

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

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

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

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

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

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

Так как у вас есть доступные ресурсы, перейдите к следующей историей и повторите шаги 1—5.

(Сведения о том, как это сделать с помощью Team Foundation Server, см. в статье Совместная работа [перенаправление].)

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

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

Один из способов превратить вопрос "Как заполнить стакан?" в цифры — рассмотреть рост размера в плане. Рост размера в плане показывает, как фактически затраченное время соотносится с исходными оценками. Допустим, например, что производительность группы — 200 часов. Группа делает обязательство на 190 часов на основе оценок. В конце спринта группа вычисляет, что для историй требовалось 240 часов фактической работы, что дает рост размера плана на 20 %.

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

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

Группе также следует учитывать рост размера плана во время собрания планирования спринта, когда группа определяет, может ли она взять на себя обязательство по истории. Вернемся к нашему примеру: если группа по-прежнему оценивает свою производительность как 200 часов, следует вычесть 20 %, чтобы скомпенсировать рост размера плана на основе прошлых данных. Другими словами, если для этого спринта группа оценивает необходимое время как 160 часов, ей следует заявить о том, что достигнута максимальная планка.

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

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

Распространенные проблемы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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