Что такое Спринт в Скраме — Справочник Unusual Concepts
Спринт — это отрезок времени, за который Скрам-команда создаёт часть Продукта, готовую к показу и ценную для клиента. Каждый Спринт — это мини-проект, который состоит из цели, плана по её достижению, работы и конечного Продукта. Если сравнивать разработку со съёмками сериала, то съёмка одной серии — это Спринт.
Разработка Спринтами:
- делает Продукт и бизнес гибкими. Вы можете изменять Продукт в каждом цикле и вовремя подстраиваться под желания покупателей и условия рынка.
- сохраняет рабочий настрой Команды. Все сотрудники понимают, на каком этапе работы находится Команда и что будет дальше. Все необходимые мероприятия прописаны и ограничены по времени. Нет неразберихи, есть разумная организация рабочего процесса.
- ускоряет достижение желаемого результата. В Спринте помимо Команды участвуют люди, которые принимают решения по Продукту. Команде не нужно ждать, пока их действия будут согласованы с руководством.
В Руководстве по Скраму написано, что Спринт не может быть короче одной недели и длиннее одного месяца. Такое ограничение задаёт временные рамки, достаточные для создания готового Продукта и безопасные для компании в случае, если он окажется невостребованным. По опыту наших тренеров оптимальная длина Спринта — 1–2 недели.
Каждый Спринт состоит из пяти последовательных мероприятий: Планирования Спринта, Ежедневного Скрама, разработки, Обзора Спринта и Ретроспективы Спринта. Все пять событий обязательны к исполнению и ограничены по времени.
Планирование Спринта
Планирование Спринта — это встреча, на которой Скрам-команда выбирает Цель Спринта и обсуждает конкретные шаги для её достижения.
Сколько длится: до восьми часов при длине Спринта один месяц.
Кто участвует: Владелец Продукта, Скрам-мастер, Команда Разработки.
Зачем нужно: определяет, какие цели будут достигнуты в Спринте.
Результат: Команда сформулировала Цель Спринта, составила Бэклог Спринта, обсудила и взяла в работу несколько пунктов из Бэклога Продукта.
В Болливуде снимают сериал. Перед съёмкой очередной серии режиссёр и съёмочная команда обсуждают предстоящую работу. Режиссёр хочет снять сцену во дворце махаражди с массовыми танцами и слонами. Команда прикидывает время на подготовку декораций и обучение массовки и говорит, что не успеет. В итоге от слонов и массовки отказались. Главная героиня будет танцевать одна в фойе отеля, который очень похож на дворец. Команда записала, что нужно сделать, чтобы это устроить.
Ежедневный Скрам
Ежедневный Скрам — это 15-минутные встречи, на которых Команда Разработки оценивает, как продвигается работа и синхронизирует планы на ближайшие 24 часа.
Сколько длится: 15 минут.
Кто участвует: Команда Разработки. Скрам-мастер может присутствовать, но не вмешивается в обсуждение.
Зачем нужен: синхронизироваться, оценить прогресс в работе, выявить проблемы.
Результат: Каждый член Команды понимает, как движется Команда к Цели Спринта и какой вклад в достижение общей цели он сделает сегодня.
На восходе солнца съёмочная команда обсуждает предстоящий день. Раджеш договорился о съёмках в отеле, Шанти — о транспорте. Костюмер Зита сообщила, что не хватает танцевального костюма для главной героини. Проговорили план на сегодня: найти, где арендовать костюм, подготовить съёмочную площадку, провести кастинг актёров для эпизодических ролей.
Разработка
Разработкой называют процесс работы Команды Разработки в течение одного Спринта.
Сколько длится: от 5 до 20 дней в зависимости от длины Спринта.
Кто участвует: Владелец Продукта, Скрам-мастер, Команда Разработки.
Зачем нужна: Во время разработки Команда создаёт или улучшает Продукт.
Результат: Инкремент Продукта — новая часть Продукта, готовая к показу и ценная для клиента.
На съёмку одной серии уходит неделя. Целую неделю съёмочная команда меняет локации, репетирует танцы, дорабатывает сценарий, снимает, отсматривает и монтирует. В понедельник новая серия выходит в эфир.
Обзор Спринта
Это неформальная встреча, на которой заинтересованным лицам показывают Инкремент Продукта. Все могут его потрогать, проверить, посмотреть, обсудить, чего в нём не хватает, что можно изменить или добавить.
Сколько длится: до четырех часов при месячной длительности Спринта.
Кто участвует: Владелец Продукта, Скрам-мастер, Команда Разработки, стейкхолдеры, пользователи, члены других команд компании.
Результат: Владелец Продукта обновил Бэклог Продукта, собрал обратную связь, Команда сдала работу и готова творить дальше.
Перед выходом на телевидение команда показывает новую серию в студии. Члены команды приглашают свои семьи, приезжает спонсор сериала — богач Салим. После просмотра все обсуждают новую серию и злоключения главной героини за чашечкой чая со сладостями.
Ретроспектива Спринта
Команда обсуждает процесс работы, взаимодействие между членами Команды, инструменты и фокусируется на улучшениях процесса.
Сколько длится: до трёх часов при месячной длительности Спринта.
Кто участвует: Скрам-мастер, Команда Разработки, Владелец Продукта.
Зачем нужна: чтобы постоянно улучшать процесс работы Команды.
Результат: Команда обсудила, что мешает работе, составила план, как устранить проблемы.
После просмотра и обсуждения серии съёмочная команда собралась на террасе, чтобы обсудить, как прошла неделя и решить назревший конфликт между актёрами и костюмерами. Актёрам не нравятся старые костюмы, а костюмеры говорят, что не успевают шить новые. Решили перестать шить костюмы самим, а брать в аренду. На следующей Ретроспективе обсудят результаты этого решения.
Последовательное прохождение всех пяти событий Спринта позволяет работать эффективно и постоянно улучшать Продукт и процесс в зависимости от желаний клиентов и развития технологий.
Полезно сохранять неизменной продолжительность Спринта на протяжении всего процесса разработки, чтобы участники привыкли к определённому темпу работы. Новый Спринт начинается сразу после окончания предыдущего.
В чрезвычайных обстоятельствах Владелец Продукта может отменить Спринт. Например, если идею реализовала другая компания или руководство перепродало компанию тому, кто по Скраму работать не хочет. Отмена — это неприятное событие, которое травмирует всю Команду и сводит на нет большую работу. Используйте её только в крайнем случае.
Как организовать идеальный дизайн-спринт? — Академия Яндекса
Команды используют дизайн-спринты по разным причинам: это может быть запуск нового проекта, необходимость добиться многого в сжатые сроки, найти выход из тупика в работе над продуктом или использовать новые данные исследований. В основе идеи и методологии дизайн-спринта лежит анализ пользовательского поведения и испытание прототипов на аудитории для решения сложных проблем. С момента появления дизайн-спринтов команды по всему миру много раз изменяли и расширяли первоначальную концепцию, подстраивая ее под свои задачи. В своей статье веб-продюсер сервиса Figma Андреа Хельмбольт рассказывает о том, как провести спринт действительно эффективно.
Что такое дизайн-спринт
Дизайн-спринт — это проверенная методология для решения проблем с помощью создания прототипов и исследования пользовательского поведения. Спринт рассчитывается на определенный период, обычно на пять рабочих дней, так что команды должны быстро скоординировать свою работу в рамках общего видения целей и результатов. Он состоит из шести этапов:
- знакомство с проблемой
- определение целей
- скетч
- решение
- прототип
- проверка
Методология дизайн-спринта
В её основе лежат подходы из пользовательского опыта, процессы, используемые в Google, IDEO и Stanford d.school, а также бизнес-стратегии и психология. Гибкий современный фреймворк спринтов позволяет командам в любой организации адаптировать их под свои потребности.
Спланируйте дизайн-спринт
Подготовка к дизайн-спринту важна не меньше, чем сам процесс. Не думайте, что успеете всё сделать за один день. На каждый день спринта нужно заранее выделить день на подготовку. Правильное планирование гарантирует, что вы получите максимальную отдачу на каждом этапе.
Составьте бриф
Бриф будет служить ориентиром для команды на протяжении всего процесса. В нём должны быть перечислены поставленные цели (проблемы, которые вы хотите решить), желаемые результаты, план действий и методы. Он также должен представить команде информацию о проекте и обо всех исследованиях пользовательского поведения, которые уже доступны. Не нужно, чтобы команда тратила время на поиск ответов, которые у вас уже есть, поэтому обязательно включите все необходимые детали в бриф спринта.
Дизайн-спринт предназначен для поэтапного решения задач, и это должно быть четко отражено в брифе. Привяжите спринт к одному ясному вопросу и ответу на него. Например, вместо цели «сделать нашу домашнюю страницу более удобной для покупателей» лучше написать «изменить путь пользователя для увеличения конверсии».
Соберите команду
Разбивайте большие группы людей на небольшие команды, которые будут работать над одной и той же проблемой. Таким образом, у вас будет больше идей и версий прототипа.
Каждая команда должна включать людей, ответственных за выполнение работ после спринта. В команды обычно входят UX-дизайнер, исследователь пользовательского поведения, менеджер продукта, разработчик и ключевые руководители.
Создайте план действий
Самый простой способ составить план действий на день — следовать шести этапам методологии, но в зависимости от ваших потребностей могут понадобиться некоторые изменения. Команда по дизайн-спринту может уже хорошо разбираться в контексте и в проблеме, над которой вы работаете, поэтому можно меньше времени уделить этапу знакомства с проблемой и, возможно, перераспределить больше времени на прототипирование.
Создайте визуальные концепции
Будете ли вы делать бриф его в виде карточек или любым другим способом, убедитесь, что у вас перед глазами всегда будут нужные референсы. Сюда входят скриншоты текущих веб-сайтов, источники вдохновения, данные, результаты исследований и всё остальное, что может понадобиться команде или на что можно будет сослаться в течение спринта.
Соберите данные о пользовательском поведении
Тщательное изучение пользователей — это то, на что команда дизайн-спринта будет опираться при создании прототипа. Без понимания желаний пользователей процесс может быстро сойти с рельсов. Исследование перед спринтом поможет в поиске новых идей, а сбор существующих данных поможет выявить, как люди сейчас пользуются продуктом и какие возможные изменения потребуется внести, чтобы сформировать нужное поведение.
Подключите ключевых экспертов
В дополнение к собранным данным вы можете подключить ключевых специалистов и привлечь внешних экспертов, которые смогут поделиться свежим взглядом на проблему, над которой работает команда. Они могут представить блиц-доклады — короткие презентации на 10–15 минут. Полезными темами презентаций могут стать результаты исследований клиентов, проведенных сотрудником службы поддержки, анализ конкурентов, выполненный аналитиком, а также обзор производительности, сделанный менеджером продукта.
Забронируйте идеальное место
Дизайн-спринт основан на креативности, и место его проведения должно вдохновлять участников. Найдите светлое помещение, в котором вы будете чувствовать себя комфортно. Может потребоваться передвинуть какую-то мебель или доски, на которых вы будете писать. Не обязательно сидеть только там. Можно сменить обстановку, сходить в кафе или в ближайший парк.
Подготовьте тему для начала разговора
Разговор для снятия напряжения, проведенный в самом начале, поможет растопить лед, познакомить всех друг с другом и дать толчок творческому мышлению.
Подготовьте материалы для работы
Подготовьте всё необходимое еще до начала спринта. Будет жалко, если потрясающая идея пропадет из-за того, что у кого-то не оказалось ручки. Начните со списка ниже и добавьте в него то, что поможет поддержать ваш уникальный дизайн-спринт:
- 1 маркер на человека (плюс еще несколько)
- 1 набор стикеров на человека
- 1 ручка для рисования на человека
- 10 листов бумаги на человека
- 1 скотч
- 1 ножницы
- 2 доски или поверхность для наклеивания стикеров
- 1 комплект цветных маркеров для доски
Определите ваши ожидания
За несколько дней до начала дизайн-спринта подготовьте участников и определите ваши ожидания. Удостоверьтесь, что люди, принявшие приглашение, действительно придут на спринт. Процесс будет неэффективным, если кто-то будет то приходить, то уходить. Поделитесь со всеми планом действий и расписанием, а также другими требованиями (вроде требования выключить телефоны).
Проводим дизайн-спринт
Рассмотрим каждый этап традиционной методологии спринтов.
Этап 1: Знакомство с проблемой
На этом этапе все участники спринта создают общую базу знаний. Эта база основана на брифе, блиц-докладах, опросах пользователей и упражнениях вроде «карт опыта» (где команда шаг за шагом описывает опыт пользователя в контексте проблемы) или методики «Как мы можем помочь» (How Might We, когда команда превращает болевые точки в возможности).
Этап 2: Определение целей
Теперь команда использует всё, что она узнала, для того, чтобы сфокусироваться на задаче спринта. Члены команды также определяют свои цели, метрики успеха и сигналы того, что-то идет не так. Одна из популярных методик этапа определения называется Золотой путь (The Golden Path), она требует от участников перечислить возможные истории пользователей, если продукт уже существует, а если его пока нет — очертить идеальный путь пользователя в новом продукте.
Этап 3: Скетч
На этом этапе каждая команда (если их больше одной) индивидуально генерирует как можно больше идей. Затем команды сужают количество вариантов до одного расширенного скетч-решения (Solution Sketch) на каждого человека. Есть популярное упражнение Crazy 8: человеку надо набросать восемь разных идей за восемь минут. Вы можете перенести эти действия в цифровой формат и наблюдать, какие идеи появляются у участников. Это также может пригодиться, если некоторые члены команды участвуют в дизайн-спринте удаленно.
Этап 4: Решение
Этап принятия решения подталкивает команду утвердить окончательное направление движения, решение, которое она будет реализовывать на оставшихся этапах дизайн-спринта. Точечное голосование (Dot Vote) — простое упражнение для быстрого принятия решений. Каждый получает три минуты на презентацию своего скетч-решения, а вся остальная команда может задавать вопросы. Затем все скетчи вешают на стену, каждый член команды получает по три круглых стикера (то есть три голоса) и может отметить ими те скетчи, которые ему понравились. Скетч с наибольшим количеством голосов становится рабочей гипотезой на спринте.
Этап 5: Прототип
На этапе прототипирования команда дизайн-спринта работает над созданием прототипа, следуя выбранной концепции. Полный прототип продукта занимает много времени, но мы сосредотачиваемся на скорости и такой детализации, чтобы можно было получить обратную связь от конечного пользователя. Обычно сюда входит карта точного пути пользователя, и она включает в себя только те шаги, которые вы хотите протестировать.
Этап 6: Проверка
На заключительном этапе команда дизайн-спринта будет использовать свой прототип для исследования пользовательского поведения. Очень важно включить сюда получение обратной связи от пользователей и других заинтересованных сторон, а также анализ технической осуществимости. В результате дизайн-спринта у вас будет либо готовая концепция, которая прошла проверку, либо концепция, которая пока проверку не прошла и нуждается в усовершенствовании. Проверка заключается в том, чтобы предоставить прототип пользователям, но существует несколько подходов к этому.
Дизайн-спринт — это начало большого проекта, поэтому с самого начала должно быть ясно, какие шаги предстоят после окончания спринта. Менеджеры проектов или продуктов должны предоставить членам команды, ответственным за доведение проекта до конца, набор четких действий. Во время спринта обязательно ведите подробные заметки и фотографируйте работу команды, чтобы потом вы могли предоставить всем желающим полное описание процесса.
Дизайн-спринты — это тяжелая работа. Отпразднуйте завершение спринта, чтобы помочь команде расслабиться после нескольких дней напряженных усилий.
Scrum — реальный опыт работы по методологии / Unicloud Business 365 corporate blog / Habr
В данной статье я привожу обзор организации процесса создания программного обеспечения в команде, в которой работаю. Моя цель – это поделиться опытом разработки и управления командой разработчиков.Для организации процесса работ над проектом мы решили выбрать популярную методологию Scrum. Отчасти это дань моде, отчасти большое количество публикаций в сети Интернет на тему «Scrum сделал за нас все!».
Какие роли есть в Scrum
Что такое спринт и зачем он нужен
ProductOwner сформулировал свою цель в виде некого пункта B, который нужно достичь, начав движение с пункта A. Но пункт B – это не точка, в которую можно попасть, просто нарисовав прямую линию между ней и пунктом А. На самом деле пункт B это окрестность точки, и радиус ее может варьироваться.
Чтобы попасть в эту окрестность, лучше всего разрабатывать ПО короткими шагами (точнее забегами): спринтами. В конце спринта все оценивают, что получается, и корректируют направление движения. ProductOwner всегда в курсе того, что его идеи правильно поняты (а если нет, то это можно скорректировать уже на следующем спринте), и спокоен. Команда знает, что делает то, что нужно, и удовлетворена своей работой.
Как формируется список задач на спринт
В команде спринт длится 2 недели. За неделю ничего не успевается, за месяц все забывается. Поэтому 2 недели для нас самый оптимальный вариант. Первый день спринта уходит на планирование. На ранних этапах на планирование уходило даже 2 дня. Планирование – это процесс, при котором команда берет из списка требований наиболее приоритетные и разбивает на задачи, которые позволяют достичь результата. Каждая задача оценивается в часах. Желательно, чтобы задача не занимала времени больше, чем 4 часа. Если участник команды говорит, что сделает задачу за 5 дней, значит, он понятия не имеет, что нужно сделать.
Как проверить, что требование ProductOwner’а выполнено
Есть список требований. Но как проверить, достигнуто это требование в ходе разработки или нет? Для этого необходимо написать тесты, в которых будет детально описано то, что считать достижением требования. Просто говоря, в них описано то, на какую кнопку нажать, и что при этом получится. В команде тесты пишут аналитики. И тесты эти должны быть готовы к моменту запуска очередного спринта. У нас в команде аналитики и дизайнеры работают с опережением команды разработчиков на 1 спринт.
Главное требование – тесты должны быть очень подробными.
Что происходит во время спринта
Начинается процесс исполнения спринта. Главная его цель – добиться, чтобы тесты, предъявляемые к требованиям, к концу спринта выполнялись.
Для сплоченного движения команды к цели Scrum предлагает делать ежедневные митинги. Митинг – это когда каждый, стоя у доски с маркером, вычеркивает то, что он сделал вчера и пишет то, что он собирается сделать сегодня.
Это очень мощная практика. Благодаря ей каждый знает, куда движется проект в целом. К тому же когда человек, рассказывает, что он будет делать сегодня, то он автоматически координирует свои действия с другими участниками. Другие участники могут тут же предложить лучшие решения задачи. А еще написанная на доске задача, а по сути — это обещание всем своим коллегам, очень хорошо мотивирует самого исполнителя. Единственное, ScrumMaster не должен забывать объявлять, что начался митинг.
Митинги проводить желательно стоя и длительностью не более 15 минут. Мы начинаем митинги в 9 утра.
Что происходит в конце спринта
Наступает долгожданный конец спринта, обычно это пятница в 16:00, и команда сдает спринт Product Owner’у и всем-всем, кто заинтересован в продукте. Каждый отчитывается по задачам, которые выполнял и рассказывает о том, каких успехов достиг, а также объясняет причины, по которым не удалось достичь цели. Главное правило — никогда не переносите срок сдачи спринта.
Иногда после сдачи спринта делается анализ того, почему что-то происходит или не происходит, и что нужно предпринять, чтобы исправить ситуацию.
А в понедельник все повторяется сначала.
Накопленный опыт
Мы для себя выработали несколько правил, несоблюдение которых приводило к провалу спринта:
• Спринт надо планировать детально, не жалея на это сил. Если что-то из требований непонятно, то надо прояснять требование. Если это не удается сделать, то не надо брать задачу в спринт, а требование отправлять на доработку.
• Ни при каких условиях не брать дополнительные задачи, которые идут вне спринта. А если все-таки «навязали», то согласовать с Product Owner’ом, что будут удалены из спринта другие задачи.
• Количество человек в команде не должно превышать 5-6 человек. Когда наша команда выросла до 16 человек, митинг начал затягиваться на 2 часа. Ввели фиксированное время выступления для каждого и стояли с секундомером. Но тогда человек не успевал донести свою мысль, и митинг превращался в формальность. Поэтому мы просто разделились. Сначала поделились на клиентщиков и ядерщиков, а потом начали делиться по задачам. Т.е. каждая команда делает свою фичу, и в этой подкоманде есть как клиентщики, так и ядерщики. Этот подход используется до сих пор, и для нас он наиболее эффективен.
Вывод
Scrum может быть хорошей отправной точкой для начала движения. В процессе работ некоторые правила могут эволюционировать или отпасть за ненадобностью. Это уже будет решать команда, отношения в команде и сама жизнь. Но правила, которые сформируются на основе Scrum, послужат хорошим плацдармом для достижения командой желаемого результата.
Кто мы?
Команда, в которой я работаю, называется «Юниклауд Лабс». Это дружный коллектив интересных людей, реально болеющих за свое дело.
Вариков Андрей VAndrey
Технический директор ООО «Юниклауд Лабс»
Если интересно что мы делаем — Welcome
Спринт — это… Что такое Спринт?
3.1.18 Спринт (индивидуальный и командный). Для соревнований по индивидуальному спринту трасса должна быть широкой, 6 — 10 м, с малым количеством крутых поворотов, а участки трассы должны быть спроектированы так, чтобы быть достаточно прямыми, широкими и длинными для осуществления обгона. Старт должен быть организован в виде прямых коридоров или непрерывной прямой лыжни на протяжении первых 30 — 50 м (рис. 3.6, а).
На прямых участках трассы возможна разметка коридоров. Ширина коридоров должна составлять 3 м для свободного стиля и 1,5 м — для классического.
Количество коридоров на финише должно соответствовать количеству участвующих в забеге спортсменов, но не более 4 финишных коридоров.
Длина финишной зоны должна быть минимум 80 м (рис. 3.6, б).
Для гонок в командных спринт-эстафетах участки трассы должны быть достаточно длинными, прямыми и широкими, чтобы была возможность обгона. В зависимости от расположения старта должно быть подготовлено от 2 до 6 параллельных стартовых коридоров/лыжней, прямых на протяжении примерно 100 м. Стартующий первым в первой команде стартует на дорожке с номером 1 на стартовой линии. Стартующий второй команды располагается в 1 — 3 м позади стартовой линии и стартует со второй дорожки и так далее (рис. 3.7).
Зона передачи эстафеты должна быть 15 м в ширину и как минимум 45 м в длину, расположена и подготовлена таким образом, чтобы соревнующиеся могли провести чистую передачу эстафеты на достаточно низкой скорости. Данная зона, как правило, ограждается изгородью, канатами или гирляндами из флажков. Плакат с надписью «Финиш» укрепляют в начале зоны передачи эстафеты.
Зона для подготовки лыж должна располагаться рядом с зоной передачи эстафеты.
Во время полуфинала и финала допускается работа только одного человека (тренера, смазчика) с лыжами одной команды. Возможность использования смазочных столов решается жюри в зависимости от размера свободного пространства площадки. На финише должно быть как минимум 3 коридора, на международных соревнованиях и проходящих под эгидой Федерации лыжных гонок России — 4 коридора.
Что такое Спринт в Скраме : мифы, ошибки и выдумки
Если разработчики и менеджеры не до конца понимают, что такое спринт и зачем он нужен в Скраме, они могут сильно навредить проекту. Разбираемся с правильным определением спринта, распространенными ошибками и способами их исправить.
Главное. Что такое Cпринт в Скраме
Как говорится в Руководстве по Скраму , Спринт — это временной отрезок длительностью месяц или меньше, в течение которого создается «готовый», то есть пригодный к использованию и выпуску Инкремент продукта. Для эффективной разработки спринты должны быть одинаковой длины. Новый спринт всегда начинается сразу после окончания предыдущего.
Во время спринта:
- не допускаются изменения, которые могут поставить под угрозу цель спринта;
- качество продукта не должно снижаться;
- по мере появления новых знаний, объем работ может быть уточнен и заново согласован между Владельцем Продукта и Командой разработки.
Спринт как концепция основывается на теории эмпирического управления. Её применяют, чтобы сделать разработку более предсказуемой и снизить риски. Три кита теории эмпиризма — прозрачность, инспекция и адаптация. Именно инспекция результатов работы и адаптация их под потребности пользователей являются залогом успеха спринта. К сожалению, именно эти принципы недопонимают чаще всего, вместо них полагаясь на мифы.
Миф первый. Обратную связь иногда можно игнорировать
Десятилетиями успех проектов по разработке измеряли с помощью «золотого треугольника менеджера», то есть по соотношению времени, стоимости и объёма работ. В результате погиб не один проект и появился не один бесполезный продукт: этот треугольник относится к успеху продукта лишь опосредованно.
Но как тогда сделать проект успешным? Прежде всего, помнить о том, что Скрам создан для разработки креативных ПРОДУКТОВ (не проектов), как говорится в Руководстве по Скраму.
Главная цель в применении Скрама — создать продукт, который будет иметь спрос у пользователей и давать достаточную окупаемость инвестиций (ROI). Самый серьезный риск в разработке — выпустить продукт, который никому не нужен. Скрам уменьшает этот риск с помощью частых циклов обратной связи. Чтобы разработать востребованный продукт, Скрам команда регулярно проводит демонстрации (инспектирует Инкремент) во время Обзоров Спринтов. На этих встречах ключевые стейкхолдеры и конечные пользователи работают с инкрементом продукта. Так мы получаем обратную связь, а Владелец Продукта корректирует планы — адаптирует Бэклог Продукта, а иногда и план релиза.
Спринт без отзывов нарушает принципы прозрачности, инспекции и адаптации. Поэтому всегда приглашайте стейкхолдеров и конечных пользователей на Обзор Спринта.
Миф второй. Спринт провален, если в нём не удалось достичь целей
Поскольку процесс в Скраме эмпирический, каждый спринт — это эксперимент, в котором возможны разные случайности. Это влечет за собой некоторые риски — как раз их призваны снизить ограничения по времени.
Кен Швабер в книге «Софт за 30 дней» (Software in 30 days) так описывает случайности в разработке: «С самого начала у нас есть видение или возможность, которой мы собираемся воспользоваться. Команда разработки создает приложение, чтобы воплотить важнейшие стороны нашего видения. Мы смотрим на инкремент и начинаем думать, как он будет использоваться. Мы обсуждаем, что добавить, чтобы сделать инкремент полезнее. В некоторых дисциплинах это также называется промежуточным контролем. Мы проводим его в каждой итерации».
Если спринт рассматривать как эксперимент, а Скрам — как эмпирический процесс, становится ясно следующее:
Проваленным можно назвать спринт, в конце которого мы ничему не научились. При таком сценарии мы не можем инспектировать и адаптировать результаты работы, не можем кастомизировать продукт и процессы.
Многим трудно принять такую концепцию. Мы привыкли думать, что успешная команда — это та, которая за один спринт успевает разработать множество фич. В реальности же это множество окажется совершенно бесполезным, если фичи не подвергнуть инспекции и адаптации.
Пример удачного спринта:
Команда не выполнила цель спринта, переоценив свои возможности с самого начала и напланировав слишком много. На Обзоре Спринта она честно показывает заказчикам только то, что действительно готово, даже если это всего лишь несколько вещей. Она получает обратную связь, какой бы та ни была. После этого Владелец Продукта решает, финансировать следующий спринт или нет. Его решение может быть как положительным, так и отрицательным. Если он решает в пользу следующего спринта, то команда идет на Ретроспективу, где инспектирует себя, свои инструменты и процессы, чтобы адаптировать их в следующем спринте.
Пример неудачного спринта:
Команда смогла закончить много функций и выполнить к Обзору Спринта всё запланированное («благодаря» овертаймам и снижению качества). Но на Обзор Спринта не пришел никто, кроме Владельца Продукта. Команда разработки так и не видит реакцию пользователей, а стейкхолдеры слишком заняты, чтобы ходить на Обзоры. Нет никакой обратной связи об инкременте. Раз так, то можно и Ретроспективу пропустить — у всех и так слишком много работы. А потом — начать новый «успешный» спринт.
Миф третий. Спринт не обязательно заканчивается выпуском готового Инкремента
Некоторые неопытные специалисты полагают, что не все спринты должны заканчиваться созданием готового инкремента. В результате появляются разные виды «недоспринтов», которых стоит избегать. Вот некоторые из них.
Спринт ноль
Так называют небольшой отрезок работ по созданию видения и наброска Бэклога Продукта. Это делается, чтобы оценить время и объем работы до релиза. Сами по себе такие действия неплохие, но только когда все причастные к ним понимают, что полученный результат будет менятся после инспекции в каждом спринте. Так или иначе, называть прогнозирование спринтом нельзя, так как оно противоречит определению спринта в Скраме.
Дизайн-спринт
Такой «спринт» начинают, чтобы создать техническую архитектуру — руководство для всего последующего релиза. Этот случай «тяжелее», чем предыдущий: помимо того, что он не соответствует определению спринта, он еще и мешает инспекции и адаптации в последующих спринтах. Опять-таки, наброски по архитектуре и функционалу могут быть полезны как часть видения продукта: так команда избежит риска и наладит диалог со стейкхолдерами. Но не стоит разрабатывать подробный и окончательный дизайн процесса.
Жесткий спринт (Hardening Sprint)
Из всех вольных интерпретаций спринта потенциально опаснее всего именно эта. Концепция пришла из одного популярного фреймворка, и в последних его редакциях относительно жестких спринтов уже есть поправки. Цель такого спринта — добиться готового к выпуску и интеграции инкремента, которого невозможно было добиться ранее. Такая постановка вопроса подразумевает, что в результате каких-то других спринтов могут получаться неготовые инкременты. Так возникает двоякое толкование прозрачности, инспекции и адаптации, а без них команды уже не могут провести ни одного настоящего спринта.
Выводы
- Тем, кто работает по Скраму, нужно создавать действующие творческие продукты, а не проекты.
- Каждый спринт — это эксперимент. Его результаты обязательно подвергаются инспекции и адаптации.
- Если результаты спринта нельзя инспектировать и адаптировать, спринт считается неудачным.
- В результате спринта должен появляться готовый инкремент продукта, а не жестко определенный план последующих работ. На этом основан эмпиризм Скрама.
Успешных вам спринтов!
Статья подготовлена по материалам и мотивам:
What is a Sprint in Scrum? (Scrum.org)
What is a failed Sprint? (Илья Павличенко)
Scrum Myths: It is ok to have a Sprint 0, Design Sprint, Hardening Sprint… (Алекс Бэллерин Латр)
Переведено и адаптировано командой BrainRain
Остались вопросы? Напишите нам ⬇️
Три Спринта на фичу. Что делать?
Андрей Толмачев рассказывает, как разрешить взаимное недовольство Владельца Продукта и Команды Разработки.
Условия задачи
Представьте такую ситуацию. Вы — новый Скрам-мастер. Ваша Команда Разработки состоит из системного аналитика, двух разработчиков и двух специалистов по тестированию. Длина Спринта — две недели. Команда работает со сложной системой на старой платформе, поэтому для каждого элемента Бэклога Продукта аналитика, разработка и тестирование попадают в отдельные Спринты.
В течение последнего Спринта Команда не успела сделать работу, взятую в Спринт, поэтому на Ретро Владелец Продукта допытывается, кто чем занимался в течение Спринта.
Владелец Продукта жалуется, что Команда работает очень медленно. Члены Команды жалуются, что бизнес контролирует и микроменеджит их.
Как разрешить взаимное недовольство Владельца Продукта и Команды Разработки?
Давайте разбираться.
Что происходит
Для каждого элемента Бэклога Продукта аналитика, разработка и тестирование попадают в отдельные Спринты — это означает, что элемент будет готов к выпуску только через три Спринта. В таком случае истинная длина Спринта равна шести неделям — это больше, чем допускает Руководство по Скраму.
Максимальная продолжительность Спринта — один календарный месяц. При большем сроке планирования возможны изменения целей, увеличение сложности и рост рисков.
Руководство по Скраму
Когда Команда редко поставляет готовый Инкремент, то редко получает обратную связь от стейкхолдеров и клиентов. В результате:
- возрастает риск сделать не то, что надо. Способность реагировать на изменения падает;
- стабильность процесса падает, прогнозировать работу сложно. Например, тестирование выявляет дефекты через недели после разработки. Баги обнаруживаются поздно, поэтому объём «поддержки» будет меняться от Спринта к Спринту;
- рабочий процесс перестаёт быть прозрачным.
По этим причинам Команда Разработки теряет доверие Владельца Продукта и стейкхолдеров, следовательно, давление возрастает и начинаются конфликты.
Решение
Скрам-мастер не может решить проблему самостоятельно, но может помочь своей Команде следующим образом:
- объяснить описанную выше системную динамику и её вредные последствия. Скрам-команда должна понимать, что правило Скрама про Done Increment каждый Спринт — это естественное системное решение их проблемы;
- помочь сформулировать или пересмотреть минимальный DoD, который может быть выполнен в течение Спринта и который обеспечит готовность Инкремента к релизу;
- научить Команду Разработки правильно декомпозировать элементы Бэклога. Небольшие элементы в Бэклоге Продукта способствуют ранней поставке, оптимизации ценности Продукта и улучшению потока работы;
- помочь договориться взять в следующий Спринт хотя бы один небольшой элемент Бэклога, но довести его до состояния Done;
- визуализировать поток работы. Прозрачность — залог успеха;
- устранить простои в работе. Для этого Скрам-мастер обучает Команду хорошим инженерным практикам, например, общему владению кодом, стимулирует развитие T-shaped или E-shaped людей в Команде, заключает командные соглашения;
- объяснить Владельцу Продукта, что причина задержек — технический долг и убедить его выплатить.
Используйте Ретроспективу, чтобы найти лучшие решения по устранению препятствий. Помните, что эти решения — эксперименты, не факт, что они принесут ожидаемый эффект. Поэтому инспектируйте результаты прошлых решений и адаптируйте решения на следующих Ретроспективах.
Итоги
Готовый Инкремент в конце Спринта — это важнейшие правило Скрама, которое помогает избежать роста рисков, потери предсказуемости и гибкости.
Описанные причинно-следственные связи полезно знать, чтобы понимать, почему Скрам требует соответствующий DoD, готовый к релизу Инкремент каждый Спринт.
Следующие действия могут помочь в достижении этой цели:
- декомпозиция работы на небольшие PBI;
- визуализация потока работы в Спринте и поиск основных узких мест;
- устранение «простоев» работы с помощью командных соглашений, хороших инженерных практик и развития T-shaped или Е-shaped людей;
- планомерная ликвидация технического долга.
Что такое Спринт в Скраме : мифы, ошибки и выдумки
Если разработчики и менеджеры не до конца понимают, что такое спринт и зачем он нужен в Скраме, они могут сильно навредить проекту. Разбираемся с правильным определением спринта, распространенными ошибками и способами их исправить.
Главное. Что такое Cпринт в Скраме
Как говорится в Руководстве по Скраму , Спринт — это временной отрезок длительностью месяц или меньше, в течение которого создается «готовый», то есть пригодный к использованию и выпуску Инкремент продукта. Для эффективной разработки спринты должны быть одинаковой длины. Новый спринт всегда начинается сразу после окончания предыдущего.
Во время спринта:
- не допускаются изменения, которые могут поставить под угрозу цель спринта;
- качество продукта не должно снижаться;
- по мере появления новых знаний, объем работ может быть уточнен и заново согласован между Владельцем Продукта и Командой разработки.
Спринт как концепция основывается на теории эмпирического управления. Её применяют, чтобы сделать разработку более предсказуемой и снизить риски. Три кита теории эмпиризма — прозрачность, инспекция и адаптация. Именно инспекция результатов работы и адаптация их под потребности пользователей являются залогом успеха спринта. К сожалению, именно эти принципы недопонимают чаще всего, вместо них полагаясь на мифы.
Миф первый. Обратную связь иногда можно игнорировать
Десятилетиями успех проектов по разработке измеряли с помощью «золотого треугольника менеджера», то есть по соотношению времени, стоимости и объёма работ. В результате погиб не один проект и появился не один бесполезный продукт: этот треугольник относится к успеху продукта лишь опосредованно.
Но как тогда сделать проект успешным? Прежде всего, помнить о том, что Скрам создан для разработки креативных ПРОДУКТОВ (не проектов), как говорится в Руководстве по Скраму.
Главная цель в применении Скрама — создать продукт, который будет иметь спрос у пользователей и давать достаточную окупаемость инвестиций (ROI). Самый серьезный риск в разработке — выпустить продукт, который никому не нужен. Скрам уменьшает этот риск с помощью частых циклов обратной связи. Чтобы разработать востребованный продукт, Скрам команда регулярно проводит демонстрации (инспектирует Инкремент) во время Обзоров Спринтов. На этих встречах ключевые стейкхолдеры и конечные пользователи работают с инкрементом продукта. Так мы получаем обратную связь, а Владелец Продукта корректирует планы — адаптирует Бэклог Продукта, а иногда и план релиза.
Спринт без отзывов нарушает принципы прозрачности, инспекции и адаптации. Поэтому всегда приглашайте стейкхолдеров и конечных пользователей на Обзор Спринта.
Миф второй. Спринт провален, если в нём не удалось достичь целей
Поскольку процесс в Скраме эмпирический, каждый спринт — это эксперимент, в котором возможны разные случайности. Это влечет за собой некоторые риски — как раз их призваны снизить ограничения по времени.
Кен Швабер в книге «Софт за 30 дней» (Software in 30 days) так описывает случайности в разработке: «С самого начала у нас есть видение или возможность, которой мы собираемся воспользоваться. Команда разработки создает приложение, чтобы воплотить важнейшие стороны нашего видения. Мы смотрим на инкремент и начинаем думать, как он будет использоваться. Мы обсуждаем, что добавить, чтобы сделать инкремент полезнее. В некоторых дисциплинах это также называется промежуточным контролем. Мы проводим его в каждой итерации».
Если спринт рассматривать как эксперимент, а Скрам — как эмпирический процесс, становится ясно следующее:
Проваленным можно назвать спринт, в конце которого мы ничему не научились. При таком сценарии мы не можем инспектировать и адаптировать результаты работы, не можем кастомизировать продукт и процессы.
Многим трудно принять такую концепцию. Мы привыкли думать, что успешная команда — это та, которая за один спринт успевает разработать множество фич. В реальности же это множество окажется совершенно бесполезным, если фичи не подвергнуть инспекции и адаптации.
Пример удачного спринта:
Команда не выполнила цель спринта, переоценив свои возможности с самого начала и напланировав слишком много. На Обзоре Спринта она честно показывает заказчикам только то, что действительно готово, даже если это всего лишь несколько вещей. Она получает обратную связь, какой бы та ни была. После этого Владелец Продукта решает, финансировать следующий спринт или нет. Его решение может быть как положительным, так и отрицательным. Если он решает в пользу следующего спринта, то команда идет на Ретроспективу, где инспектирует себя, свои инструменты и процессы, чтобы адаптировать их в следующем спринте.
Пример неудачного спринта:
Команда смогла закончить много функций и выполнить к Обзору Спринта всё запланированное («благодаря» овертаймам и снижению качества). Но на Обзор Спринта не пришел никто, кроме Владельца Продукта. Команда разработки так и не видит реакцию пользователей, а стейкхолдеры слишком заняты, чтобы ходить на Обзоры. Нет никакой обратной связи об инкременте. Раз так, то можно и Ретроспективу пропустить — у всех и так слишком много работы. А потом — начать новый «успешный» спринт.
Миф третий. Спринт не обязательно заканчивается выпуском готового Инкремента
Некоторые неопытные специалисты полагают, что не все спринты должны заканчиваться созданием готового инкремента. В результате появляются разные виды «недоспринтов», которых стоит избегать. Вот некоторые из них.
Спринт ноль
Так называют небольшой отрезок работ по созданию видения и наброска Бэклога Продукта. Это делается, чтобы оценить время и объем работы до релиза. Сами по себе такие действия неплохие, но только когда все причастные к ним понимают, что полученный результат будет менятся после инспекции в каждом спринте. Так или иначе, называть прогнозирование спринтом нельзя, так как оно противоречит определению спринта в Скраме.
Дизайн-спринт
Такой «спринт» начинают, чтобы создать техническую архитектуру — руководство для всего последующего релиза. Этот случай «тяжелее», чем предыдущий: помимо того, что он не соответствует определению спринта, он еще и мешает инспекции и адаптации в последующих спринтах. Опять-таки, наброски по архитектуре и функционалу могут быть полезны как часть видения продукта: так команда избежит риска и наладит диалог со стейкхолдерами. Но не стоит разрабатывать подробный и окончательный дизайн процесса.
Жесткий спринт (Hardening Sprint)
Из всех вольных интерпретаций спринта потенциально опаснее всего именно эта. Концепция пришла из одного популярного фреймворка, и в последних его редакциях относительно жестких спринтов уже есть поправки. Цель такого спринта — добиться готового к выпуску и интеграции инкремента, которого невозможно было добиться ранее. Такая постановка вопроса подразумевает, что в результате каких-то других спринтов могут получаться неготовые инкременты. Так возникает двоякое толкование прозрачности, инспекции и адаптации, а без них команды уже не могут провести ни одного настоящего спринта.
Выводы
- Тем, кто работает по Скраму, нужно создавать действующие творческие продукты, а не проекты.
- Каждый спринт — это эксперимент. Его результаты обязательно подвергаются инспекции и адаптации.
- Если результаты спринта нельзя инспектировать и адаптировать, спринт считается неудачным.
- В результате спринта должен появляться готовый инкремент продукта, а не жестко определенный план последующих работ. На этом основан эмпиризм Скрама.
Успешных вам спринтов!
Статья подготовлена по материалам и мотивам:
What is a Sprint in Scrum? (Scrum.org)
What is a failed Sprint? (Илья Павличенко)
Scrum Myths: It is ok to have a Sprint 0, Design Sprint, Hardening Sprint… (Алекс Бэллерин Латр)
Переведено и адаптировано командой BrainRain
Остались вопросы? Напишите нам ⬇️