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

Главное. Что такое спринт в скраме

Как говорится в Руководстве по Скраму, спринт — это временной отрезок длительностью месяц или меньше, в течение которого создается «готовый», то есть пригодный к использованию и выпуску инкремент продукта. Для эффективной разработки спринты должны быть одинаковой длины. Новый спринт всегда начинается сразу после окончания предыдущего.

Во время спринта:

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

Спринт как концепция основывается на теории эмпирического управления. Её применяют, чтобы сделать разработку более предсказуемой и снизить риски. Три кита теории эмпиризма — прозрачность, инспекция и адаптация. Именно инспекция результатов работы и адаптация их под потребности пользователей являются залогом успеха спринта. К сожалению, именно эти принципы недопонимают чаще всего, вместо них полагаясь на мифы.

Спринт в Скраме - BrainRain 2018

Миф первый. Обратную связь иногда можно игнорировать

Десятилетиями успех проектов по разработке измеряли с помощью «золотого треугольника менеджера», то есть по соотношению времени, стоимости и объёма работ. В результате погиб не один проект и появился не один бесполезный продукт: этот треугольник относится к успеху продукта лишь опосредованно.

Но как тогда сделать проект успешным? Прежде всего, помнить о том, что скрам создан для разработки креативных ПРОДУКТОВ (не проектов), как говорится в Руководстве по скраму.

Как стать классным владельцем продукта? Говорим об этом на тренинге Professional Scrum Product Owner

Главная цель в применении скрама — создать продукт, который будет иметь спрос у пользователей и давать достаточную окупаемость инвестиций (ROI). Самый серьезный риск в разработке — выпустить продукт, который никому не нужен. Скрам уменьшает этот риск с помощью частых циклов обратной связи. Чтобы разработать востребованный продукт, скрам-команда регулярно проводит демонстрации (инспектирует инкремент) во время обзоров спринтов. На этих встречах ключевые стейкхолдеры и конечные пользователи работают с инкрементом продукта. Так мы получаем обратную связь, а владелец продукта корректирует планы — адаптирует бэклог продукта, а иногда и план релиза.

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

Спринт в Скраме

Миф второй. Спринт провален, если в нём не удалось достичь целей

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

Кен Швабер в книге «Софт за 30 дней» (Software in 30 days) так описывает случайности в разработке: «С самого начала у нас есть видение или возможность, которой мы собираемся воспользоваться. Команда разработки создает приложение, чтобы воплотить важнейшие стороны нашего видения. Мы смотрим на инкремент и начинаем думать, как он будет использоваться. Мы обсуждаем, что добавить, чтобы сделать инкремент полезнее. В некоторых дисциплинах это также называется промежуточным контролем. Мы проводим его в каждой итерации».

Если спринт рассматривать как эксперимент, а скрам — как эмпирический процесс, становится ясно следующее:

Проваленным можно назвать спринт, в конце которого мы ничему не научились. При таком сценарии мы не можем инспектировать и адаптировать результаты работы, не можем кастомизировать продукт и процессы.

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

Пример удачного спринта:

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

Пример неудачного спринта:

Команда смогла закончить много функций и выполнить к обзору спринта всё запланированное («благодаря» овертаймам и снижению качества). Но на обзор спринта не пришел никто, кроме владельца продукта. Команда разработки так и не видит реакцию пользователей, а стейкхолдеры слишком заняты, чтобы ходить на обзоры. Нет никакой обратной связи об инкременте. Раз так, то можно и ретроспективу пропустить — у всех и так слишком много работы. А потом — начать новый «успешный» спринт.

Как найти свое место в скраме? Приходите на тренинг PSM, познакомьтесь с методологией как она есть

Миф третий. Спринт не обязательно заканчивается выпуском готового инкремента

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

Спринт ноль

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

Дизайн-спринт

Такой «спринт» начинают, чтобы создать техническую архитектуру — руководство для всего последующего релиза. Этот случай «тяжелее», чем предыдущий: помимо того, что он не соответствует определению спринта, он еще и мешает инспекции и адаптации в последующих спринтах. Опять-таки, наброски по архитектуре и функционалу могут быть полезны как часть видения продукта: так команда избежит риска и наладит диалог со стейкхолдерами. Но не стоит разрабатывать подробный и окончательный дизайн процесса.

Жесткий спринт (Hardening Sprint)

Из всех вольных интерпретаций спринта потенциально опаснее всего именно эта. Концепция пришла из одного популярного фреймворка, и в последних его редакциях относительно жестких спринтов уже есть поправки. Цель такого спринта — добиться готового к выпуску и интеграции инкремента, которого невозможно было добиться ранее. Такая постановка вопроса подразумевает, что в результате каких-то других спринтов могут получаться неготовые инкременты. Так возникает двоякое толкование прозрачности, инспекции и адаптации, а без них команды уже не могут провести ни одного настоящего спринта.

Выводы

  • Тем, кто работает по скраму, нужно создавать действующие творческие продукты, а не проекты.
  • Каждый спринт — это эксперимент. Его результаты обязательно подвергаются инспекции и адаптации.
  • Если результаты спринта нельзя инспектировать и адаптировать, спринт считается неудачным.
  • В результате спринта должен появляться готовый инкремент продукта, а не жестко определенный план последующих работ. На этом основан эмпиризм скрама.

Успешных вам спринтов!

Статья подготовлена по материалам и мотивам:

Переведено и адаптировано командой BrainRain