Scrum в деталях

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

Scrum — это гибкий и структурированный метод управления проектами. Под каждый проект собирается команда специалистов с распределенными ролями, работающая на общий результат. Разработка ведется спринтами — короткими периодами в 1−2 недели. Промежуточные результаты постоянно оцениваются, а на основе оценки принимается решение о дальнейших задачах. Для множества проектов Scrum будет куда эффективней, чем традиционная «водопадная» модель разработки, в которой все этапы проекта выполняются последовательно, в строго фиксированном порядке. Вот основные причины:

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

Гибкие модели чаще всего сравнивают с водопадной (каскадной) моделью, как наиболее распространенной традиционной методикой управления. Для наглядности мы собрали основные отличия в таблицу:

Основателями методологии SCRUM считают японских ученых Хиротаку Такэути и Икудзиро Нонака. В 1986 году во время наблюдений за компаниями-инноваторами — Fuji-Xerox, Honda и Canon — они заметили, что более эффективны те команды, в которых несколько разнопрофильных специалистов одновременно работают над задачей. А традиционный подход, в котором задача поэтапно переходит от одного специалиста к другому — проигрывает по результатам. Ученые сравнили такой подход со «схваткой» в регби (scrum) — так в игре называют стартовое состояние команд перед подачей мяча.

Первой компанией, где применили Scrum, стала Easel Corporation. В 1993 году Джеффу Сазерленду, Джону Скамниоталеса и Джеффу МакКенну требовалось разработать программный продукт и полностью изменить действующее предложение в рекордный срок — 6 месяцев. В поисках решения Сазерленд наткнулся на статью Такэути и Икудзиро и решил опробовать Scrum на «горящем» проекте.

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

В 2001 году Кен Швабер и Джефф Сазерленд опубликовали Agile-манифест, в котором сформулировали ключевые поинты, которые делают разработку гибкой. Они стали определяющими для методики Scrum:

• Люди важнее инструментов.
  
• Качество продукта важнее подробной документации.
  
• Взаимодействие с заказчиком важнее обсуждения деталей договора.
  
• Реакция на изменения важнее следования плану

Позднее стали появляться организации по продвижению методики: Scrum Alliance, Scrum.org и Scrum.inc. В 2010 г. вышло первое руководство по Scrum, которое продолжает обновляться по сей день.

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

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

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

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

В Scrum-процессах также присутствует scrum-мастер. Он как раз участвует со стороны исполнителя. Его задача — контролировать процессы, вести планирование, проводить ежедневные встречи команды (стендапы) и т. д. — то есть, следить за тем, чтобы все шло по правилам фреймворка. Эта роль не предполагает каких-то дополнительных полномочий по проекту, кроме модерации самого Scrum-а.

В отличие от классической схемы разработки, в которой все делается последовательно в соответствии с четким техзаданием, в Scrum никакого ТЗ не предполагается вовсе. Вместо него есть Backlog (бэклог) — список требований к продукту и главный источник информации для команды разработки.

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

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

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

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

На внедрение Scrum в процессы компании может уйти несколько месяцев. Сроки зависят от того, как сейчас выстроены процессы в компании, от ее размера (внедрить Scrum в бизнесе с 5 сотрудниками очевидно быстрее, чем с 500), от сопротивления внутри компании, от энергии, которую руководитель тратит или готов тратить на внедрение и т. д. Лучше начать с одного небольшого проекта, протестировать методологию на нем, выявить возможные сложности, понять, насколько морально и психологически сотрудники готовы к таким переменам.

Действовать лучше по шагам:

1. Соберите кросс-функциональную команду — такую, в которой специалисты с разной экспертизой будут работать над достижением одной цели. Смысл в том, чтобы команда смогла достичь ее самостоятельно, без привлечения каких-либо еще экспертов. Как правило, в scrum-командах участвуют от 3 до 8 человек. Подключать больше специалистов не стоит — управлять такой командой будет сложно.
   
   
2. Найдите scrum-мастера. Если в компании есть энтузиасты, знакомые с методикой или готовые ее изучить — дайте им шанс. Если добровольцев нет, можно привлечь эксперта со стороны.
   
   
3. Назначьте владельца продукта. У него должны быть реальные полномочия для принятия решений. Если ему придется согласовывать каждый шаг с руководителем — он не будет по факту являться владельцем продукта. Помните, человек должен обладать глубокой экспертизой в бизнесе, должен понимать ценности и задачи создаваемого продукта, уметь их донести до команды и при этом неплохо разбираться в ИТ. И у него должно быть время на полноценное участие в проекте.
   
   
4. Создайте бэклог. Не мельчите задачи, уделите внимание смыслам. Соберите первоочередные задачи минимум на первые три спринта.
   
   
5. Определите спринты. Обычно они длятся от 2 до 4 недель.
   
   
6. Будьте готовы проводить ежедневные стендапы (планерки в Scrum, на которых обсуждаются всего три вопроса: «что было сделано вчера», «что будет сделано сегодня» и «какие есть проблемы»). Они не должны занимать больше 15 минут, хотя в первое время придется сложно — не все привыкли к таким коротким собраниями.
   
   

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

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

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

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