Зачем использовать итерации в Scrum?

тл; ДР

На самом деле у вас есть два вопроса. Один касается временных рамок, а другой - оценки.

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

Инструменты и практики — не серебряные пули

[Инкрементальная разработка], кажется, не приносит достаточно пользы нашей команде.

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

1. Составление более детальных пользовательских историй.
2. Применение неявных ограничений незавершенного производства.
3. Повышение точности оценки.
4. Разработка предсказуемой каденции в рамках проекта.

Временные рамки: необходимы для Scrum

[H] Насколько ценно сохранять итерацию с временными рамками?

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

Длину тайм - боксов можно регулировать, но без них не обойтись. На самом деле продолжительность спринта — один из самых эффективных регуляторов проекта.

• Более короткие спринты...

  • ускорить цикл обратной связи.
  • увеличить нагрузку на процесс.
  • уменьшить неявные лимиты WIP.
  • уменьшить максимальный размер рабочей единицы.
  • сократить время цикла для рабочих единиц надлежащего размера.

• Более длинные спринты...

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

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

Тайм-боксинг и оценка работают рука об руку

[T] здесь никогда не было спринта, в котором мы успешно выполнили ВСЕ запланированные задачи. Мы всегда завершаем большинство из них, но в следующем спринте всегда остается несколько. Может быть, это как-то связано с тем, что только 2 человека участвуют в оценке [s.]

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

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

Возможные решения

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

1. Формальное заседание по планированию спринта, в котором участвует вся команда.
2. Планирование покера для поощрения незакрепленных оценок и быстрого обсуждения расхождений в оценках.
3. Ретроспективы спринта, на которых можно просмотреть оценки, чтобы выявить уроки, извлеченные из процесса оценки команды.
4. Поощрение коллективного владения или роения вместо того, чтобы назначать истории отдельным членам команды.

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

1. Настройка длины спринта до оптимального размера для вашей типичной пользовательской истории.
2. Пересмотр ваших ожиданий скорости в сторону понижения, когда цели обязательств не выполняются.
3. Ограничьте количество историй, принимаемых в каждом спринте, нижним пределом вашего прогнозируемого диапазона скоростей.
4. Работа с владельцем продукта над декомпозицией пользовательских историй, которые не укладываются в один спринт.

Смотрите также

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

Я думаю, вы должны спросить: «Почему команда недостаточно вовлечена, чтобы предоставить оценки?»

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

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

Мне кажется, вы смешиваете две вещи — приоритизацию задач, которые войдут в следующий спринт, и оценку задач. Заинтересованные стороны проекта должны расставлять приоритеты задач, а команда оценивает, сколько задач уместится в следующем спринте (обычно 1-2 недели). Спринты с ограничением по времени хороши для установления правильных ожиданий с клиентом и хороши для итераций развертывания (только готовый и протестированный код отправляется на промежуточное развертывание каждую неделю).

Если вы начинаете спринты по понедельникам, во вторник на предыдущей неделе договоритесь о встрече с заинтересованным лицом проекта (Клиентом), чтобы составить приоритетный список задач, которые необходимо выполнить на следующей неделе. Это может пройти не быстро, но, скажем, в среду клиент пришлет вам список. В четверг пригласите 3-4 квалифицированных разработчиков на сессию Planning Poker (не стоит водить всю команду на оценочную сессию). Оцените каждый пункт списка в Story Points. Разбивайте большие объекты на более мелкие. Посмотрите, сколько Story Points было выполнено ранее (предыдущие спринты), и сократите свой список задач примерно до того же размера Story Points. Если есть вопросы, уточните их у Заказчика и Разработчиков в пятницу. Отправьте шорт-лист клиенту по электронной почте, чтобы установить правильные ожидания. Начните работать над спринтом в понедельник — этот короткий список, скорее всего, будет закончен в спринте.

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

Итерации с ограничением по времени хороши для установления скорости. Это займет несколько итераций, но в какой-то момент вы сможете сказать, что команда может сделать, скажем, 15-20 баллов за недельную итерацию.

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

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

Недостаток: когда нет конкретных сроков, задачи часто занимают больше времени, чем должны.

Более конкретно: «Работа расширяется, чтобы заполнить время, доступное для ее завершения». -- Закон Паркинсона

Если это время бесконечно (нет крайнего срока), что ж... вы видите, к чему это ведет.

... насколько ценно сохранять итерацию с ограничением по времени?

По моему опыту, это довольно ценно.

Я не вижу, чтобы команда завершала все функции, даже если каждый вносил свой вклад в оценки.

Это совершенно отдельная проблема, которую вы можете отредактировать и отправить как отдельный вопрос.

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

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

Уже довольно давно мы не занимаемся планированием спринта или оценкой сюжетных баллов.

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

Для моей команды мы решили, что планирование спринта было выполнено по трем причинам:

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

Во- вторых, мы решили, что оценка (которую мы сделали в отдельном сеансе) ценна для нас опять же по трем причинам:

1. Чтобы сообщить историю команде и позволить команде задать вопрос ЗП.
2. Чтобы вызвать разговор о сложности и рисках, связанных с историей.
3. Чтобы гарантировать, что история не слишком велика, чтобы работать над ней в спринте.

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

Сессии невыполненных работ — это 30-минутный интервал каждый день (хотя он используется только «по мере необходимости»), когда Владелец Продукта знакомит команду с предстоящими историями. Затем мы обсуждаем их на высоком уровне, определяем, где нам может понадобиться всплеск или сессия технического проектирования для проработки, и решаем, имеет ли он такой размер, который мы готовы принять, или его нужно разбить (эмпирическое правило: думаем ли мы? мы можем сделать это в течение недели). Это заменяет пункты 4, 5 и 6.

Story Huddles — это происходит в начале истории, обычно между разработчиками, BA, QA и PO. Это возможность убедиться, что мы уловили критерии приемлемости, иметь представление о тестах, которые нам нужно написать, и мы можем разделить историю, если мы начинаем думать, что она слишком большая, чтобы делать ее как единое целое. Это заменяет пункты 2 и 3.

Время цикла как метрика. Вместо того, чтобы измерять скорость, мы просто измеряем, сколько времени требуется для завершения средней истории. Мониторинг этого с течением времени помогает нам определить, когда размер/сложность нашей истории увеличивается, а также дает информацию о расписании заказа на поставку (если у меня есть 5 вещей, которые я хочу сделать, и время цикла составляет 4 дня, я должен сделать их все за 20 дней). Это заменяет пункт 1.

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