Основные принципы Scrum гибкой методологии разработки. Управление проектами: метод "Scrum"

Методология Scrum. Как управлять проектами? Reviewed by Владислав Челпаченко on Jul 27 Rating: 4.0

Добрый вечер, уважаемые коллеги!

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

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

Что такое Scrum?

Имея дело с управлением проектами и людьми, включая себя, мы руководствуемся какими-либо принципами. Выстраивается определенная структура взаимодействия, контроля, мониторинга и улучшения процесса работы. Одним из методов гибкого управления является «Scrum».

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

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

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

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

Scrum управление проектами - основные принципы

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

Выберите визионера. Обычно это владелец самого продукта. Этот человек обладает видением того, что должно быть на выходе. Он понимает, как должно быть всё устроено, и является путеводной звездой для всего проекта.
Выберите скрам-мастера. Это человек, которые решает все мелкие и многочисленные задачи, устраивает короткие собрания и следит за выполнением самого подхода.
. Найдите тех, кто лучше всего вам подходит для работы над проектом. Scrum подразумевает малое количество участников от 3 до 12.
Создать бэклог. Это список всех требований к продукту по приоритетности. Составляется он с учётом все людей, принимающих участие в создание продукта.
Оцените список задач. Пусть команда определится, что ей необходимо и достаточно ли знаний, умений и информации для реализации каждой из задач. Также задайте сложность каждой задаче, можно сделать это с помощью чисел Фибоначчи: 1, 2, 3, 5, 8, 13, 21. При подведение итогов и сравнению с прошлым опытом необходимо сравнить количество баллов.
Запланируйте спринт. Это краткосрочный забег на 1 или 2 недели, который команда сама планирует. Берётся определённое количество заданий, с которыми по мнению команды она может справиться. Если уже пройдено несколько спринтов, то стоит учитывать количество прошлых баллов. Должна наблюдаться динамика.
Видимость процесса. Очень важно сохранять прозрачность процесса для скорейшего достижения результата. Для этого можно завести скрам-доску с колонками: «нужно сделать», «в процессе» и «сделано». Для этого подойдёт обычная доска в офисе или мобильное приложение Trello.
Ежедневные собрания. Это встреча Scrum-мастера и команды, которая длится не более 15 минут. На ней разбираются несколько основных вопросов: «что делал вчера для спринта», «что будешь делать сегодня для завершения спринта» и «какие препятствия встают перед командой». Это необходимо для быстрого устранения любых проблем скрам-мастером.
Обзор спринта. Это собрание, на котором команда предоставляет свои результаты - что она сделала окончательно по завершению спринта.
Собрание после завершения спринта. На этом обсуждении должны присутствовать все. Главный упор делается на улучшении процесса, а не на поиске виноватых и нерешаемых препятствий. Что можно улучшить? Что поможет ускорить процесс? Что можно внедрить? и так далее. Занесите результаты в бэклог.
Следующий спринт. Начинайте его немедленно с учётом прошлого опыта. Непрерывность, развитие и гибкость - важнейшие параметры скрама.

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

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

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

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

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

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

Когда говорят о методологии Scrum, чаще всего имеют ввиду гибкую методологию разработки ПО, построенную на основе правил и практик Scrum, так что вполне может оказаться что ваш Scrum круче моего Scrum, а также быть от него так же далеким, как ВАЗ 7-ка от BMW 7-й серии:)

Роли в Scrum

В классическом Scrum существует 3 базовых роли:
-Product owner
-Scrum master
-Команда разработки (Development team)

Product owner (PO) является связующим звеном между командой разработки и заказчиком. Задача PO - максимальное увеличение ценности разрабатываемого продукта и работы команды.

Одним из основных инструментов PO является Product Backlog. Product Backlog содержит необходимые для выполнения рабочие задачи (такие как Story, Bug, Task и др.), отсортированные в порядке приоритета (срочности).

Scrum master (SM) является «служащим лидером» (англ. servant-leader). Задача Scrum Master - помочь команде максимизировать ее эффективность посредством устранения препятствий, помощи, обучении и мотивации команде, помощи PO

Команда разработки (Development team, DT) состоит из специалистов, производящих непосредственную работу над производимым продуктом. Согласно The Scrum Guide (документу, являющимся официальным описанием Scrum от его авторов), DT должны обладать следующими качествами и характеристиками:
-Быть самоорганизующейся. Никто (включая SM и PO) не может указывать команде каким преобразовать Product Backlog в работающий продукт
-Быть многофункциональной, обладать всеми необходимыми навыками для выпуска работающего продукта
-За выполняемую работу отвечает вся команда, а не индивидуальные члены команды

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

Процесс Scrum

Основой Scrum является Sprint, в течении которого выполняется работа над продуктом. По окончанию Sprint должна быть получена новая рабочая версия продукта. Sprint всегда ограничен по времени (1-4 недели) и имеет одинаковую продолжительность на протяжении все жизни продукта.

Перед началом каждого Sprint производится Sprint Planning, на котором производится оценка содержимого Product Backlog и формирование Sprint Backlog, который содержит задачи (Story, Bugs, Tasks), которые должны быть выполнены в текущем спринте. Каждый спринт должен иметь цель, которая является мотивирующим фактором и достигается с помощью выполнения задач из Sprint Backlog.

Каждый день производится Daily Scrum, на котором каждый член команды отвечает на вопросы «что я сделал вчера?», «что я планирую сделать сегодня?», «какие препятствия на своей работе я встретил?». Задача Daily Scrum - определение статуса и прогресса работы над Sprint, раннее обнаружение возникших препятствий, выработка решений по изменению стратегии, необходимых для достижения целей Sprint"а.

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

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

Важные, часто забываемые особенности

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

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

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

3. Scrum применяется для продукта, требования к которому противоречат идеологии Scrum.
Scrum относится к семейству Agile, так Scrum приветствует изменения в требованиях в любой момент (Product backlog может быть изменен в любой момент). Это затрудняет использование Scrum в fixed-cost/fixed-time проектах. Идеология Scrum утверждает, что заранее невозможно предусмотреть все изменения, таким образом нет смысла зарание планировать весь проект, ограничившись только just-in-timе планированием, т. е. Планировать только ту работу, которая должна быть выполнена в текущем Sprint. Существуют и иные ограничения.

Достоинства и недостатки

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

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

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

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

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

Список использованных источников

The Scrum Guide. The definitive Guide to Scrum: The Rules of the Game. (Ken Schwaber, Jeff Sutherland)
Психология управления, учебное пособие. (А. А. Трусь)
How a Traditional Project Manager Transforms to Scrum: PMBOK vs. Scrum. (Jeff Sutherland, Nafis Ahmad)

Заранее благодарю за указанные ошибки и неточности!

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

Узнайте базовые, но важные термины, используемые в процессе Agile Scrum вместе с реальным примером полного процесса.

SCRUM - это процесс в гибкой методике, которая представляет собой сочетание итеративной и добавочной моделей.

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

Некоторые из ключевых особенностей SCRUM:

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

Чтобы хорошо понять эту методику, важно понимать ключевые термины SCRUM.

Важные термины SCRUM:

1. Scrum-команда

Scrum-команда – это команда из 7 +/– 2 члена. Члены команды представляют собой смесь из компетентных разработчиков, тестеров, людей из база данных, операторов техподдержки, т. д., а также владельца продукта и scrum-мастера. Все эти люди работают в тесном сотрудничестве в течении заданного рекурсивного промежутка для разработки и выполнения указанных функций.

2. Спринт

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

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

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

Владелец продукта – это человек, который представляет сторону клиента. Он/она имеет решающий авторитет и всегда должен/-а быть доступен/-а для команды. Он/она должен/-а быть доступен/-а в случае, когда кому-либо нужно что-то объяснить. Для владельца продукта важно понять и не устанавливать новые требования в середине спринта или когда он уже начался.

4. Scrum-мастер

Scrum-мастер является координатором команды scrum. Он/она следит за тем, чтобы команда scrum была продуктивной и прогрессивной. В случае каких-либо помех scrum-мастер находит и устраняет их для команды.

5. Пользовательская история

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

Как <тип пользователя>

я хочу <доступная цель>

для достижения <результат/причина>

Например:

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

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

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

6. “Эпопеи”

Эпопеи являются неясными пользовательскими историями. Или же, можно сказать, что это пользовательские истории, которые не определены и хранятся для будущих спринтов. Просто попробуйте связать это с жизнью, представьте, что вы уходите в отпуск. Так как вы уезжаете на следующей неделе, у вас все распланировано: бронирование номера в отеле, осмотр достопримечательностей, собрана дорожная сумка др. Но что насчет вашего отпуска в следующем году? У вас есть только смутная мысль, что вы можете пойти в место XYZ, но у вас нет никакого детального плана.

“Эпопея” – она как ваш отпуск в следующем году: вы знаете, что вы можете поехать, но куда, когда и с кем – пока что нет мыслей на этот счет.

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

7. Журнал пожеланий по продукту

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

8. Журнал пожеланий спринта

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

9. Очки за пользовательскую историю:

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

Каждой пользовательской истории определяется балл из ряда Фибоначчи (1, 2, 3, 5, 8, 13, 21). Чем выше число, тем сложнее история.

Если точнее, то

Если вы ставите 1 / 2 / 3 очка, это означает, что история небольшая и имеет низкую сложность.
Если вы даете 5 / 8 очков, то это средняя сложность и
13 и 21 очко – история очень сложная.

Здесь сложность заключается в разработке и в объеме тестовых работ

Чтобы решить, сколько очков дать, scrum-команда начинает мозговой штурм коллективно это решает. Может случиться так, что команда разработки даст конкретной истории 3 очка, потому что для них это может быть 3 строки кода замены, но команда тестирования даст 8 очков, потому что им кажется, что эта замена кода будет больше влиять на модули, поэтому объем работы при тестировании будет больше. Но сколько бы очков вы ни дали, вы должны обосновать свое решение. Таким образом, происходит мозговой штурм и команда решает, сколько очков поставить.

Всякий раз, когда вы решаете сколько очков поставить, учитывайте следующие факторы:

Отношение истории к другим приложениям/модулям,
Набор навыков ресурса
Сложность истории
Повествовательное обучение,
Критерии приемки пользовательский историй

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

10. Диаграмма сгорания задач

Диаграмма сгорания задач представляет график, который показывает предполагаемые v/s реальных усилий задач scrum.

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

Пример: Чтобы понять это, посмотрите на рисунок:

Я выбрал:

Двухнедельный Спринт (10 дней)
2 ресурса фактической работы спринта.

«История»-> колонка показывает пользовательские истории, взятые для спринта. «Задача»-> столбец показывает список задач, связанных с пользовательскими историями.

«Объем работы»-> колонка показывает объем работы. Сейчас эта мера является общим объемом работы для завершения задачи. Она не изображает объем работы какого-то конкретного человека.

«День 1 – день 10»-> – столбец (столбцы) показывает/-ют время, оставшееся до завершени истории. Обратите внимание, что это НЕ то время, что уже прошло, НО время, которое еще остается.

«Предполагаемый объем работы»-> показатель общих объема работы. Для «Старта» это просто итог всей задачи: СУММА (C5: C15)

Общий объем работы, который должен быть выполнен за 1 день, составляет 70 / 10 = 7. Таким образом, в конце первого дня объем работы должен уменьшиться до 70-7 = 63. Аналогичным образом это рассчитывается для всех дней до 10го, когда предполагаемый объем работ должен равняться нулю (строка 16)

«Оставшийся объем работы»-> исходя из названия, это – объем работы, оставшийся до завершения истории. Также может случиться, что фактический объем работы становится больше или меньше, чем предполагалось.

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

Этапы диаграммы сгорания задач:

Введите все истории (колонка A5 – А15)
Введите все задачи (колонка B5-B15)
Введите дни (1-день – 10-й день)
Введите начальный объем работы (суммируйте задачи C5-C15)
Примените формулу для расчета «предполагаемого объема работы» на каждый день (от дня 1 до дня 10). Введите формулу в D15 (с16-$C$ 16/10) и перетяните ее на все дни.
На каждый день введите фактический объем работы. Введите формулу в D17 (СУММА (D5:D15)) суммировать оставшийся объем работы и перетащите ее на все остальные дни.
Выберите это и создайте диаграмму следующим образом:

11. Скорость команды

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

Например : Для конкретного спринта: общее количество пользовательских историй – 8. Каждая из них имеет определенное количество очков

Таким образом, скорость – это сумма очков = 30

12. Определение “готово”:

История СДЕЛАНА в Scrum, только тогда, когда есть развитие, полное обеспечение качества и возможность попасть в производство.

Деятельность в SCRUM:

#1: Совещание по планированию

Совещание по планирования является отправной точкой SCRUM. Это совещание, где собирается вся scrum-команда. Владелец продукта на основе приоритета выбирает пользовательские истории из журнала пожеланий по продукту и команда начинает мозговой штурм. Во время обсуждения scrum-команда определяет сложность истории и измеряет ее согласно ряду Фибоначчи. Команда определяет задачи, а также объем работы (в часах), которые могли бы быть сделаны для завершения реализации пользовательской истории.

«Предварительное планирование встречи» предшествует встрече. Это как домашняя работа, которую scrum-команда делает, прежде собраться на формальной встрече по планированию. Команда пытается записать зависимости или другие факторы, которые они хотели бы обсудить на встрече.

#2: Выполнение задач спринта

Исходя из названия, это работа scrum-команды для выполнения своей задачи и перемещения пользовательской истории в статус “готово”.

#3: Ежедневное scrum-совещание (звонок)

Во время цикла спринта, каждый день scrum-команда встречается не более чем на 15 минут (это может быть звонок, который рекомендуется проводить в начале дня). На собрании ставится 3 вопроса:

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

Над решением этих проблем работает Scrum-мастер. В том случае столкновения участника с любого рода трудностями, scrum-мастер помогает их решить.

#4: Обзор итогов

В конце каждого цикла спринта SCRUM-команда снова встречается и демонстрирует владельцу продукта осуществление пользовательских историй. Владелец продукта может сличить истории в соответствии с их критериями приемки. Это опять же ответственность Scrum-мастера – председательствовать на этой встрече.

#5: Ретроспективное совещание

Ретроспективное совещание происходит после обзора итогов. SCRUM-команда собирается, обсуждает и документирует следующие моменты:

Что было сделано хорошо в предыдущем спринте (наилучшая практика)
Что было сделано не очень хорошо
Извлеченные из этого уроки
Элементы действий.

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

Как выполняется процесс? Пример!

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

Шаг #1 : Представим SCRUM-команду из 9 человек, в составе которых 1 владелец, 1 Scrum-мастер, 2 тестера, 4 разработчика и 1 администратор базы данных.

Шаг #2 : Спринт цикл, например, будет длиться 4 недели. Итак, у нас 1 месяц спринта: с 5 июня по 4 июля.

Шаг #3 : Владелец продукта имеет приоритетный список пользовательских историй в журнале пожеланий по продукту.

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

После обсуждения члены команды возвращаются на свои рабочие места и

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

Общее количество рабочих часов = 9

Минус 1 час для перерыва, минус 1 час для встреч, минус 1 час для писем, обсуждений, устранения неполадок и др.
Таким образом, фактические рабочие часы = 6

Общее количество рабочих дней во время спринта = 21 день.
Общее количество доступных часов = 21 * 6 = 126

Участник находится в отпуске 2 дня = 12 часов (это варьируется для каждого члена, некоторые могут взять отпуск, некоторые не могут.)
Количество фактических часов = 126-12 = 114 часов.

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

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

Шаг #6 : После начала спринта, каждый участник команды начинает работать над назначенными задачами.

Шаг #7 : Команда ежедневно встречается на 15 минут и обсуждает 3 вопроса:

Что они делали вчера?
Что они планируют сделать сегодня
Есть ли какие-нибудь помехи?

Шаг #8 : Scrum-мастер ежедневно отслеживает прогресс с помощью «Диаграммы сгорания задач»

Шаг #9 : В случае каких-либо помех Scrum-мастер решает их.

Шаг #10 : 4 июля команда собирается вновь для обзора итогов. Каждый член команды демонстрирует реализованную пользовательскую историю владельцу продукта.

Шаг #11 : 5 июля команда собирается снова для ретроспективного совещания, где они обсуждают

Что прошло хорошо?
Что прошло не хорошо
Элементы действий.

Шаг #12 : 6 июля команда снова встречается для совещания предварительного планирования следующего спринта, и цикл продолжается.

(Нажмите, чтобы увеличить изображение)

Программы, которые могут быть использованы для деятельности SCRUM:

Есть много инструментов, которые могут широко использоваться для отслеживания деятельности scrum. Вот некоторые из них:

XPlanner
VersionOne
Sprintometer
ScrumNinja

Заключение:

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

Многие временные организации вдохновляют команду (в качестве задачи scrum) посвятить пару часов самостоятельному обучению и развитию. Также во время обзора члены группы показывают что они изучили, а иногда представляют программы или приложения, которые они разработали. Лично я ценю этот метод, потому что он дает людям шанс расширить свои знания, а также показать свои навыки.

«Цинизм является ответной реакцией нашего сознания на чувство отчаяния ».
Джефф Сазерленд

Насколько сильна альтернатива PM?

Действуя как топ-менеджер и проект-менеджер, я столкнулся с понятием Scrum как некой экзотической альтернативой классическому project management. Захотелось разобраться, в чем идеологические и технологические особенности данного подхода, и в чем, собственно, революция метода? Прочел несколько монографий. Честно скажу, после первого знакомства особой глубины не разглядел. Методология Скрам показалась несколько ангажированной и неконкретной.

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

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

Являются ли современная парадигма управления проектами, международные и национальные стандарты (ANSI PMbok Guide, PM ICB IPMA, НТК) продуктом, который используют потребители: государство, его институты, бизнес? Да, конечно. Какие проблемные зоны существуют в современной проектной практике, основанной на рабочей методологии? Их несколько, но основных две: невыполнение проектных сроков и превышение бюджета проекта.

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

Данное свойство проектов особенно остро проявляется в областях, требующих инновационного подхода. Метод Скрам (Scrum) способен существенно смягчить названные проблемы. В начале 2000-х годов он явился результатом труда двух новаторов Д. Сазерленда и К. Швабера (США). В своей разработке авторы метода использовали элементы теории Х. Такеучи и И. Нонака, а также идеи системы компании Тoyota (Тайити Оно). И как революционный метод управления проектами модель Скрам уже получила признание в западных странах, причем на сегодняшний день практика его применения не ограничена только бизнесом.

Терминология метода

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

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

Владелец продукта. Эта фигура несет ответственность за то, чтобы командная работа дала результат, который приносит компании прибыль (выгоды). Он должен прекрасно разбираться в сути продукта, в возможностях команды и в приоритетах рынка.
Скрам-мастер. Метафорически это очень интересная роль. «Лидер-слуга», «капитан команды», «тренер-коуч». Его главная задача – вести команду по пути непрерывного совершенствования, устраняя препятствия и причины помех.
Доска Скрам. Обычная офисная доска, разделенная на части: «бэклог», «в работу», «в работе», «на рассмотрение», «сделано!». По ней перемещаются наклеиваемые стикеры с заданиями.
Собрание Скрам. Итоговое собрание по завершении спринта.
Спринт. Временной промежуток от 1 до 4 недель, устанавливающий рабочий ритм деятельности команды Скрам по созданию новой функциональности.
Совещания на ходу или ежедневный Scrum. Короткие собрания команды проекта для ответа на вопросы скрам-мастера о результатах, планах на день и текущих препятствиях.
Бэклог (баклог). Список текущих требований-заданий к созданию функциональности продукта проекта.
Диаграмма выгорания задач. Диаграмма, показывающая количество сделанной и оставшейся работы в рамках поставленной задачи.
Последовательность Фибоначчи. Математическая закономерность, свойственная природе нашей Вселенной, при которой действует особый порядок чисел. Настоящая последовательность хорошо применима для альтернативной оценки продолжительности выполнения работ проекта, благодаря использованию так называемого «покера планирования». Ниже представлена визуальная модель числовой последовательности.
Сюхари (Shu Ha Ri). Сюхари – одна из концепций японских боевых практик (например, айкидо), которая вошла в число принципов метода Скрам как метафора возможности поэтапного (итерационного) достижения совершенства команды проекта.
OODA. Принцип метода Скрам по циклической реализации: наблюдать, ориентироваться, решать, действовать.

Модель последовательности Фибоначчи

Базовая модель метода Скрам. Источник: Асхат Уразбаев. Краткий обзор методологии Скрам

Краткое описание процесса

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

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

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

Заполнение ролей команды Скрам.
Формирование артефактов Скрам.
Реализация активности.
Воспроизводство цикла Скрам.

Визуальная модель процесса метода Скрам

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

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

Пример доски Скрам

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

Комментарии по заполнению ролей

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

Шаг 1 алгоритма методологии Скрам

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

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

Шаг 2 алгоритма методологии Скрам

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

Шаг 3 алгоритма методологии Скрам

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

Если «лидер – не босс», а скрам-мастер – «играющий тренер», тогда кто управляет командой Скрам? Самоуправление, на мой взгляд, не укладывается в концепцию проектного управления.
Возникает вопрос мотивации владельца продукта проекта, скрам-мастера и команды Скрам. В методике описан принцип открытости информации, включая доступа к финансовым данным проекта. Идея неплохая, но, учитывая Макиавеллевскую позицию, присутствующую во многих российских компаниях, у такой возможности среди руководителей, наверное, окажется много противников.

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

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

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

Шаг 4 алгоритма методологии Скрам

Пятый шаг алгоритма Scrum не менее интересен. Совершенно не хочется погружаться в мистические аспекты чисел. Но у нас с вами есть рядовая прагматическая задача: наилучшим образом составить прогноз продолжительности выполнения работ проекта, используя самую объективную экспертную оценку. К сожалению, «гадание на кофейной гуще» по проставлению часов в MS Project – нет ничего более тоскливого и изнурительного даже с привлечением знающих экспертов. Могу с уверенностью заявить, что лучшего метода, чем «покер планирования» я в проектной практике не встречал. Метод широко известен, поэтому заострять на нем внимание не будем. Замечу лишь, что сочетание метода Дельфи и последовательности Фибоначчи дает поразительные результаты.

Пример пасьянса метода «Покера планирования»

Причин для того, чтобы рассматривать метод Скрам не как тюнинг современной доктрины PM, а как поистине революционный метод управления проектами несколько. Одна из них – это отношение к описанию работы по выполнению проектного задания с позиции историй, что противоположно процессуальному подходу Д. Чампи и М. Хаммера. Люди действительно мыслят образами. С одной стороны, трудно согласиться с тем, что можно не бояться потерять однозначность трактовки результата работы. С другой стороны, если отвлечься от задачного давления и взглянуть на вопрос с позиции подлинной ориентации на клиента проекта, «мягкие» истории могут дать больше для получения нужных результатов заданий.

Шаг 5 алгоритма методологии Скрам

Рассматривая шаги 5 и 6, механизмы расчета динамики производительности, бэклога спринта, сроков окончания проекта и возможности ускорения, не вызывают сомнений. Все достаточно очевидно. Затруднения в понимании возникают относительно одного вопроса: как по окончании каждого спринта добиваться наглядного приращения функциональности продукта? Касаемо проектов разработки программных продуктов такое вполне возможно. А как быть, например, при реализации проекта внедрения системы бюджетирования по методу Скрам, где много этапов подготовительной работы, на которых видимого прироста функциональности не происходит? Представляется, что в данную часть метода требуется дополнительное погружение.

Шаг 6 алгоритма методологии Скрам

Вопросы активных действий в ходе процесса

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

Шаг 7 алгоритма методологии Скрам

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

Шаг 8 алгоритма методологии Скрам

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

Шаг 9 алгоритма методологии Скрам

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

Шаг 10 алгоритма методологии Скрам

Скрам как код антицинизма

Мне импонирует представленная в подзаголовке метафора. Она принадлежит Джеффу Сазерленду, и в ней чувствуется глубокое переживание цинизма как значительного порока современного бизнеса. В целом позиция автора метода Скрам, безусловно, искренняя. Это подкупает. И, в принципе, совсем неплохо, что Сазерленд вводит в управленческий контекст компонент счастья. Подобное делается так по-американски. Вместе с тем, хотелось бы разобраться, почему слово «счастье», и все, что с ним связано в рассматриваемой революционной проектной доктрине, вызывает внутренний дискомфорт. Только ли это субъективно-личностное восприятие, или это некоторый общий культурологический взгляд на предлагаемый подход?

Мы с вами, скорее всего, помним, что происходило в России в конце 90-х – начале 2000-х годов. В страну буквально хлынули «новоявленные нуворишы» со всех уголков мира, и в основном из США, вещающие «правду» о личной и корпоративной успешности. Надо честно сказать, что подобные «откровения» не прошли бесследно, многие бизнесмены взяли на вооружение ключевые аспекты привезенных с Запада теорий управления. Я специально не называю тренинговые курсы, авторские теории и именитые школы. Кто с ними сталкивался, поймут.

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

Происходит быстрое отрезвление и на уровне государства, и на уровне деловых людей. И они начинают понимать, что некоторые привносимые решения, способы ведения бизнеса, построения отношений с персоналом не просто полезны, они служили враждебным и разрушающим целям, приводящим к ломке нашей национальной культуры, в том числе культуре хозяйствования. Я приведу один единственный пример противопоставления двух идеологем: «Разделяй и властвуй!» и «Купеческое слово дороже договора!».

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

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

Все слышали об Agile («аджайл»). Если ещё недавно кто-то мог не знать этого слова, то в январе этого года сам Герман Греф, руководитель Сбербанка, стал атаковать страну из всех орудий своим евангелизмом гибких подходов к управлению, и сейчас Agile прозвучал уже для всех.

Scrum («скрам») - практическое воплощение Agile-принципов. Это подход, позволяющий, по словам его создателя Джеффа Сазерленда (Jeff Sutherland), делать в два раза больше за вдвое меньшее время.

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

Чтобы быть в курсе, вы можете прочитать новую книгу Джеффа Сазерленда «Scrum. Революционный метод управления проектами». Это займёт несколько дней. Альтернативный способ быстрого чтения умных американских бизнес-книг - прочитать краткую выжимку , пересказ, саммари от нашего партнёра - компании Smart Reading. Это займёт полчаса, и вы обязательно усвоите все ключевые идеи без воды.

Scrum появился около 20 лет назад как эффективный метод увеличения продуктивности при разработке программного обеспечения. Завоевав популярность в Кремниевой долине, Scrum быстро получил признание в других отраслях бизнеса. Его создатели Кен Швабер (Ken Schwaber) и Джефф Сазерленд изучили передовой мировой опыт успешных компаний и пришли к выводу, что «водопадная» модель, по которой прежде строилась работа над IT-проектами, безнадёжно устарела. Она не отвечала ожиданиям клиентов, поскольку работа продвигалась медленно, в строгом соответствии с долгосрочным планом, и часто на выходе получался не тот продукт, который на самом деле был нужен.

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

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

Люди важнее процессов

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

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

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

Продукт важнее документации

Ещё одно любимое занятие бюрократии - бесконечно всё описывать, создавать тонны документации, тратить на это добрую половину ресурсов, затягивать таким образом сроки. Важны не бумажки, а то, удаётся ли вашей организации, вашей команде создавать именно тот продукт, который действительно нужен клиентам. Если у вас будет отличный продукт и не будет документации - это неплохо. Именно так вышел на рынок первый iPhone в 2007 году.

Scrum - это про смысл, а не про создание максимума бумажек ради создания максимума бумажек.

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

Сотрудничество с клиентом важнее идеально составленного контракта

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

Scrum - это про понимание и сотрудничество, а не про юристов и прикрывание мягкого места.

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

Способность меняться важнее следования планам

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

Scrum - это про науку и смысл, а не про веру и необоснованные надежды.

Как же быть? По Scrum, вы должны иметь большую цель, но идти к ней итеративно, не пытаясь предугадать каждый свой шаг в далёком будущем. Небольшими итерациями по 2–4 недели двигайтесь к цели, оборачивайтесь назад, делайте ретроспективу, оценивайте сделанное, отказывайтесь от результата последней итерации, если он не приближает вас к цели. Таким образом можно избежать глупых больших провалов. Итеративность - это научный подход. Надежды на правильность больших планов - это, скорее, похоже на религию.

Должности и титулы не важны - важно то, что вы делаете

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

Scrum - это про доверие, а не про силу и насилие.

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

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

Итак, узнать досконально всё о Scrum можно из книги его создателя Джеффа Сазерленда. В качестве альтернативы можно за 20–30 минут прочитать саммари этой книги в электронной библиотеке Smart Reading.

Лайфхакер и Smart Reading предлагают попробовать этот новый способ быстро узнавать всю суть очень умных, но весьма толстых книг. На сайте Smart Reading вас ждёт ещё несколько сотен саммари великих книг, которые, возможно, вы никогда полностью не прочтёте.