что такое суперспринт в agile
Спринты
Спринт — это короткий временной интервал, в течение которого scrum-команда выполняет заданный объем работы.
Просмотр тем
Что такое спринты?
Спринт — это короткий временной интервал, в течение которого scrum-команда выполняет заданный объем работы. Спринты лежат в основе методологий scrum и agile, и правильный выбор спринтов поможет вашей agile‑команде выпускать более качественное программное обеспечение без лишней головной боли.
«При использовании scrum продукт разрабатывается в ходе нескольких итераций с фиксированной продолжительностью, которые называются спринтами и разбивают большие сложные проекты на небольшие задачи», — говорит Меган Кук, менеджер группы товаров для Jira Software в Atlassian.
Многие ассоциируют Scrum-спринты с Agile-разработкой программного обеспечения настолько часто, что Scrum и Agile принимают за синонимы. Однако это не так. Agile — это набор принципов, а Scrum — методика для активного решения задач.
Многочисленные сходства между глобальными задачами agile и процессами scrum вполне справедливо приводят к тому, что эти два понятия ассоциируются друг с другом. Благодаря спринтам команды могут следовать agile‑принципу «частой поставки рабочего программного обеспечения», а также реализовать agile‑задачу «реагирования на изменения в соответствии с планом». Установки scrum — прозрачность, проверка и адаптация — дополняют agile‑методику и играют главную роль в концепции спринтов.
Руководство по Scrum закладывает прочную теоретическую основу для обсуждения спринтов. Мы хотим внести немного красок в эту тему и делимся рекомендациями от людей, которые занимаются этой работой каждый день.
Как планировать и выполнять спринты в scrum
Авторы Scrum действительно все предусмотрели. Чтобы запланировать предстоящий спринт, нужно провести собрание по планированию спринта. Планирование спринта — это мероприятие, на котором команда сообща отвечает на два основных вопроса: какую работу можно выполнить в этом спринте и как она будет выполняться?
Выбором подходящих рабочих задач для спринта занимаются совместно владелец продукта, Scrum-мастер и команда разработчиков. Владелец продукта определяет цель спринта и задачи из бэклога продукта, при выполнении которых она будет достигнута.
Затем команда создает план, согласно которому будут выполняться задачи бэклога, чтобы к окончанию спринта вся работа была завершена. Выбранные рабочие задачи и план по их выполнению называется бэклогом спринта. К концу совещания по планированию спринта команда готова приступить к работе. Для этого необходимо просто выбирать задачи из бэклога спринта и менять их статус с «В работе» на «Готово» по мере завершения работы.
В течение спринта команда собирается на ежедневные Scrum‑совещания (стендапы), чтобы обсудить ход работы. Такие совещания нужны, чтобы выявить блокеры и проблемы, которые могут повлиять на достижение цели спринта.
По окончании спринта команда показывает выполненную работу на обзоре итогов спринта. Здесь можно продемонстрировать итоги работы заинтересованным сторонам и другим участникам команды до того, как они попадут в рабочую среду.
Завершите цикл спринтов на моем любимом собрании — ретроспективе спринта. Здесь команда может определить области, требующие улучшения в следующем спринте. С этими сведениями можно начинать следующий цикл спринта. Вперед!
Что стоит и не стоит делать
Даже если основы уже известны, большинство команд спотыкается в начале работы со спринтами. Меган Кук завершает эту дискуссию списком действий, которые стоит и не стоит делать при использовании спринтов, которые она сформулировала за годы своей работы.
И если уж вы работаете над тем, чтобы стать сильным специалистом по scrum, выполняя рекомендации, ознакомьтесь также с действиями, которые выполнять не следует.
Чего не стоит делать.
Оптимизируйте спринты с помощью автоматизации
Когда вы поймете, как работают спринты, вы сможете оптимизировать процессы, используя автоматизацию. Вот три правила автоматизации, которые часто используются в спринтах Jira.
Эти и сотни других правил автоматизации можно найти в библиотеке шаблонов Jira Automation.
Подробнее о спринтах
Спринты настолько известны (и настолько эффективны), что их часто считают первым шагом на пути к повышению гибкости. Но мы выяснили, что для освоения спринтов необходимо овладеть некоторыми взаимосвязанными понятиями Scrum и Agile. Изучите остальные статьи по Scrum, чтобы расширить знания и стать еще на шаг ближе к счастью от использования Scrum.
Как объяснить бабушке, что такое Agile за 15 минут с картинками
«Любое дело всегда длится дольше, чем ожидается, даже если учесть закон Хофштадтера.»
— закон Хофштадтера
Самый просматриваемый ролик на YouTube по теме agile. 744 625 просмотров на момент публикации данной статьи. Легкий стиль изложения, картинки и всего 15 минут — лучшее что я видел. TED отдыхает.
Это Пэт, владелец продукта. Она не знает технических деталей, зато обладает видением общей картинки, знает, зачем мы делаем продукт, какие проблемы он будет решать и для кого.
Это заинтересованные лица. Они будут использовать продукт, поддерживать его или будут как-то еще вовлечены в разработку.
Это пользовательские истории. В них выражены пожелания заинтересованных лиц. Например, «у системы бронирования авиабилетов у пользователя должен быть поиск по рейсам».
У заинтересованных лиц много идей, и Пэт помогает сделать из идей пользовательские истории.
Это команда разработчиков. Те, кто будет строить рабочую систему.
Пропускная способность
Так как команда использует гибкую методологию разработки, они не копят все эти истории до большого релиза, наоборот, они выпускают их сразу и как можно чаще. Обычно они выпускают 4-6 пользовательских историй в неделю. Это их пропускная способность. Ее очень просто измерить — количество пользовательских историй за 7 дней.
Некоторые истории большие, их можно считать за две, некоторые маленькие, их можно считать за половину.
Для того чтобы поддерживать этот ритм и чтобы не завязнуть в ручном регрессивном тестировании, команда усиленно работает над автоматическим тестированиеми постоянной интеграцией. Поэтому на каждую фичу приходится писать автотесты, и большая часть кода имеет встроенные автотесты.
Проблема заключается в том, что заинтересованных лиц очень много и их запросы невозможно удовлетворить 4-6 историями в неделю.
Каждый раз когда мы реализуем пользовательскую историю, у них появляется еще несколько идей, из которых вытекает еще больше запросов.
Что произойдет, если мы будем делать все, о чем они нас просят? У нас будет перегруз.
Допустим, команда возьмется сделать 10 новых историй за эту неделю.Если на входе 10 а на выходе 4-6, то команда будет перегружена. Будет спешить, переключаться между задачами, терять мотивацию, в итоге снижается производительность и качество. Это заведомо проигрышная стратегия.
Scrum и XP в этом случае используют метод “вчерашняя погода”. Команда говорит: “За последнее время мы делали 4-6 фич в неделю, какие 4-6 фич мы будем делать на следующей неделе?”
Задача владельца продукта в том, чтобы грамотно выбирать, какие именно пользовательские истории будут реализованы на этой неделе.
Kanban рекомендует ограничиться несколькими задачами — WIP limit. Допустим команда решает, что 5 — это приемлемое количество пользовательских историй, над которыми они смогут работать одновременно без перегруза, не перескакивая с одной на другую.
Оба эти подхода хорошо работают и оба они создают очередь задач, которые в Scrum называется Backlog, или приоритезированный список задач.
Этой очередью тоже необходимо управлять.Если заинтересованные лица запрашивают 10 историй в неделю, а команда реализует 4-6 историй, то эта очередь будет становиться все больше и больше. И скоро ваш Backlog будет расписан на полгода вперед. То есть одна история будет ждать выхода 6 месяцев.
Есть только один способ держать список задач под контролем — это слово “нет”
Это наиболее важное слово для владельца продуктом. Он должен тренировать его каждый день перед зеркалом.
Сказать “да” — легко. Но более важная задача — решать, что не надо делать и нести за это ответственность. Владелец продукта так же определяет последовательность, что делаем сейчас, а что позже. Это сложная работа и выполнять ее следует вместе с командой разработки и минимум одним заинтересованным лицом.
Для того, чтобы правильно расставить приоритеты, владелец продукта должен понимать ценность каждой истории и ее объем.
Принятие решений
Некоторые истории крайне необходимы, а некоторые просто бонусные фичи. На разработку одних историй уйдет пару часов, на разработку других — месяцы.
Как соотносится размер истории и ее ценность? Никак. Больше не значит лучше. Ценность и сложность задачи — вот что помогает Пэт расставлять приоритеты.
Как владелец продукта определяет ценность и объем истории? Никак. Это игра в угадайку. И лучше в ней участвовать всем. Пэт постоянно общается с заинтересованными лицами, чтобы знать ценность каждой истории, общается с командой разработчиков, чтобы знать объем работ, но все это приблизительные догадки, никаких точных цифр. Вначале всегда будут промахи и это нормально. Гораздо большую ценность представляет общение, чем сверхточные цифры.
Каждый раз когда разработчики выпускают что то новое, мы узнаем больше информации и можем лучше ориентироваться.
Одной приоритезации недостаточно. Чтобы выпускать истории быстро и часто, нужно разбивать на кусочки, которые можно сделать за пару дней. Мы хотим чтобы в начале воронки были маленькие и четкие истории а в конце — большие и неопределенные. Вовремя делать такую разбивку мы можем воспользоваться нашими последними открытиями относительно продукта и нужд пользователя. Это все называется очистка Backlogа.
Пэт проводит встречу по очистке Backlogа каждую среду с 11 до 12. Обычно на ней собирается вся команда и иногда несколько заинтересованных лиц. Содержание встреч бывает разным. Фокусировка на оценке, на разбивке историй, на критериях приемки.
Владелец ИТ-продукта должен постоянно со всеми общаться
Матерые владельцы продукта выделяют 2 компонента успеха: страсть к работе и общение. Какие задачи владелец продукта решает месте с командой.
Баланс между сложностью разработки и ценностью пользовательской истории
На ранней стадии балансу угрожает неопределенность и сразу несколько рисков.
Риски
Бизнес риск: «Правильную ли вещь мы делаем?»
Социальный риск: «Сможем ли мы сделать то что нужно?»
Технический риск: «Будет ли проект работать на данной платформе?»
Риски со стоимостью и сроками реализации: «Успеем ли и хватит ли денег?»
Знание можно рассматривать как противоположность риску. Когда неопределенность большая, мы фокусируемся на приобретении знаний — прототипах интерфейса, технических экспериментах,
Компромисс между ценностями знания и ценностями для клиента
С точки зрения заказчика кривая выглядит вот так:
С точки зрения ценности для заказчика эта кривая выглядит вот так. По мере того как неопределенности снижаются, мы можем концентрироваться на ценностях для заказчика. Мы знаем что и как делать. Остается только сделать. После того как реализовали основные истории, будем делать бонусные фичи или запускать новый проект.
Компромисс между краткосрочным и долгосрочным мышлением
Что реализовать в первую очередь? Срочно устранять ошибки или начать разрабатывать сногсшибательную фичу, которая поразит пользователей. Или делать сложный апгрейд платформы, который ускорит работу в будущем. Необходимо постоянно соблюдать баланс между реактивной и проактивной работой.
Делать правильные вещи, делать вещи правильно или делать быстро?
В идеале — все три одновременно, но в реальности приходится выбирать.
Предположим мы здесь. Пытаемся создать идеальный продукт с помощью идеальной архитектуры. Если мы потратим много времени, мы можем не попасть в «маркетинговое окно» и у нас появятся проблемы с деньгами.
Мы делаем быстро прототип продукта. Для краткосрочной перспективы это неплохо. В долгосрочной — мы получаем технический риск. И скорость разработки снизится до нуля.
Мы вот здесь, создаем прекрасный храм в рекордные сроки. Но пользователю не нужен был храм, ему нужен был жилой фургон.
Между ролями в Scrum существует здоровое противостояние
Владелец продукта фокусируется на построении правильных вещей. Команда фокусируется на том, чтобы строить вещи правильно. Scrum-мастер или agile-тренер фокусируется на сокращении цикла обратной связи.
Отдельно стоит подчеркнуть важность скорости, так ккак короткий цикл обратной связи ускоряет обучение. Это позволяет нам быстрее узнавать какие вещи правильные и как их правильно построить.
Компромисс между разработкой нового продукта и улучшением старого
Продукт никогда не может быть полностью завершен, потому что ему постоянно нужны изменения. Когда команда начинает работу над новым продуктом, что происходит со старым? Передача продукта от одной команды к другой — очень затратно и рискованно. Обычно команда поддерживает старый продукт, разрабатывая новый. Поэтому скорее понятие “Backlog” относится не к продукту а к команде. Backlog — это список вещей, которые хочет владелец продукта от команды. И набор историй для разных продуктов. Владельце продукта нужно постоянно выбирать актуальные для реализации.
График уничтожения историй
Время от времени, заинтересованные лица будут спрашивать у Пэт: “Когда выпустят мою фичу?” или “Сколько фич выпустят к рождеству?”. Владелец продукта должен уметь управлять ожиданиями пользователя. И управлять ожиданиями реалистично.
Два тренда — оптимистичный и пессимистичный (можно на глаз). Расстояние между трендами показывает насколько нестабильна скорость работы команды. Со временем эти тренды стабилизируются и конус неопределенности будет уменьшаться.
Предположим, заинтересованное лицо спрашивает, когда вот эта фича будет сделана?
Это вопрос с фиксированным содержанием и неопределенным сроком. Для ответа Пэт использует две линии тренда. Ответ — в апреле или мае.
Заинтересованное лицо спрашивает Пэт: «Сколько будет сделано к рождеству?» Это вопрос с фиксированным сроком и неопределенным содержанием. Линии тренда отсекают на вертикальной шкале вероятный отрезок того, что успеют реализовать.
Заинтересованное лицо спрашивает :«Успеем ли мы сделать вот эти фичи к рождеству?» Это вопрос с фиксированными временными рамками и фиксированным содержанием. Ориентируясь на тренды, Пэт отвечает: «Нет». Добавляя: «К рождеству мы успеем сделать столько, а вот столько времени нам понадобится чтобы завершить всю эту работу полностью.»
Обычно лучше уменьшать содержимое проекта, чем увеличивать время. Если мы уменьшаем содержание, у нас будет возможность отодвинуть сроки. Мы можем выпустить кое-что здесь, а остальное — позже.
Владелец продукта делает расчеты еженедельно и использует исключительно эмпирические данные, а не выдает желаемое за действительное. Он честно говорит о неопределенности. Команда поддерживает темп работы, а Пэт не давит на них, заставляя ускориться.
Несколько команд
Пусть у нас несколько владельцев продукта и несколько команд. Модель та же — управление пропускной способностью, коммуникация с заинтересованными лицами, принятие решений по поводу отклонения пользовательских историй. Скорость равна сумме скоростей всех команд. Прогнозирование может быть общее или по каждой команде. У владельцев продуктов появляется дополнительная задача — общение с другими владельцами продукта. Нужно организовать работу над Backlogами так, чтобы минимизировать зависимости и обеспечить синхронизацию. В больших проектах требуется Главный владелец продукта (CPO), чтобы синхронизировать всех остальных.
Эволюция обзора спринта в Agile-команде
Привет! Меня зовут Анатолий Савченко, я разработчик и по совместительству скрам-мастер в команде сервиса «Автотека». Как вы уже догадались, мы работаем по Cкраму. Каждые две недели мы проводим обзор спринта — встречу, на которой команда и заинтересованные стороны обсуждают, что было сделано. На основе этой информации команда может сделать выводы о том, в правильном ли направлении движется разработка, какие доработки ещё необходимы и т.д. Недавно мы получили ценный новый опыт проведения этой важной встречи. О нём я и хочу вам рассказать.
Инструменты получения обратной связи
Конечно, обзор спринта — это не единственный канал обратной связи: у нас есть UX-лаборатория, мы обрабатываем отзывы в сторах мобильных приложений, обращения в поддержку, отзывы на всевозможных интернет-ресурсах, проводим опросы пользователей на сайте и прочее.
Это — то, что касается частных пользователей.
Помимо них мы сотрудничаем с бизнес-партнёрами, которым мы предоставляем дополнительную функциональность и инструменты работы. С ними у нас более плотное взаимодействие. Наши менеджеры всегда с ними на связи (почта, телефон), есть чаты в мессенджерах, в которых состоят члены команды разработки. Таким образом мы становимся ближе к нашим бизнес-пользователям: мы их лучше знаем, понимаем их потребности, слышим их и чувствуем их боль или радость.
И это всё замечательные и нужные каналы связи. Но они дают информацию уже после релиза. Кроме того, в этом случае команда разработки всё ещё довольно далеко находится от пользователей. Именно поэтому обзоры спринта могут дать наибольшую пользу для команды, продукта и в конечном счёте для пользователей.
Обзор спринта — как было раньше
Наши встречи в целом проходили на хорошем уровне: мы получали оперативные и качественные комментарии от наших стейкхолдеров (то есть внутренних заказчиков — менеджеров) и других коллег из Авито. Создавалась довольно камерная обстановка, но в какой-то момент нам стало не хватать полноты обратной связи. Нам захотелось что-то поменять. И наш agile-тренер Левон Гончаров из AgileVerse навел нас на идею позвать внешних пользователей — наших бизнес-партнеров — прямо на встречу.
Левон Гончаров, co-founder AgileVerse: «С ребятами я познакомился, когда они решили улучшить свои процессы. Они понимали, что что-то идёт не так, и искали ответ. Во время диагностики каждый член команды так или иначе говорил о необходимости понимать “как живёт пользователь”. На кого-то это влияло с точки зрения мотивации, кому-то необходимо было понять, как развивать проект архитектурно. Это, в принципе, довольно частая проблема скрам-команд — превращение обзора спринта в встречу, где рассказывают то, что было сделано и мыслят не как создатели, а как исполнители. Чтобы этого не допускать, нужно задуматься вот о чем.
№1 Когда вы разрабатываете продукт, вы больше думаете о фичах или о проблемах пользователя?
№2 Вы знаете, как живёт ваш пользователь и для чего он должен использовать ваш продукт?
№3 Достаточно ли часто вы общаетесь с теми, кто пользуется вашим продуктом?
Я посоветовал команде обсудить эти вопросы и изменить формат обзора спринта.
Случай пообщаться с пользователями появился довольно быстро. К концу спринта мы планировали выпустить с конвейера новый инструмент для партнёров, который ещё никто не видел. И мы решили «на горячую» собрать обратную связь на ещё не вышедший продукт.
Подготовка
Для начала мы с Левоном собрали с коллег ожидания от новой встречи, после чего спланировали повестку и подготовили все необходимые материалы.
Могу сказать, что про одну только подготовку можно было бы написать целый пост. Она позволила создать нам целостную картину встречи и абсолютно всё учесть (конечно, мы учли не всё, потому что это невозможно, но мы учли и это).
Сначала мы расписали на флипчарте цель и образ результата. Прописали по пунктам общий план встречи. Детализировали наполнение каждого этапа.
Прописали тайминги всех этапов (и несколько раз переписали их). Определили для каждого этапа необходимые материалы и записали, что нужно не забыть взять на встречу.
Вкратце у нас получилось вот что.
Образ результата
Левон Гончаров, co-founder AgileVerse: «Когда мы заполняем примерную повестку встречи, выписываем всё, что может произойти на ней и какими способами мы можем этим управлять. Мы предположили, что пользователи начнут говорить об совершенно общих болях и мы внесли это в дизайн обзора спринта. Но в процессе подготовки стало ясно, что места на это не хватит. Так что мы получили полезную информацию перед встречей, что общие темы мы затрагивать не сможем».
Как всё прошло
Основной идеей было дать нашим пользователям живой опыт соприкосновения с продуктом и получить максимум обратной связи. Вот что мы придумали: каждого нашего гостя мы посадили за ноутбук с продуктом, рядом с которым постоянно находились два члена команды. Роль одного — рассказывать о продукте и отвечать на возникающие вопросы, а второго — максимально подробно записывать все, что происходит, чтобы потом обработать это вместе с владельцем продукта.
Ну, получилось чуть больше, чем два члена команды у каждого гостя
Обсуждение получилось насыщенным, и мы даже продлили показ продукта по времени. В результате не только получили массу полезных комментариев, но и узнали о том, как построена работа нашего партнёра изнутри. Это поможет нам в планировании дальнейшей работы над продуктом.
Так выглядела первая версия продукта
Мы хотели разместить максимум полезной информации на одной странице, однако для пользователей интерфейс получился перегруженным. Кроме того, часть информации была просто непонятной.
Мы записали комментарии и пожелания наших гостей, отметили самое важное и приоритетное, и тут же обсудили с партнёрами, что и когда собираемся реализовать.
Обратная связь помогла нам переосмыслить то, как можно удобно и понятно представить информацию для пользователя. На момент написания статьи уже были внесены самые приоритетные правки, которые значительно трансформировали первоначальную версию.
Версия продукта после правок
Благодаря ранней обратной связи нам удалось избежать ситуации, когда мы отдали нашим пользователям сырой продукт, который нужно править на ходу.
Мы как команда получили очень ценный опыт. Вот что говорят мои коллеги.
Вадим Иванов, генеральный директор Автотеки: «Подобный сбор обратной связи считаю очень полезной и нужной практикой, которую, по-хорошему нужно было внедрять намного раньше: одно дело — смотреть/слушать обзоры спринтов в уютной атмосфере позитивно настроенных коллег, совсем другое — сразу видеть живую реакцию пользователей на проделанную работу. Вдвойне полезно мнение бизнес-пользователей, т.к. они часто точнее знают свои потребности и проблемы. Даже первая попытка оказалась удачной, вся команда была сильно увлечена и вовлечена в процесс, удалось собрать ценные замечания, которые сразу взяли в работу еще до первого релиза новой функциональности и в итоге сделали намного более подготовленный для партнеров продукт. И экстра трудозатраты на подготовку мероприятия с лихвой окупились. Всем рекомендую внедрять подобные методы у себя и не бояться экспериментировать».
Мансур Ахмади, QA Автотеки: «В голове инженера образ конечного пользователя и его UX зачастую расходится с реальной картиной мира, что в свою очередь может привести к не самым подходящим решениям. На прошедшей встрече это было достаточно наглядно, когда наш гость обозначил свое видение продукта. То видение, которое доставило бы ему больше счастья. То видение, на которое нам стоит ориентироваться. На мой взгляд, именно такие встречи помогают быстрее к нему прийти».
Андрей Тумкин, product owner Автотеки: «Первое, что может прийти на ум, перед тем как позвать реальных пользователей на демо — зачем? Мы же на ранних этапах выявили их боли, а после релиза соберём обратную связь и внесём правки. Но не всё так просто.
Во-первых, вы будете терять время и деньги, вместо того, чтобы сразу решить проблемы пользователей. Во-вторых, даже проведенный до разработки CusDev не сможет выявить всех проблем, которые вскроются в реальном продукте. В-третьих, никакой другой процесс не даст такой вовлеченности команды в продукт».
Заключение
Встреча с пользователями — это не просто инструмент улучшения и получения обратной связи, это реальное построение отношений с теми, для кого ты делаешь продукт, и осознание важности этой работы.
Наша команда очень вдохновилась приобретенным опытом, поэтому мы планируем ввести подобную практику на регулярной основе — один раз в месяц или два. Желаю и вам провести подобную встречу, и посмотреть, что из этого получится. Удачи!