что такое спринт в скраме
Что такое Спринт в Скраме
Спринт — это отрезок времени, за который Скрам-команда создаёт часть Продукта, готовую к показу и ценную для клиента. Каждый Спринт — это мини-проект, который состоит из цели, плана по её достижению, работы и конечного Продукта. Если сравнивать разработку со съёмками сериала, то съёмка одной серии — это Спринт.
В Руководстве по Скраму написано, что Спринт не может быть короче одной недели и длиннее одного месяца. Такое ограничение задаёт временные рамки, достаточные для создания готового Продукта и безопасные для компании в случае, если он окажется невостребованным. По опыту наших тренеров оптимальная длина Спринта — 1–2 недели.
Каждый Спринт состоит из пяти последовательных мероприятий: Планирования Спринта, Ежедневного Скрама, разработки, Обзора Спринта и Ретроспективы Спринта. Все пять событий обязательны к исполнению и ограничены по времени.
Планирование Спринта
Планирование Спринта — это встреча, на которой Скрам-команда выбирает Цель Спринта и обсуждает конкретные шаги для её достижения.
Сколько длится: до восьми часов при длине Спринта один месяц.
Кто участвует: Владелец Продукта, Скрам-мастер, Команда Разработки.
Зачем нужно: определяет, какие цели будут достигнуты в Спринте.
Результат: Команда сформулировала Цель Спринта, составила Бэклог Спринта, обсудила и взяла в работу несколько пунктов из Бэклога Продукта.
В Болливуде снимают сериал. Перед съёмкой очередной серии режиссёр и съёмочная команда обсуждают предстоящую работу. Режиссёр хочет снять сцену во дворце махаражди с массовыми танцами и слонами. Команда прикидывает время на подготовку декораций и обучение массовки и говорит, что не успеет. В итоге от слонов и массовки отказались. Главная героиня будет танцевать одна в фойе отеля, который очень похож на дворец. Команда записала, что нужно сделать, чтобы это устроить.
Ежедневный Скрам
Ежедневный Скрам — это 15-минутные встречи, на которых Команда Разработки оценивает, как продвигается работа и синхронизирует планы на ближайшие 24 часа.
Сколько длится: 15 минут.
Кто участвует: Команда Разработки. Скрам-мастер может присутствовать, но не вмешивается в обсуждение.
Зачем нужен: синхронизироваться, оценить прогресс в работе, выявить проблемы.
Результат: Каждый член Команды понимает, как движется Команда к Цели Спринта и какой вклад в достижение общей цели он сделает сегодня.
На восходе солнца съёмочная команда обсуждает предстоящий день. Раджеш договорился о съёмках в отеле, Шанти — о транспорте. Костюмер Зита сообщила, что не хватает танцевального костюма для главной героини. Проговорили план на сегодня: найти, где арендовать костюм, подготовить съёмочную площадку, провести кастинг актёров для эпизодических ролей.
Разработка
Разработкой называют процесс работы Команды Разработки в течение одного Спринта.
Сколько длится: от 5 до 20 дней в зависимости от длины Спринта.
Кто участвует: Владелец Продукта, Скрам-мастер, Команда Разработки.
Зачем нужна: Во время разработки Команда создаёт или улучшает Продукт.
Результат: Инкремент Продукта — новая часть Продукта, готовая к показу и ценная для клиента.
На съёмку одной серии уходит неделя. Целую неделю съёмочная команда меняет локации, репетирует танцы, дорабатывает сценарий, снимает, отсматривает и монтирует. В понедельник новая серия выходит в эфир.
Обзор Спринта
Это неформальная встреча, на которой заинтересованным лицам показывают Инкремент Продукта. Все могут его потрогать, проверить, посмотреть, обсудить, чего в нём не хватает, что можно изменить или добавить.
Сколько длится: до четырех часов при месячной длительности Спринта.
Кто участвует: Владелец Продукта, Скрам-мастер, Команда Разработки, стейкхолдеры, пользователи, члены других команд компании.
Зачем нужен: для сбора обратной связи, демонстрации улучшений Продукта, получения замечаний, определения дальнейшего направления работы.
Результат: Владелец Продукта обновил Бэклог Продукта, собрал обратную связь, Команда сдала работу и готова творить дальше.
Перед выходом на телевидение команда показывает новую серию в студии. Члены команды приглашают свои семьи, приезжает спонсор сериала — богач Салим. После просмотра все обсуждают новую серию и злоключения главной героини за чашечкой чая со сладостями.
Ретроспектива Спринта
Команда обсуждает процесс работы, взаимодействие между членами Команды, инструменты и фокусируется на улучшениях процесса.
Сколько длится: до трёх часов при месячной длительности Спринта.
Кто участвует: Скрам-мастер, Команда Разработки, Владелец Продукта.
Зачем нужна: чтобы постоянно улучшать процесс работы Команды.
Результат: Команда обсудила, что мешает работе, составила план, как устранить проблемы.
После просмотра и обсуждения серии съёмочная команда собралась на террасе, чтобы обсудить, как прошла неделя и решить назревший конфликт между актёрами и костюмерами. Актёрам не нравятся старые костюмы, а костюмеры говорят, что не успевают шить новые. Решили перестать шить костюмы самим, а брать в аренду. На следующей Ретроспективе обсудят результаты этого решения.
Последовательное прохождение всех пяти событий Спринта позволяет работать эффективно и постоянно улучшать Продукт и процесс в зависимости от желаний клиентов и развития технологий.
Полезно сохранять неизменной продолжительность Спринта на протяжении всего процесса разработки, чтобы участники привыкли к определённому темпу работы. Новый Спринт начинается сразу после окончания предыдущего.
В чрезвычайных обстоятельствах Владелец Продукта может отменить Спринт. Например, если идею реализовала другая компания или руководство перепродало компанию тому, кто по Скраму работать не хочет. Отмена — это неприятное событие, которое травмирует всю Команду и сводит на нет большую работу. Используйте её только в крайнем случае.
Катя Кондратьева Редактор Unusual Concepts
Гибкие методы разработки
В вакансиях большинства IT-компаний востребованы гибкие методы разработки. В этой статье рассказываем, что такое Agile, Scrum и какие преимущества есть у подхода в целом.
В основе всего Agile — манифест, который чётко формулирует основные ценности процессов:
Гибкие методы позволяют сделать командную работу, с одной стороны, более динамичной и адаптивной, а с другой — комфортной для всех участников.
Один из инструментов для эджайл (Agile) — это скрам (Scrum). Это фреймворк (framework) для реализации основных принципов гибкой разработки.
Посмотрим, из чего он состоит, чтобы понять, как его применять.
Как устроен скрам
Начнём с основных инструментов, при помощи которых можно организовать рабочий процесс. Для иллюстраций будем использовать сервис Trello, который хорошо подходит для небольших команд.
Доска — это список задач, распределённых по этапам. Она может быть виртуальной, как в нашем примере, или реальной: нарисованной на флипчарте и со стикерами.
У доски есть несколько колонок:
У задач всегда есть исполнитель, который за них отвечает. Например, в Trello в карточке можно указать участника команды и уточнить, к какому направлению относится задача (например, фронтенд, бэкенд, дизайн и т. д.).
Доска — необязательный элемент, заимствованный из канбана. Некоторые команды могут вести свой бэклог и в Excel. Тем не менее доска наглядно иллюстрирует динамику процессов, поэтому ею часто пользуются.
Бэклог (backlog) — список задач проекта. Они попадают туда от продакт-оунера (product owner), который приоритизирует их исходя из бизнес-целей, технического долга или пожеланий пользователей. Главное правило — один продакт-оунер на один бэклог.
В этой статье мы не будем рассматривать методы приоритизации, а поступим просто: расположим самые важные задачи сверху. Но стоит отметить, что у Trello есть система меток, и мы можем добавлять нужные к самым критичным задачам.
Спринт (sprint) — это промежуток времени (месяц или меньше, например 2 недели), за который создаётся инкремент продукта.
Инкремент продукта — это определённый ощутимый результат, к которому должна прийти команда в течение спринта. Например, если мы делаем сервис для репетиторов, то инкрементом спринта может быть бронирование уроков, для которого у нас есть 6 задачек в бэклоге.
Бэклог спринта — задачи, которые нужно выполнить в текущем спринте для достижения инкремента. Как задачки попадают сюда из бэклога, мы разберём чуть позже.
Роли в команде скрама
Помимо инструментов скрам чётко регламентирует роли в команде.
Участники команды — это исполнители: например, разработчики, дизайнеры, копирайтеры.
Скрам-мастер (Scrum master) — сердце и душа скрам-команды. Он помогает организовать основные процессы: планирование, ежедневные митинги, ретроспективы, следит за скрам-доской (но не за бэклогом, за который отвечает продакт-оунер). Также скрам-мастер, как правило, фасилитирует встречи, то есть следит за тем, чтобы участники не отходили от темы и чувствовали себя комфортно. В идеале задача скрам-мастера — организовать процесс таким образом, чтобы команда могла работать без него. Но на практике, к сожалению, это редко реализуется.
Продакт-оунер (product owner) — это владелец продукта. Он видит полную картину и отвечает за приоритизацию задач и ведение бэклога, иногда формулировку и детализацию, а также решает, какой инкремент будет у спринта в соответствии с планированием и ресурсами команды.
Церемонии, они же встречи
Перед каждой встречей заранее определяется её цель и участники.
Планирование — перед стартом спринта продакт-оунер обозначает цели (инкремент), и встреча проходит с фокусом на этом инкременте спринта. Команда оценивает задачи, например в сторипойнтах (Story Points). Сама оценка может происходить на этапе планирования или заранее, в рамках груминга (см. ниже). После оценки команде нужно понять, какие она берёт задачи для выполнения инкремента. Если это невозможно в рамках спринта, то продакт-оунер меняет инкремент или принимает решение об увеличении длительности спринта.
Груминг — уточнение и формулировка задач, возможно, декомпозиция. В отличие от планирования и митингов, для этих встреч нет конкретных указаний, в какой момент их стоит проводить. Тем не менее основная цель — сделать задачи более прозрачными и лучше подготовится к планированию.
Митинги (стендапы) — ежедневная встреча, на которой команда разбирает текущие задачи, чтобы выявить проблемы в процессе. Длятся такие церемонии, как правило, 10–15 минут. Каждый участник рассказывает, что делал вчера и что планирует сегодня. Чаще митинги проводятся утром, но иногда команды их смещают на день или вечер. Такие встречи также фасилитирует скрам-мастер, чтобы участники чувствовали себя комфортно и встреча не затягивалась. Если, например, специалисты по бэкенду и фронтенду начинают детально обсуждать методы, то им предлагают назначить для этого разговора отдельную встречу.
Ретроспектива спринта — на этой встрече команда обсуждает, достигла ли инкремента, что получилось хорошо и не очень, а также что сделать, чтобы улучшить процесс. Цель ретроспективы — понять и проанализировать процессы и ошибки, подумать, как их предупреждать.
Демо — показ инкремента за один спринт или несколько. Демо может быть внутренним, с участниками близких команд (чтобы все понимали, что делают коллеги), или внешним — перед заказчиком.
Когда полезен скрам
Скрам хорош, когда нужно постоянное улучшение продукта. Например, у нас есть мобильное приложение и мы работаем над ним: исправляем баги и добавляем новые фичи. Цель нашего процесса — сделать продукт ещё лучше.
Скрам не подойдёт, когда не нужно ничего нового в процессах, а всё идёт по алгоритму. Например, мы делаем лендинги и процесс у нас выглядит так:
Мы хорошо представляем, сколько занимает каждый процесс. А ещё нам сложно приоритизировать задачи. Так что нет нужды в таком подробном планировании, как в скраме. В этом случае лучше применить другой подход — канбан.
Если вы решитесь внедрить скрам, то стоит знать о возможных сложностях:
Скрам — это относительно молодой подход к разработке, который постоянно развивается. У вас получится его внедрить, несмотря на все трудности, если он действительно подходит для ваших процессов. Он сделает работу команды удобнее, а процессы — прозрачнее.
В вакансиях большинства IT-компаний востребованы гибкие методы разработки. В этой статье рассказываем, что такое Agile, Scrum и какие преимущества есть у подхода в целом.
В основе всего Agile — манифест, который чётко формулирует основные ценности процессов:
Гибкие методы позволяют сделать командную работу, с одной стороны, более динамичной и адаптивной, а с другой — комфортной для всех участников.
Один из инструментов для эджайл (Agile) — это скрам (Scrum). Это фреймворк (framework) для реализации основных принципов гибкой разработки.
Посмотрим, из чего он состоит, чтобы понять, как его применять.
Как устроен скрам
Начнём с основных инструментов, при помощи которых можно организовать рабочий процесс. Для иллюстраций будем использовать сервис Trello, который хорошо подходит для небольших команд.
Доска — это список задач, распределённых по этапам. Она может быть виртуальной, как в нашем примере, или реальной: нарисованной на флипчарте и со стикерами.
У доски есть несколько колонок:
У задач всегда есть исполнитель, который за них отвечает. Например, в Trello в карточке можно указать участника команды и уточнить, к какому направлению относится задача (например, фронтенд, бэкенд, дизайн и т. д.).
Доска — необязательный элемент, заимствованный из канбана. Некоторые команды могут вести свой бэклог и в Excel. Тем не менее доска наглядно иллюстрирует динамику процессов, поэтому ею часто пользуются.
Бэклог (backlog) — список задач проекта. Они попадают туда от продакт-оунера (product owner), который приоритизирует их исходя из бизнес-целей, технического долга или пожеланий пользователей. Главное правило — один продакт-оунер на один бэклог.
В этой статье мы не будем рассматривать методы приоритизации, а поступим просто: расположим самые важные задачи сверху. Но стоит отметить, что у Trello есть система меток, и мы можем добавлять нужные к самым критичным задачам.
Спринт (sprint) — это промежуток времени (месяц или меньше, например 2 недели), за который создаётся инкремент продукта.
Инкремент продукта — это определённый ощутимый результат, к которому должна прийти команда в течение спринта. Например, если мы делаем сервис для репетиторов, то инкрементом спринта может быть бронирование уроков, для которого у нас есть 6 задачек в бэклоге.
Бэклог спринта — задачи, которые нужно выполнить в текущем спринте для достижения инкремента. Как задачки попадают сюда из бэклога, мы разберём чуть позже.
Роли в команде скрама
Помимо инструментов скрам чётко регламентирует роли в команде.
Участники команды — это исполнители: например, разработчики, дизайнеры, копирайтеры.
Скрам-мастер (Scrum master) — сердце и душа скрам-команды. Он помогает организовать основные процессы: планирование, ежедневные митинги, ретроспективы, следит за скрам-доской (но не за бэклогом, за который отвечает продакт-оунер). Также скрам-мастер, как правило, фасилитирует встречи, то есть следит за тем, чтобы участники не отходили от темы и чувствовали себя комфортно. В идеале задача скрам-мастера — организовать процесс таким образом, чтобы команда могла работать без него. Но на практике, к сожалению, это редко реализуется.
Продакт-оунер (product owner) — это владелец продукта. Он видит полную картину и отвечает за приоритизацию задач и ведение бэклога, иногда формулировку и детализацию, а также решает, какой инкремент будет у спринта в соответствии с планированием и ресурсами команды.
Церемонии, они же встречи
Перед каждой встречей заранее определяется её цель и участники.
Планирование — перед стартом спринта продакт-оунер обозначает цели (инкремент), и встреча проходит с фокусом на этом инкременте спринта. Команда оценивает задачи, например в сторипойнтах (Story Points). Сама оценка может происходить на этапе планирования или заранее, в рамках груминга (см. ниже). После оценки команде нужно понять, какие она берёт задачи для выполнения инкремента. Если это невозможно в рамках спринта, то продакт-оунер меняет инкремент или принимает решение об увеличении длительности спринта.
Груминг — уточнение и формулировка задач, возможно, декомпозиция. В отличие от планирования и митингов, для этих встреч нет конкретных указаний, в какой момент их стоит проводить. Тем не менее основная цель — сделать задачи более прозрачными и лучше подготовится к планированию.
Митинги (стендапы) — ежедневная встреча, на которой команда разбирает текущие задачи, чтобы выявить проблемы в процессе. Длятся такие церемонии, как правило, 10–15 минут. Каждый участник рассказывает, что делал вчера и что планирует сегодня. Чаще митинги проводятся утром, но иногда команды их смещают на день или вечер. Такие встречи также фасилитирует скрам-мастер, чтобы участники чувствовали себя комфортно и встреча не затягивалась. Если, например, специалисты по бэкенду и фронтенду начинают детально обсуждать методы, то им предлагают назначить для этого разговора отдельную встречу.
Ретроспектива спринта — на этой встрече команда обсуждает, достигла ли инкремента, что получилось хорошо и не очень, а также что сделать, чтобы улучшить процесс. Цель ретроспективы — понять и проанализировать процессы и ошибки, подумать, как их предупреждать.
Демо — показ инкремента за один спринт или несколько. Демо может быть внутренним, с участниками близких команд (чтобы все понимали, что делают коллеги), или внешним — перед заказчиком.
Когда полезен скрам
Скрам хорош, когда нужно постоянное улучшение продукта. Например, у нас есть мобильное приложение и мы работаем над ним: исправляем баги и добавляем новые фичи. Цель нашего процесса — сделать продукт ещё лучше.
Скрам не подойдёт, когда не нужно ничего нового в процессах, а всё идёт по алгоритму. Например, мы делаем лендинги и процесс у нас выглядит так:
Мы хорошо представляем, сколько занимает каждый процесс. А ещё нам сложно приоритизировать задачи. Так что нет нужды в таком подробном планировании, как в скраме. В этом случае лучше применить другой подход — канбан.
Если вы решитесь внедрить скрам, то стоит знать о возможных сложностях:
Скрам — это относительно молодой подход к разработке, который постоянно развивается. У вас получится его внедрить, несмотря на все трудности, если он действительно подходит для ваших процессов. Он сделает работу команды удобнее, а процессы — прозрачнее.
Полная схема scrum — работа с бэклогом и релизный цикл
В четырнадцатой статье серии «Менеджмент цифрового мира» я расскажу, откуда появляется бэклог и как с ним работать для получения реалистичного прогноза на итерацию, а также про планирование цикла релизов. И этим завершу рассказ про схему scrum.
Отмечу, что это будет расширенный вариант схемы, по сравнению с тем, что я рассказывал в предыдущих статьях, и он обычно не входит в рассказ для начинающих и тренинг для скрам мастера. Тем не менее, он не является каким-то секретным знанием, все это можно найти в материалах для Product Owner и даже в продвинутой версии тренинга для них.
Я в 2013 услышал все это как раз на тренинге Джефа Паттона, и был уверен, что это входит в стандартную версию. Но потом мне объяснили, что это мне просто крупно повезло, а стандартные тренинги на сертификат Product Owner, который проходило несколько моих знакомых содержит гораздо меньше материала. Собственно, в этом и состоит смысл проходить даже начальные тренинги у топовых специалистов-практиков – они расскажут много больше, чем обычный тренер. И мне повезло учиться Scrum у Джефа Паттона и Хенрика Книберга, я им очень благодарен, как и другим топовым специалистам, на тренингах которых я был – Ивару Якобсону, Джеффу де Люка и другим.
Возникает естественный вопрос: а насколько подробно необходимо прорабатывать задачи, кто именно их оценивает. На этот вопрос есть следующий функциональный ответ: содержание задачи должно быть проработано настолько, чтобы (а) Product Owner был уверен, что выполнение этих работ принесет стейкхолдерам желаемую ценность и (б) Команда могла оценить трудоемкость выполнения этих работ на планировании. Не меньше, но и не больше. Потому что именно на основании оценки задач и принимается решение, что помещается в спринт, а что – нет.
Как мы говорили, в Scrum деятельность состоит из выполнения задач, помещенных в Product backlog. Каждая из них несет некоторую ценность и имеет содержание – набор работ, которые надо выполнить. Откуда же появляется бэклог?
Достижение цели – и есть ценность. Формулировки – важны. Классический примеры из новейшей мифологии касаются Стива Джобса. «Я хочу слышать музыку, чтобы получать удовольствие», а вовсе не иметь 100500 записей в своей коллекции – идея, которая породила iPod.
Как легко заметить, в формулировке для iPod часть про роль – отсутствует. Это не значит, что она не обязательна, просто она появится наследующем уровне детализации – вам надо описать представить пользователей, и для этого есть техника персонажей: вы описываете типичного представителя социальной группы и его потребности относительно продукта, в случае iPod – какую музыку любит, где и как много слушает, какое нужно разнообразие и так далее. Техника персонажей требует олицетворения и именования конкретного человека, за которым будет стоять группа, соотнесение его с социумом, очень полезно, чтобы у него появилось лицо, и вообще вы могли говорить от его имени. Эта техника возникла с развитием массового web при работе с User eXperience (UX), но может применяться для любых продуктов и услуг, а не только в IT.
В целом вы детализируете свою ценность по группам пользователей и по составу, но при этом придумываете принципиальный способ реализации, это как раз часть о том, что именно делает пользователь и каким образом. Без особых подробностей, но идея должна быть реализуема, иначе это фантазии.
Для уже существующего бизнеса вместо ценности для пользователей можно использовать продвижение по векторам Objectives and Key Results (OKR) для развития бизнеса. Например, если стоит задача захвата регионального рынка, то вы планируете разные рекламные и маркетинговые акции с целевыми аудиториями и ожидаемым эффектом, но при этом не надо забывать о насыщении рынка количеством товара, адекватным прогнозируемому росту спроса. И так далее.
Далее есть интересный такт – последовательность захвата мира. Вы определяется последовательность, в которой группы людей начнут использовать ваш продукт, и причины, по которым они это сделают. При этом учитываете, что люди начинают использовать новое по разным причинам, каждому персонажу нужна своя киллер фича: одним важно, чтобы было прикольно, другим – чтобы лучше, чем у аналогов, а третьим – чтобы было в тренде. Для того, чтобы определить последовательность, есть хорошая техника – story mapping, в которой вы раскладываете на доске карточки с фичами, привязывая их к релизам.
Заметим, что фичи бывают трех категорий: одни привлекают пользователей, другие обеспечивают основной функционал, а третьи – обеспечивают целостность работы. Прием платежей в интернет-магазине вовсе не нужен покупателям, для них ценность – товар и доставка, но без оплаты оно не работает и оплата должна быть удобна. Фичи разных категорий реализуются по-разному, киллер фича должна привлекать пользователей, а поддерживающая – лишь не раздражать. Поэтому полагания о классе фичи тоже надо запомнить.
Дальше идет такт оценки трудоемкости. Оценка идет по придуманной принципиальной реализации, и обычно выполняется по аналогии, детализация для более точной оценки на этом этапе отсутствует. Технически это может быть planning poker, о котором я расскажу дальше, или оценка экспертами. Оценка приближенная, поэтому единицы оценки – грубые, обычно в человеко-неделях. Из оценки получаются сроки релизов, в которые необходимо заложить резервы, учитывая приближенные оценки и высокую степень неопределенности в реализации. Они обычно оказываются слишком долгими, особенно для первого, и идет несколько итераций по свертыванию плана. Особенно важно на этом этапе не свертывать план за счет уменьшения резервов, потому что такой план будет не реалистичным.
Важно, чтобы на такте оценки, а лучше – раньше в процессе участвовало ядро будущей команды разработки. Если же ядро команды появляется позже, то с ним нужно заново пройти такт оценки, получить совсем другие цифры и разобраться с расхождениями – это лучше сделать до старта проекта. Впрочем, даже если этого не сделать, итерационная разработка по Scrum или другим Agile-методам за 2-3 итерации проявит проблемы планирования, в отличие от классического проектного подхода, в котором они обычно выясняются к концу проекта.
В целом начальное наполнение бэклога и планирование релизов занимает не так много времени, не больше недели работы нескольких экспертов и стейкхолдеров, часть из которых войдет в ядро будущей команды. Важно, чтобы в составе были не только реализаторы, но и те, кто представляет потребителя и рынок. Для начального планирования часто проводят отдельную сессию на 1-2 дня, центром которой является story mapping. Но это хорошая техника, а вовсе не обязательная часть метода. Возможна просто работа группы экспертов, вместо story mapping можно применять сортировку списка функций. Однако, чего нельзя делать – это заменять ценность на функции и забывать о группах пользователей, которым релиз несет ценность.
Заметим, что в описанной выше технике практически нет специфики IT, ее можно применять для планирования рекламных компаний, создания коллекций одежды и в целом развития бизнеса, особенно при использовании OKR вместо ценности, о котором я писал выше.
Отмечу, однако, что описанное выше нельзя рассматривать как исчерпывающую инструкцию по созданию продукта. Это лишь часть, создание продукта имеет много других аспектов, о которых можно посмотреть бизнес-модель Александра Остервальдера или другие.
В результате описанного выше процесса, который инода называют нулевой итерацией, у вас появляется начальное наполнение бэклога и теперь можно запускать спринты, которые объединяются в более крупный релизный цикл, как это изображено на полной схеме Scrum.
Почему релизы не выпускаются каждую итерацию, если она итерация должна поставлять ценность? Дело в том, что темп выпуска релизов определяется не внутренней скоростью разработки, а характером взаимодействия с рынком – проведением рекламных компаний, привлечения групп пользователей и так далее. Все это разворачивается в собственном темпе. То же можно сказать и про корпоративную разработку: внедрение нового функционала требует изменения бизнес-процессов и обучения пользователей, и эти процессы разворачиваются в собственном темпе. При этом технически новый функционал уже может быть в продукте.
Релизный цикл накладывает свой отпечаток на спринты, могут появляться отдельные спринты стабилизации и выпуска релизов, в некоторых проектах после выпуска может быть предусмотрен спринт срочных доработок по запросам пользователей, или даже переключение в потоковую обработку задач до стабилизации.
Как написано выше, предварительный бэклог наполнен крупными задачами, для которых известен только принципиальный способ реализации. Они несут значительную долю неопределенности, которая недостаточна для уверенного планирования спринта. Поэтому до планирования задачи бэклога, которые с большой вероятностью будут включены в спринт, необходимо дополнительно детализировать.
Однако, использование только функционального ответа недостаточно, потому что разные люди будут по-разному давать ответ на этот вопрос. Поэтому хорошей практикой является разработать чек-лист Definition of Ready, формулирующий критерии готовности задачи к планированию.
За подготовку и необходимую детализацию задач отвечает Product Owner. Как уже говорили, она выполняется не заранее, а по мере продвижения проекта только для ближайших спринтов. Потому что детальные проработки проекта целиком имеют печальное обыкновение сгнивать раньше, чем добираются до реализации, и оказываются бесполезной работой.
Если такая подготовка задач к будущему планированию требуют заметных трудозатрат, то их надо планировать в предыдущим спринте, а если ограничивается обсуждениями, то отдельное время не выделяется, оно учитывается как общие накладные расходы. Процесс такой подготовки называется backlog grooming или backlog refinement. Груминг – первоначальное название, и оно соответствует сути, однако у него есть негативные сленговые коннотации, поэтому в официальных документах оно было заменено на refinement, подробности можно прочитать в этой статье.
Подготовка бэклога показана на моей рисовке схемы отдельным процессом, хотя часто ее помечают просто надписью на содержании спринта. Этот процесс требует организации. Простой способ – добавить к скрам-доске три колонки слева, в первую из которых Product Owner будет вывешивать задачи, ожидающие подготовки, во второй – те, которые готовятся на данный момент и в третьей – готовые к включению в будущий спринт. Но если процесс более сложен и требует внешних согласований, то такой способ может оказаться недостаточен. Тогда для подготовки бэклога можно организовать отдельный Kanban-процесс – об этом есть хороший доклад Алексея Пименова на SECR-2016 «Discovery Kanban для управления беклогом Scrum-команды».
Еще один вариант организации подготовки бэклога – уже упоминавшийся в статье «Завершение спринта в Scrum – демо и ретро» splitting sprint, разделение спринта на два со сдвигом.
Об оценке трудоемкости следует сказать отдельно. Она может выполняться в человеко-часах, в том числе в разрезе конкретных специалистов. В этом случае понятно, как определять, сколько задач поместиться в спринт: у нас есть общий ресурс часов команды, с учетом текущих отпусков, есть нормированные накладные расходы и резерв на регулярные потоки работ, если команда их делает, и дальше мы просто учитываем загрузку специалистов. Такая оценка практикуется, при этом, однако, важно не стремиться к излишней точности оценки.
Обычно это достигается применением карточек, где оценка дана в числах Фиббоначи (1, 2, 3, 5, 8, 13, 20, 40) или степенями двойки. Но практика показывает, что при относительно однородном потоке задач не менее точной, зато гораздо более быстрой является оценка не в часах, а условных единицах Story Point или в условных размерах: S, M, L, XL. При этом на нескольких спринтах эта оценка калибруется и емкость спринта или скорость команды определяется именно в таких единицах. Практика показывает, что члены команды могут давать оценку в размерах даже для задач, в которых они не являются специалистами-исполнителями, обучаясь на предыдущем опыте работы.
А еще опишем процедуру оценки, для этого используется planning poker: после представления задачи члены команды выкладывают карточки с оценками, а потом одновременно их переворачивают. При больших расхождениях идет обсуждение, обычно это означает, что разные члены команды поняли задачу сильно по-разному, что и выясняется в обсуждении. Потом следует повторное голосование.
На планировании вполне вероятной является ситуация, когда оценка задачи получается слишком дорогой для ее ценности. Тогда следует такт обсуждения с Product Owner, который на планировании представляет интересы стейкхолдеров. Во-первых, бывает, что у стейкхолдеров есть на этот случае План-Б, и задачу просто не нужно делать. Во-вторых, возможно, команда может предложить какое-то более легкое решение для реализации, которое удовлетворит основные потребности – правило Парето говорит, что чаще всего это возможно. Это – конструктивное обсуждение.
А вот переход в этом случае к различным способам давления чаще всего не имеет смысла. Потому что наиболее распространенный результат – команда соглашается, а потом просто не делает. И в результате вместо четкого представления о том, что какой-либо функционал не будет получен через две недели, стейкхолдеров обнаруживают это постфактум, две недели спустя, когда они рассчитывали его получить. Не обязательно тот, по поводу которого было давление – может оказаться, что его сделали, но не сделали что-то другое. А если не сделали именно его – то на него при этом уже затрачены определенные ресурсы, и далее надо доделывать или выбросить.
Конечно, может оказаться, что сознательная команды сделает этот функционал за счет личного времени. Но, как показывает практика, на это может сработать один-два раза, а вот на регулярной основе это приводит к негативным последствиям: либо команда выгорает и производительность падает, а сотрудники уходят, либо команда начинает систематически завышать оценки, чтобы было, куда отступать при давлении. В любом случае, прозрачность процесса и сотрудничество в достижении цели – разрушается, что разрушает эффект использования Agile-подходов.
Вообще надо отметить, что планирование представляет собой заключение контракта на спринт между командой и стейкхолдерами, при этом интересы стейкхолдеров представляет Product Owner. Этот контракт может иметь разную жесткость. В свое время была популярной идея о том, что «настоящая команда» на планировании всегда дает обещание, commitment, которое потом выполняет почти любой ценой. Такой взгляд очень нравится стейкхолдерам и, на первый взгляд, отвечает их интересам. Однако, практика показывает, что это неверно. В долгую это ведет к выгоранию команды либо к сознательному завышению оценок, в котором еще и не сознаются, тратя выигранное время по своему усмотрению и превращая работу в agile-курорт. И этому есть системная причина – длинный хвост распределения в оценках IT-работы, о чем есть хороший доклад Андрея Бибичева «Пуассоново горение сроков».
Конечно, планирование спринта обычно не является заключением какого-то принципиально нового контракта, речь обычно идет лишь о целях и объеме работ на спринт. Однако, в общем случае, стейкхолдерами проекта после любого спринта может быть принято решение о прекращении проекта.
И в заключении этой статьи я хочу еще раз обратить внимание на то, что выполнение состава работ, которым наполнена задача, вовсе не означает, что ценность получена. Начинали наполнение бэклога мы именно с ценности, которую выполнение задачи должно принести пользователям, клиентам или потребителям. Ценность – это решенная проблема или предоставленная возможность. По мере проработки бэклога мы придумали способ получить ценность, сначала – принципиальный, потом – детальный, потом реализовали это. Но при этом наш придуманный способ остается гипотезой, и требует экспериментальной проверки реальным потребителем. И может оказаться, что требуются какие-то дополнительные работы.
Мы думали, что пользователь сформирует список из 10-20 любимых песен для запуска по циклу в фоне, а оказалось, что у многих есть несколько списков для разных настроений, и любимое произведение в одном состоянии превращается нестерпимым в другом. Мы сделали специальную форму для оформления заказов с доставкой со склада на тренажеры прямо из магазинов, а оказалось, что сотрудники магазинов по-прежнему звонят в офис и резервируют товар по телефону, а только потом заполняют форму. Потому что боятся, что пока они будут оформлять заказ и подробности доставки, тот единственный тренажер уйдет по другому назначению, и не хотят, чтобы покупатель почувствовал тоже самое, что чувствуют многие из вас, когда после заполнения сведений о пассажирах при покупке билетов получают сообщение, что билеты уже проданы или подорожали…
То есть уже после реализации оказывается, что создание ценности требует дополнительных объемов работ. И на это тоже надо закладывать резервы при планировании. Но если у вас задачи похожие, то статистика позволит оценить качество, с которым команда превращает ценность в содержание работ, и требуемый размер буфера.
Отметим, что важно закладывать общий буфер, а не резерв на каждую задачу: дело в том, что имея по задаче оценку с резервом, разработчики всегда испытывают искушение повысить качество реализации, если они сделали задачу быстрее оценки. А если задача оказалось сложной – то превышают оценку. По этой же причине, кстати, детальные оценки на планировании спринта в человеко-часах хуже оценки в размерах или условных единицах.
На этом я завершаю описание схемы Scrum. В следующей статье мы переключимся от описания методов и практик к описанию мест, в которых целесообразно применение Agile-команд в компаниях. Особенно в ситуациях, когда речь идет о постепенном изменении организации в большой компании, которое не стоит делать революционно. А в последующих статьях – снова вернемся к методам, у нас впереди Kanban, затем – фреймворки масштабирования Agile и много другого материала, включая рассказ о кейсах трансформации. Продолжение следует.