Что такое Scrum методология?

February 23, 2015

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

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

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

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

Авторы Scrum определили следующие качества:

  • Простой (или незначительный)
  • Ясный, доступный
  • Сложный для изучения (почти взаимоисключающие пункты)

Scrum жизненный цикл

Жизненный цикл Scrum. Источник изображения: www.software-development-resource.com

РОЛИ В SCRUM

В Scrum есть 3 роли:

  • Владелец продукта (несет ответственность за сам продукт и его приоритеты)
  • Команда (несет ответственность за разработку продукта)
  • Scrum мастер (руководит Scrum процессом и устраняет любые препятствия, возникающие в ходе работы)

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

Один из главных инструментов Владельца продукта – это список требований. В нем перечислены задачи для выполнения (такие как История, Ошибка, Задача и т.д.), упорядоченные по приоритету (срочности).

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

Команда разработки (КТ) – это команда профессионалов, которые работают над продуктом. В Руководстве по Scrum (официальном описании методологии Scrum), указаны следующие обязательные для команды разработчиков качества и характеристики:

  • Самоорганизованность. Никто (даже Scrum мастер и Владелец продукта) не может назначать, кто будет превращать список требований в готовый работающий продукт.
  • Многофункциональность и владение всеми навыками, которые необходимы для создания продукта.
  • Ответственность за проделанную работу всей команды целиком, а не отдельных ее членов.

Рекомендованный размер команды – 7 участников (плюс-минус 2). Идеологи Scrum считают, что большие команды тратят слишком много ресурсов на коммуникацию, а при меньшем размере команды возрастают риски (в силу вероятного недостатка необходимых навыков) и снижает объем работы, с которым команда справляется за единицу времени.

SCRUM ПРОЦЕСС

Работа над продуктом в Scrum основывается на спринтах. По окончанию спринта команда должна выпускать очередную рабочую версию продукта. Спринт имеет ограничение по времени (1 – 4 недель), и этот период не изменяется на протяжении всего времени разработки продукта.

Перед запуском каждого нового спринта необходимо проводить планирование, чтобы оценить содержимое и сформировать список требований для спринта. В этот список требований включаются разные элементы (например, История, Ошибки, Задачи), которые необходимо выполнить за этот спринт. Для каждого спринта необходимо ставить цель, которая будет мотивировать команду и будет достигнута только посредством решения задач из Списка требований спринта.

Каждый день необходимо проводить Ежедневное совещание, на котором каждый участник отвечает на вопросы «Что я делал вчера?», «Что я планирую делать сегодня?», «С какими препятствиями я столкнулся?»

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

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

Схематическое представление Scum процесса изображено ниже:

Scrum график

Источник изображения: www.agileforall.com

ВАЖНЫЕ, НО ЧАСТО УПУСКАЕМЫЕ ИЗ ВИДУ КАЧЕСТВА

Многие часто говорят, что методология Scrum вообще не помогает, или ее эффективность ниже ожидаемой. Нужно отметить, что в большинстве случаев это обусловлено следующими причинами:

  • Scrum используется неправильно или не полностью

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

  • Недооценка важности мотивации команды

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

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

  • Scrum используется при разработке продукта, не соответствующего идеологии Scrum

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

НЕ ОГРАНИЧИВАЙТЕСЬ ОДНИМ ИНСТРУМЕНТОМ!

Выбирайте и комбинируйте инструменты так, чтобы вам было удобно! Например, я с трудом могу представить успешную Scrum команду, участники которой не использует большинство приемов экстремального программирования. Многие команды предпочитают организовывать короткие ежедневные собрания, но это прием Scrum. Некоторые Scrum команды описывают проблемы списка требований методом сценариев использования (RUP методология), или ограничивают размер очереди задач (метод Канбан). Да все что угодно, если это работает!

Миямото Мусаси как-то сказал (легендарный самурай 17 века, знаменитый своей техникой фехтования двумя мечами):

  • «У тебя не должно быть любимого оружия. Стать слишком близким с одним из видов оружия - большая ошибка, чем недостаточное знание его.».

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