Это случается практически всегда, когда в ходе нашего планирования я задаю вопрос: “Итак, какова же цель спринта?”. Все начинают смотреть на меня удивлёнными глазами, а product owner – морщить лоб, почёсывая свой подбородок.
Почему-то сформулировать цель спринта бывает довольно непросто. Но я до сих пор убеждён, что усилия, потраченные на попытки сформулировать цель, оправдывают себя. Лучше паршивая цель, чем её отсутствие. Например, цели могут быть следующие: “заработать больше денег”, “завершить три истории с наивысшими приоритетами”, “удивить исполнительного директора”, “подготовить систему к бета-тестированию”, “добавить возможность администрирования” или что-нибудь в этом духе. Самое главное, чтобы цель была обозначена в терминах бизнеса, а не в технических терминах. То есть языком, понятным даже людям вне команды.
Цель спринта должна отвечать на главный вопрос “Зачем мы работаем над этим спринтом? Почему мы все просто не уйдём в отпуск?”. На самом деле, самый простой способ вытянуть цель спринта из product owner’a – напрямую задать ему этот вопрос.
Целью должно быть что-то, что не было ещё достигнуто. “Удивить исполнительного директора” может быть неплохой целью. Но только не в том случае, когда он и так в восторге от текущего состояния системы. В этом случае, все могут просто собраться и пойти домой, а цель спринта всё равно будет достигнута.
Цель спринта может показаться слегка глупой и надуманной на протяжении всего планирования. Но чаще всего, основная её ценность начинает проявляться к середине спринта, когда люди начинают забывать чего они хотят достичь в этом спринте. Если у вас работают несколько Scrum-команд (как у нас) над разными продуктами, очень полезно иметь возможность просмотреть список целей спринтов для всех команд на одной wiki-странице (или ещё где-нибудь), а также вывесить их на видном месте, чтобы все (а не только топ-менеджеры) знали, чем занимается компания и зачем!
суббота, 7 мая 2011 г.
Scrum - Определяем длину спринта.
Одна из основных задач планирования спринта – это определение даты демо. А это значит, что вам придётся определиться с длиной спринта.
Какая же длина оптимальна?
Короткие спринты – удобны. Они позволяют компании быть максимально “гибкой”, а значит готовой часто корректировать свои планы. Короткий спринт = короткий цикл обратной связи = частые релизы = быстрые отзывы от клиентов = меньше времени тратится на работу в неправильном направлении = быстрое обучение, совершенствование и т.д.
Но с другой стороны длинные спринты тоже хороши. У команды остаётся больше времени, чтобы набрать темп, больше пространства для манёвров, чтобы решить возникшие проблемы, а также больше времени для достижения цели спринта, а у вас меньше накладных расходов, таких как планирование спринта, демо и т.д.
В основном короткие спринты больше нравятся product owner’у, а длинные – разработчикам. Поэтому длина спринта – это всегда компромисс. Мы долго экспериментировали и выбрали нашу любимую длину: 3 недели. Большинство наших команд (но не все) используют трёхнедельный спринт. Достаточно короткий, чтобы предоставить адекватную корпоративную “гибкость”, но в тоже время достаточно длинный, для того чтобы команда смогла достигнуть максимальной производительности и успеть решить все вопросы, которые возникнут по ходу спринта.
Мы пришли к важному выводу: экспериментировать с длиной спринта нужно на начальном этапе. Не тратьте слишком много времени на анализ, просто выберите подходящую длину и используйте её на протяжении одного или двух спринтов, после чего можете выбрать новую.
Однако, как только вы найдёте подходящею длину, надолго зафиксируйте её. После нескольких месяцев экспериментов нам подошла длина в 3 недели, поэтому теперь мы следуем этому правилу и используем трёхнедельные спринты. Иногда спринт будет казаться слишком длинным, иногда – слишком коротким. Но сохранение фиксированной длины спринта позволяет выработать корпоративный ритм, в котором все чувствуют себя достаточно комфортно. К тому же исчезнут споры, насчёт даты релиза, так как все знают, что как ни крути, а выпуск новой версии продукта каждые 3 недели.
Какая же длина оптимальна?
Короткие спринты – удобны. Они позволяют компании быть максимально “гибкой”, а значит готовой часто корректировать свои планы. Короткий спринт = короткий цикл обратной связи = частые релизы = быстрые отзывы от клиентов = меньше времени тратится на работу в неправильном направлении = быстрое обучение, совершенствование и т.д.
Но с другой стороны длинные спринты тоже хороши. У команды остаётся больше времени, чтобы набрать темп, больше пространства для манёвров, чтобы решить возникшие проблемы, а также больше времени для достижения цели спринта, а у вас меньше накладных расходов, таких как планирование спринта, демо и т.д.
В основном короткие спринты больше нравятся product owner’у, а длинные – разработчикам. Поэтому длина спринта – это всегда компромисс. Мы долго экспериментировали и выбрали нашу любимую длину: 3 недели. Большинство наших команд (но не все) используют трёхнедельный спринт. Достаточно короткий, чтобы предоставить адекватную корпоративную “гибкость”, но в тоже время достаточно длинный, для того чтобы команда смогла достигнуть максимальной производительности и успеть решить все вопросы, которые возникнут по ходу спринта.
Мы пришли к важному выводу: экспериментировать с длиной спринта нужно на начальном этапе. Не тратьте слишком много времени на анализ, просто выберите подходящую длину и используйте её на протяжении одного или двух спринтов, после чего можете выбрать новую.
Однако, как только вы найдёте подходящею длину, надолго зафиксируйте её. После нескольких месяцев экспериментов нам подошла длина в 3 недели, поэтому теперь мы следуем этому правилу и используем трёхнедельные спринты. Иногда спринт будет казаться слишком длинным, иногда – слишком коротким. Но сохранение фиксированной длины спринта позволяет выработать корпоративный ритм, в котором все чувствуют себя достаточно комфортно. К тому же исчезнут споры, насчёт даты релиза, так как все знают, что как ни крути, а выпуск новой версии продукта каждые 3 недели.
Scrum - Распорядок встречи по планированию спринта
Наличие хотя бы примерного расписания значительно увеличит ваши шансы закончить планирование спринта в отведённое для этого время.
Например, наше расписание выглядит так:
Планирование спринта: с 13:00 до 17:00 (после каждого часа перерыв на 10 минут)
Например, наше расписание выглядит так:
Планирование спринта: с 13:00 до 17:00 (после каждого часа перерыв на 10 минут)
- 13:00 – 13:30. Product owner разъясняет цель спринта и рассказывает про бизнес-процессы из product backlog’а. Обсуждается время и место проведения демо.
- 13:30 – 15:00. Команда проводит оценку времени, которое потребуется на разработку бизнес-процессов и, при необходимости дробит их на более мелкие. В некоторых случаях product owner может изменить приоритет их исполнения. Выясняем все интересующие нас вопросы. Для наиболее важных заполняем поле «Как продемонстрировать».
- 15:00 – 16:00. Команда определяет набор user story, которые войдут в следующий спринт. Чтобы проверить насколько это реально, вычисляем производительность команды.
- 16:00 – 17:00. Договариваемся о времени и месте проведения ежедневного Scrum’а (если они изменились по сравнению с прошлым спринтом). После чего приступаем к разбиению user story на задачи.
Scrum - Планирование спринта, которое никак не заканчивается
Самая большая сложность при планировании спринта состоит в следующем:
В Scrum’е всё ограничено по времени. Мне очень нравится это простое правило, и мы всячески пытаемся его придерживаться.
Так что же мы делаем, когда ограниченное по времени планирование спринта близится к концу, а цель спринта или sprint backlog всё ещё не определены? Просто обрываем планирование? Продлеваем на час? Или, быть может, мы завершаем собрание и продолжаем его на следующий день?
Это случается снова и снова, особенно в новых командах. Как вы обычно решаете эту проблему? Я не знаю. А как решаем её мы? Ну, обычно, я бесцеремонно обрываю встречу. Заканчиваю её. Пусть спринт пострадает. Точнее, я говорю команде и product owner’у: «Итак, встреча заканчивается через 10 минут. Мы, до сих пор, полностью не спланировали спринт. Можем ли мы начать работать с тем, что у нас есть, или назначим ещё одно 4-х часовое планирование спринта на завтра в 8 утра?». Можете догадаться, что они отвечают… :o)
Я несколько раз давал возможность совещанию затянуться, но обычно это, ни к чему не приводило. Главная причина этому – усталость участников встречи. Если команда не выработала подходящий план спринта за 2 – 8 часов (зависит от конкретно ваших ограничений по времени), они, скорее всего, не управятся с ним и в дополнительное время. Второй вариант, по правде, достаточно хорош: назначить новую встречу на следующий день. За исключением того, что люди обычно нетерпеливы и хотят быстрее начать спринт, а не тратить ещё пару часов на планирование.
Итак, я урезаю продолжительность встречи. Да, спринт от этого страдает. Но с другой стороны, команда получила очень ценный урок, и следующее планирование спринта пройдёт более эффективно. Кроме того, когда вы в следующий раз предложите увеличить продолжительность встречи, люди будут возмущаться гораздо меньше.
Учитесь оставаться в рамках установленного времени, учитесь давать реалистичные оценки. Это касается как продолжительности встреч, так и продолжительности спринта.
- Люди не расчитывают, что это займёт так много времени
- … но так оно и происходит!
В Scrum’е всё ограничено по времени. Мне очень нравится это простое правило, и мы всячески пытаемся его придерживаться.
Так что же мы делаем, когда ограниченное по времени планирование спринта близится к концу, а цель спринта или sprint backlog всё ещё не определены? Просто обрываем планирование? Продлеваем на час? Или, быть может, мы завершаем собрание и продолжаем его на следующий день?
Это случается снова и снова, особенно в новых командах. Как вы обычно решаете эту проблему? Я не знаю. А как решаем её мы? Ну, обычно, я бесцеремонно обрываю встречу. Заканчиваю её. Пусть спринт пострадает. Точнее, я говорю команде и product owner’у: «Итак, встреча заканчивается через 10 минут. Мы, до сих пор, полностью не спланировали спринт. Можем ли мы начать работать с тем, что у нас есть, или назначим ещё одно 4-х часовое планирование спринта на завтра в 8 утра?». Можете догадаться, что они отвечают… :o)
Я несколько раз давал возможность совещанию затянуться, но обычно это, ни к чему не приводило. Главная причина этому – усталость участников встречи. Если команда не выработала подходящий план спринта за 2 – 8 часов (зависит от конкретно ваших ограничений по времени), они, скорее всего, не управятся с ним и в дополнительное время. Второй вариант, по правде, достаточно хорош: назначить новую встречу на следующий день. За исключением того, что люди обычно нетерпеливы и хотят быстрее начать спринт, а не тратить ещё пару часов на планирование.
Итак, я урезаю продолжительность встречи. Да, спринт от этого страдает. Но с другой стороны, команда получила очень ценный урок, и следующее планирование спринта пройдёт более эффективно. Кроме того, когда вы в следующий раз предложите увеличить продолжительность встречи, люди будут возмущаться гораздо меньше.
Учитесь оставаться в рамках установленного времени, учитесь давать реалистичные оценки. Это касается как продолжительности встреч, так и продолжительности спринта.
Подписаться на:
Сообщения (Atom)