Скрам: метод управления проектами

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

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

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

Скрам: что это такое, как работает и кому подходит

Что такое Скрам простыми словами

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

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

В Скраме работа организована в спринты - периоды фиксированной продолжительности не более одного месяца.

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

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

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

Правила фреймворка описаны в Руководстве по Скраму 2020 года, подготовленном создателями подхода Кеном Швабером и Джеффом Сазерлендом.

На каких принципах основан Скрам

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

Он опирается на три столпа.

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

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

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

Пять ценностей Скрама

Помимо трех столпов, Руководство по Скраму определяет пять ценностей:

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

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

Кто входит в Скрам-команду

Скрам-команда состоит из людей, совместно отвечающих за создание ценного результата.

В ней предусмотрены три зоны ответственности:

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

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

Владелец продукта

Владелец продукта отвечает за максимизацию ценности продукта, создаваемого командой.

В его обязанности входят:

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

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

Важный нюанс: владелец продукта - один человек, а не комитет руководителей.

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

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

Скрам-мастер

Скрам-мастер отвечает за правильное применение Скрама и повышение эффективности команды.

Он помогает:

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

Скрам-мастер не является руководителем, распределяющим задания между сотрудниками.

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

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

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

Разработчики

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

Это могут быть не только программисты, но и дизайнеры, аналитики, тестировщики и другие профессионалы.

Разработчики отвечают за:

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

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

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

Три артефакта Скрама: как организуется работа

В Скраме предусмотрены три артефакта. Они делают прозрачными планы, выполняемую работу и получаемые результаты.

У каждого артефакта есть связанное с ним обязательство, которое помогает оценивать прогресс.

Бэклог продукта и цель продукта

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

В нем могут находиться:

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

За эффективное управление бэклогом отвечает владелец продукта.

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

Обязательство бэклога - цель продукта.

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

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

Бэклог спринта и цель спринта

Бэклог спринта создают разработчики.

Он включает три составляющие:

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

Обязательство бэклога спринта - цель спринта.

Она обеспечивает общее направление и помогает принимать решения при возникновении изменений.

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

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

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

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

Инкремент и определение готовности

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

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

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

Обязательство инкремента - определение готовности.

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

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

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

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

Пять событий Скрама: как проходит работа

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

Спринт объединяет остальные четыре события.

Спринт

Спринт - это фиксированный период продолжительностью не более одного месяца.

Следующий спринт начинается сразу после завершения предыдущего. Благодаря этому работа развивается в регулярном ритме.

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

Во время спринта действуют важные правила:

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

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

Планирование спринта

На планировании вся Скрам-команда совместно определяет предстоящую работу.

Встреча посвящена трем вопросам.

Почему этот спринт ценен?

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

Что можно завершить за спринт?

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

Как будет выполняться работа?

Разработчики составляют план создания инкремента и при необходимости разделяют крупные элементы на более мелкие задачи.

Результатом становится бэклог спринта.

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

Ежедневный Скрам

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

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

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

Ежедневный Скрам не является отчетом сотрудников перед руководителем.

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

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

Обзор спринта

Обзор спринта проводится ближе к его завершению.

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

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

Эта информация может повлиять на дальнейшее упорядочивание бэклога продукта.

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

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

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

Ретроспектива завершает спринт.

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

Обсуждаются:

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

Например, команда обнаружила, что большую часть времени потратила на исправление ошибок из-за недостаточно четких требований.

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

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

Можно ли менять задачи во время спринта

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

На самом деле Скрам защищает цель спринта, а не первоначальный список задач.

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

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

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

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

Гибкость здесь не означает бесконтрольное добавление любых поручений.

Пример использования Скрама в бизнесе

Рассмотрим условную ситуацию.

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

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

Цель продукта: создать работающую систему самостоятельной записи клиентов.

Команда выбирает двухнедельные спринты.

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

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

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

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

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

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

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

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

Пример условный. Он иллюстрирует работу фреймворка и не описывает реальный проект Platrum.

Как начать работать по Скраму

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

Начать лучше с другого.

Шаг 1. Определить продукт и его цель

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

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

Без понятной цели список задач быстро превращается в набор несвязанных поручений.

Шаг 2. Сформировать Скрам-команду

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

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

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

Шаг 3. Сформировать бэклог продукта

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

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

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

Шаг 4. Договориться об определении готовности

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

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

Шаг 5. Провести первый спринт

Команда выбирает подходящую продолжительность спринта, формулирует его цель и составляет план работы.

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

В конце проводятся обзор результата и ретроспектива.

Шаг 6. Корректировать работу на основании результатов

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

Полезно проверять:

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

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

Когда Скрам подходит бизнесу

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

Например:

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

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

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

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

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

Фиксированные бюджет и сроки сами по себе не запрещают использовать Скрам. Но компании придется учитывать эти ограничения при планировании объема работ и прогнозировании результата.

Распределенная команда также может применять Скрам, если способна организовать необходимое взаимодействие и совместное принятие решений.

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

Чем Скрам отличается от Канбана

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

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

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

Например, команде, создающей новый продукт с меняющимися требованиями, может подойти Скрам.

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

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

Подробнее о работе с непрерывным потоком задач можно прочитать в статье «Что такое система Канбан».

Типичные ошибки при использовании Скрама

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

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

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

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

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

Ретроспектива не приводит к изменениям. Одни и те же препятствия повторяются несколько спринтов подряд, а команда продолжает работать прежним способом.

Общая причина таких ошибок - внимание к внешним атрибутам Скрама при отсутствии его основных механизмов: прозрачности, проверки и адаптации.

Какие инструменты помогают организовать работу

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

Для этого могут использоваться цифровые системы управления задачами.

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

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

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

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

Главное о Скраме

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

Успех применения определяется не количеством встреч и не соблюдением первоначального списка задач.

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

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

Также читайте: Что такое Канбан