Спринт сколько длится

Содержание

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

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

Спринт в методологии Scrum

Спринт — короткий промежуток времени, итерация, в течение которой команда выполняет конкретный объем работы.

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

Сколько должен длиться спринт?

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

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

Продолжительность спринта должна быть фиксированной. Однако следует иметь в виду, что поиск оптимальной продолжительности спринта и ритма может занять какое-то время.

Как работать по спринтам?

Планирование

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

У каждого спринта должна быть своя цель. Например, разработать конкретную часть — инкремент, продукта или внедрить новый функционал в сервис. В ином случае, можно установить какую-то измеряемую норму: к примеру, количество закрытых задач или story points.

Ход работы

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

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

Итоги спринта

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

четко достичь целей спринта;
перевыполнить установленный план;
не успеть вовремя.

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

Практикующие Scrum-команды рекомендуют при планировании спринта закладывать 10% рабочего времени на именно устранение технического долга.

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

Разделяй и властвуй, или что такое спринт в Scrum

Если вам нужно регулярно обновлять продукт и оперативно вносить в него изменения, можете попробовать разделить работу на части — итерации. А для управления ими использовать Scrum-спринты. Подготовили для вас гайд, в котором расскажем: что такое спринт, какой должна быть продолжительность спринта и как управлять спринтами, используя Кайтен.

Начнем с теории

Чтобы не запутаться, предлагаем разобраться с базовыми терминами: Agile, спринт и Scrum.

Agile — методология, набор практик и методов для улучшения производимого продукта. Подробнее о подходе рассказали здесь, а подробнее про 10 моделей управления проектами здесь.

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

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

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

Scrum sprint (спринты) — это период времени, в который команда выполняет определенный объем работы шаг за шагом. Подробнее о спринтах расскажем в блоке ниже.

Получается, если вы хотите разрабатывать продукт или услугу согласно Agile-подходу, вы должны выбрать фреймворк (Scrum или Kanban). Если выбираете Scrum, то вам нужно разбить рабочий процесс на спринты.

С теорией разобрались, теперь подробнее поговорим о спринтах в методологии Scrum.

Спринт в методологии Scrum

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

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

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

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

Если говорить о времени, то согласно руководству спринт может длиться от 2 до 4 недель. Количество итераций зависит от продукта и сложности его реализации, строгих правил нет. Обычно спринты сменяют друг друга, как месяцы: заканчивается один, и сразу же начинается другой.

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

Как только команда заканчивает спринт, разработчики проводят ретроспективу спринта — об этом поговорим чуть позже.

Кто участвует в Scrum-спринтах

Существует три типа участников Scrum-проекта:

владелец продукта,
скрам-мастер,
команда разработчиков.

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

подсчет ресурсов (ПО, времени, кадров) для успешного выполнения каждого спринта;
отслеживание изменений в требовании клиента к продукту;
предоставление четких ТЗ команде.

Скрам-мастер. Он направляет общение специалистов в нужное русло. Можно сказать, что это своеобразный мост между владельцем продукта и разработчиками. Еще одна задача Scrum-мастера — рассказать сотрудникам о правилах и ценностях фреймворка, чтобы работать по Scrum было комфортно. Подробнее о задачах этого специалиста можно почитать по ссылке.

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

Внутри Kaiten есть все необходимые инструменты для работы по Scrum

Как проводится спринт

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

Этап 1. Планирование

Продолжительность встречи — от 2 до 8 часов (в зависимости от продукта и размера команды). На ней присутствуют все члены команды: разработчики, владелец продукта и скрам-мастер. Но что же нужно обсуждать?

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

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

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

После чего вся скрам-команда формирует Цель спринта и Бэклог для достижения поставленной цели.

Sprint Backlog — список задач, которые команде нужно выполнить за один спринт. Каждая задача отображает элемент или этап, без которого не получится реализовать продукт.

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

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

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

Чтобы упростить планирование, можно использовать ICE-метод — нужно оценить каждую задачу по 3 параметрам:

I — Impact, показывает, насколько идея положительно повлияет на ключевые показатели, которые нужно улучшить (продажи, узнаваемость и др.).
E — Effort, помогает оценить сколько усилий и ресурсов потребуется для реализации этой идеи.
C — Confidence, демонстрирует, насколько команда уверена в легкости реализации каждой задачи. Если разработчики понимают, что не смогут выполнить одну из задач, не стоит включать ее в спринт.

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

То, как команда будет реализовывать поставленную цель, разработчики решают сами.

Этап 2. Исполнение и отслеживание прогресса

После организации, команды приступают к работе. Главное в этом этапе — отслеживать промежуточные результаты. Для этого нужно проводить ежедневные мероприятия — Daily-встречи (или Daily Scrum).

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

Что следует обсудить на таком синхроне:

Что сотрудник сделал с момента прошлой встречи для достижения цели?
Что разработчик планирует сделать сегодня?
Есть ли какие-то препятствия для его работы (или работы команды)?
Если да, то как их решить?

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

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

Этап 3. Обзор и тестирование (Sprint Review)

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

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

Этап 4. Ретроспектива спринта

Ретроспектива проводится на стыке спринтов. На жизненном примере, это ночь 31 декабря, когда разработчики провожают старый спринт и планируют новый.

Важно! Ретроспектива — это не публичная порка и не обсуждение проекта под бокал шампанского. Цель встречи в том, чтобы Scrum-команда:

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

Продолжительность ретроспективы: 1,5-3 часа. Чтобы встреча прошла успешно, скрам-мастер может распределить тайминг на такие шаги:

Шаг 1. Приветствие и создание приятной атмосферы, чтобы «включить» всех участников в обсуждение. К примеру, можно узнать, как коллеги оценивают прошедший спринт от 1 до 10, или спросить с каким словом ассоциируется спринт. Открытие занимает 10% от общего времени.

Шаг 2. Сбор данных — возможность высказаться каждому члену команды. Например, рассказать о плюсах и минусах прошедшего спринта или поделиться мыслями о том, что можно улучшить. Время на этап — примерно 40% от общего.

Шаг 3. Генерация идей. Время — 20% от встречи. За это время важно обозначить проблемы, возникшие в ходе работы, и найти способы их решения. Для этого можно использовать разные техники, например, мозговой штурм или составить матрицу идей.

Шаг 4. Выбор оптимальных решений. Тайминг — 20% времени. Сотрудники выбирают те идеи, которые могут пригодится в следующем спринте и формулируют из них четкие задачи. К примеру, если новый сотрудник Маша выложила непроверенный код, можно попросить отдавать его на тестирование опытному коллеге Васе.

Шаг 5. Завершение встречи занимает примерно 10% времени. Нужно подвести итоги и собрать обратную связь о ретроспективе.

Советы для проведения успешного спринта

Чтобы спринт прошел успешно, нужно:

Убедиться, что команда правильно понимает цель спринта. Если участники спринта не поймут, зачем они это делают, разработчики не смогут выдать крутой результат.
Визуализировать процесс работы, используя Scrum-доску. На ней размещаются задачи и отслеживается их статус в рамках текущего спринта. Доска может быть виртуальной или реальной.
Сделать четкий и понятный бэклог. В идеале для каждой задачи проставить дедлайн, приоритет и обозначить зависимость задач друг от друга. Если не сможете организовать прозрачный рабочий процесс, спринт будет похож не на бег по дорожке стадиона, а пробежку по болоту с завязанными глазами.
Отбрасывать задачи, которые блокируют карточки вашей команды. В идеале не брать на спринт задачи связанные с работой смежных команд (дизайнеры, бухгалтерия и т.д.).
Фиксировать на доске все идеи, решения или планы, которые обсуждаете на встречах. Так вы точно не потеряете важную информацию.
Трезво оценивать силы команды, учитывая количество сотрудников в штате, отпуска и время на общие собрания с коллегами. Если понимаете, что не успеете выполнить задачу за спринт — не берите ее в работу.
Не зацикливаться на скорости. Главное, чтобы все участники проекта работали в одном направлении. Прислушивайтесь к сотрудникам — если коллеги не успевают, всегда можно внести коррективы по необходимости.
Анализировать проделанную работу, чтобы в дальнейшем оптимизировать и рабочие процессы, и итоговый продукт.

Как визуализировать спринты

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

Если вам удобнее работать с онлайн-сервисами, можете сделать виртуальную доску в Кайтен. Например, у нас есть готовый шаблон для работы по Скраму. Он состоит из доски Backlog и Sprint с тремя колонками: «Бэклог», «В работе» и «Готово».

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

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

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

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

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

Scrum-метод управления проектами

Но такой подход оптимален не для всех направлений проектов и не для всех команд. Порой требуются более гибкие методологии управления. Об одной из них мы рассказываем в этой статье.

Что такое Scrum?

Метод Scrum (термин пришел в бизнес из регби) – это фреймворк управления проектами, авторами которого являются программисты Джефф Сазерленд и Кен Швабер. Метод предназначен для того, чтобы обеспечить эффективность и гибкость управления проектами в условиях неопределенности и быстро меняющихся требований.

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

В данном случае Scrum (Скрам) является набором конкретных практик и правил, которые помогают организовать работу небольшой команды в рамках Agile. В частности, Scrum включает в себя следующие отдельные элементы:

Метод Скрам можно рассматривать как набор инструментов, с помощью которых можно создавать проекты, основанные на принципах Agile.

Принципы Scrum и роли в команде

Методология Scrum базируется на cледующих основных принципах и ролях:

Участие скрам-мастера. В Scrum есть скрам-мастер, который отвечает за координацию работы команды и обеспечение того, чтобы каждый участник следовал скрам-процессу. Скрам-мастер – это человек, который должен быть нейтральным и объективным, чтобы команда могла сохранять свою независимость, концентрировать внимание на задачах, поддерживать связь друг с другом и правильно двигаться к цели.
Короткая итерация, или спринт. Scrum предполагает короткие итерации – спринты – продолжительностью от одной до четырех недель. В течение спринта команда работает по Scrum над одной функцией или задачей, и каждый ее член концентрируется на достижении общей цели.
Владелец продукта, или продакт-оунер (англ. product owner). Он отвечает за определение приоритетов и постановку целей для команды. Он должен постоянно быть на связи со стейкхолдерами (представителями заказчика) и адаптировать все требования к будущему готовому продукту в соответствии с их изменениями.

По методике Scrum формируется команда. Оптимальная команда в Scrum состоит из 7 человек. Особенность членов команды заключается в том, что в Скрам на разных этапах работы по реализации проекта они могут успешно меняться ролями и взаимозаменять друг друга. Благодаря этому возможно поддержка интереса каждого участника группы к работе.

Состав Scrum-команды включает в себя следующие роли:

Скрам-мастер (Scrum Master)

Скрам-мастер – это один человек, который отвечает за:

организацию рабочего процесса;
управление командой;
разрешение конфликтов.

Он должен помочь команде в:

планировании спринтов;
определении работы;
отслеживании прогресса.

Скрам-мастер в Agile также должен обеспечивать прозрачность процесса разработки продукта и коммуникацию между всеми участниками команды и заинтересованными сторонами.

Владелец продукта (Product Owner)

В Scrum должен быть один владелец продукта. Это человек, который отвечает за:

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

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

работать с бэклогом продукта;
расставлять приоритеты задач;
управлять рисками.

Разработчики (Developers)

Команда разработчиков в Scrum занимается реализацией функциональности продукта в рамках спринта. Члены команды должны:

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

Разработчики в Scrum также должны участвовать в тестировании продукта и общаться с другими членами команды.

Тестировщики (Testers), или специалисты по обеспечению качества (Quality Assurance Engineers)

Специалисты по обеспечению качества в Scrum помогают команде разработчиков выявлять и устранять все проблемы, связанные с качеством продукта. Тестировщик в Scrum:

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

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

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

Менеджер проекта (Project Manager)

Менеджер проекта в Scrum отвечает за планирование и контроль того, как идет проект, а также за управление ресурсами и рисками. В его обязанности входит:

работа с бюджетом;
определение цели и задачи проекта;
контроль качества продукта.

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

Артефакты и ценности Scrum

Артефакты Scrum – это документы и материалы, созданные в ходе командной работы над проектом. Они включают в себя:

бэклог продукта;
пользовательские истории, или user stories;
требования к качеству;
планы спринтов;
и т.д.

Артефакты помогают команде:

организовывать командную работу;
отслеживать прогресс;
принимать решения на основе фактов.

Бэклог продукта в Scrum

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

Бэклог помогает команде определять приоритеты и планировать работу, а также отслеживать прогресс проекта.

Спринт в Scrum

Спринт в Scrum – это короткий цикл работы над проектом, который обычно длится одну, две, три или четыре недели. За это время команда должна выполнить определенную задачу или набор задач и представить результат в виде продукта с определенным набором функций.

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

Бэклог спринта в Scrum

Бэклог спринта в Scrum – это часть бэклога продукта, которую выбирают для работы в текущем спринте. Он включает в себя задачи, которые необходимо выполнить за время спринта, и определяет объем работы, который команда должна выполнить за этот период.

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

Инкремент в Scrum

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

Инкременты продукта помогают Scrum команде видеть прогресс в создании продукта и оценить результаты работы.

При работе с системой Scrum важно помнить о ее основных ценностях, которые включают в себя:

Ориентированность на клиента. Скрам-команды работают над созданием ценности для своих клиентов, постоянно улучшая продукт и адаптируясь к изменяющимся требованиям.
Самоорганизация. Scrum-команды сами организуют свою работу и принимают решения на основе своих знаний и опыта.
Фокус на качестве. Scrum-команды стремятся к созданию высококачественных продуктов, и для этого применяются различные методы тестирования и отладки.
Коммуникация. Участники Scrum-команды активно общаются между собой и со всеми заинтересованными лицами, чтобы понимать требования и ожидания друг друга.
Итеративность и адаптивность. Scrum-процессы основаны на коротких итерациях, которые позволяют группе участников быстро реагировать на изменение требований и адаптироваться к новым условиям.

Для каких проектов подходит Scrum

Применять Scrum лучше всего для проектов, которые обладают следующими характеристиками:

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

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

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

Пример внедрения Scrum

Рассмотрим применение Scrum на примере компании, которая занимается разработкой нового мобильного приложения. Заказчик приложения, которым выступает один из владельцев компании, имеет общее представление о том, каким функционалом должен обладать конечный продукт, но пока до конца не знает, каким именно он должен стать. Аналогов такого приложения на рынке еще нет, а потому ориентироваться не на кого.

На первом этапе Владелец продукта и Скрам-мастер определяют:

Бэклог продукта. Он необходим для понимания того, что клиент хотел бы получить. Бэклог не является конечным и используется, как отправная точка для старта проекта – может изменяться в ходе реализации работ по продукту.
Длину спринта. Для начала решили определить ее в 1 неделю. Метод Scrum позволяет изменить длину спринта в большую или меньшую сторону в процессе реализации проекта в зависимости от того, какие результаты показывает команда в отведенный спринтом срок.
Бэклог спринта. Говоря проще, это список задач и действий, которые команда обязательно должна начать и завершить в течение одной недели. Запланированные задачи ранжируются по степени важности, а их количество составляется таким образом, чтобы не перегрузить команду. Такой подход избавляет от необходимости делать в компании что-либо в авральном режиме сразу, как упадет задача.

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

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

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

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

Главные сложности работы в Scrum

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

Специалисты Выделяют следующие ключевые сложности по внедрению Scrum:

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