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

Scrum за пять минут

Agile и Scrum в проектном управлении

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

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

Четыре ценности и 12 принципов Agile подробно описаны в Agile-манифесте, а узнать больше об Agile можно из предыдущей статьи в блоге «Апланы» — «Agile и управление проектами».

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

Чтобы объяснить суть подхода, создатели Scrum (и одни из создателей Agile) Кен Швабер и Джефф Сазерленд разработали «Исчерпывающее руководство по Скраму», в котором описали основные «правила игры», а затем дополняли его на протяжении более двадцати лет. Конечно, Scrum не стоит на месте, а продолжает развиваться. Но в чем же его суть? В чем причина его успеха?!

Scrum: теория и ценности

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

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

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

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

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

Суть Scrum — в маленькой команде людей

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

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

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

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

Джефф Безос — основатель компаний Amazon и Blue Origin, владелец The Washington Post и богатейший человек в мире (Forbes, 2018) — приверженец Scrum. Он сформулировал простое и очень наглядное правило: команда должна быть достаточно маленькой, чтобы ее можно было накормить двумя пиццами. «Правило двух пицц», внедренное в Amazon, идеально соотносится с философией Scrum — именно таким количеством можно накормить от четырех до восьми человек.

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

Роли в Скраме

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

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

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

События Скрама

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

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

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

Гибкая методология Scrum

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

Гибкие методологии

Начать стоит с самого происхождения Agile-методологий. Начало им положил «Манифест гибкой методологии разработки программного обеспечения» в 2001-м году. Agile — в переводе с английского «гибкий». Вот основные принципы Манифеста:

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

В основе таких методологий лежит итеративный подход: когда разработка ведётся циклами (итерациями). После каждого цикла определяются планы по изменению продукта на следующий.

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

  • DSDM с начала 90-х,
  • FDD с 97-го,
  • Kanban ещё с 60-х годов, однако эта методология использовала лишь часть приёмов от гибких методик.

Srum тоже был разработан во второй половине 80-х годов прошлого века.

История Scrum

Впервые слово «Скрам» не в контексте регби (там этот термин обозначает позицию игроков, борющихся за мяч в плотном скоплении), а в контексте разработки использовали Хиротака Такеучи и Нонака Икуджир в статье в 1986-м году. Там учёные описывали новый гибкий геймификационный подход к разработке коммерческого продукта, позволяющий выполнять работу в быстрые сроки. Команда разработчиков сравнивалась с командой в регби: действует во время «Скрама», как единый организм, для достижения общей цели.

Статью заметил Джефф Сазерленд, бывший военный лётчик США, занимающийся поиском новых подходов к разработке ПО. В это же время Кен Швабер, тоже разработчик, также искал новые подходы для оптимизации своей деятельности. В 1995-м году Сазерленд и Швабер объединяются и создают документ, отражающий основы методологии Scrum. В 2001-м они участвуют в создании Манифеста Agile.

Читать еще:  Миллионер без диплома: нужно ли предпринимателю образование?

В этом же году создаётся Scrum Alliance. Его миссия: направлять лидеров, компании и людей в целом на создание правильной организации рабочего процесса — «Transform the World of Work». Альянс существует и сегодня и занимается внедрением методологии Scrum.

На чём базируется Scrum

Основные принципы организации рабочего процесса в Scrum во многом являются эталоном и совпадают с другими Agile-методологиями.

  • Работа над проектом состоит из спринтов (итераций), длина которых две–четыре недели. В течение спринта необходимо выполнить заданный заранее объём работ. Обычно это либо новая функциональность продукта, либо готовый продукт в целом, который в ходе следующих спринтов улучшается. Нельзя менять задачи в ходе спринта, спринт можно остановить только в исключительных ситуациях.
  • Численность команды: четыре–десять человек. Такое ограничение обеспечивает максимальную производительность и сводит к минимуму отвлечения от работы и разговоры. Команда должна содержать всех необходимых для создания продукта специалистов.
  • Задачи спринта излагаются в Product Backlog. Product Backlog составляется из пожеланий пользователей (user stories) — то, что заказчик или потребитель желает видеть в проекте.
  • Каждый спринт начинается с планирования — на нём обсуждается, какие задачи нужно будет выполнить, завершается ретроспективой — оценка эффективности команды. Каждый день проходят 15-минутные собрания — члены команды, обязательно стоя, обсуждают: что удалось сделать вчера, что нужно сделать сегодня и что может этому препятствовать.
  • Отсутствие многозадачности. Единовременно команда работает только над одной задачей.
  • Помимо команды разработчиков обязательно присутствуют ещё две роли. Scrum-мастер, который следит за соблюдением принципов Scrum и убирает препятствия для эффективной работы, и Product Owner. Он взаимодействует с заказчиком и передаёт его требования команде.

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

Отдельно стоит поговорить о методах визуализации работы, используемых в Scrum и некоторых других Agile-методиках. Две главных из них: Burndown Chart и Desk.

Burndown Chart — Диаграмма сгорания задач. Такая диаграмма отображает процесс работы над проектом. По ней легко отследить, насколько команда приблизилась к выполнению задачи. По горизонтали откладывается время: остаток дней до конца стрима. По вертикали — количество подзадач, человеко-часов или Story Points — единиц измерения работы. График Диаграммы сгорания стремится вниз, от первого дня к последнему, от максимального количества подзадач/человеко-часов к их отсутствию. Отдельным цветом изображается идеальный график — прямая: когда за каждый день выполняется одинаковый объём работы, что в итоге приводит к равномерной нагрузке и выполнению цели в срок. Плохим результатом на Диаграмме сгорания будет не только возвышение реального графика над идеальным. Если команда выполнила весь объём работ на несколько дней раньше, значит неправильно был определён размер итерации либо поставлена слишком маленькая или простая задача.

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

Два этих способа визуализации обязательны в Scrum. Burndown chart и Desk — статистика и мотивация для команды. Однако применять такие инструменты можно и без перехода к гибким методикам: они отлично покажут эффективность любого рабочего коллектива.

Ещё один популярный инструмент: метрика Velocity. На диаграмме за несколько спринтов сравниваются столбцы запланированных подзадач/Story points за стрим со столбцами выполненных. На основе этого определяется эффективность. Метод весьма спорный, так как слишком обобщает результаты, но может использоваться дополнительно.

Где применяется Scrum

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

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

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

Scrum и крупные компании

Герман Греф активно вводит Scrum в IT-сфере «Сбербанка». Там методология используется для поддержки «Сбербанк Онлайн» с 2013-го года. По гибкой методике это же приложение и создавалось. Несколько команд занимаются разработкой других различных проектов, таких как «Советы».

Легко ли внедрять Scrum в большие компании? Гибкая методология требует полного изменения рабочего процесса, а далеко не все сотрудники будут к такому готовы. Как правило, легче всего вводить «Скрам» постепенно, набирая работников, которые заинтересованы в проекте, желают изменить привычный график. Точно не стоит сразу переводить на новый режим работы всю компанию целиком.

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

Оценка Scrum

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

Преимущества

  • Быстрое удовлетворение большинства требований заказчика или клиентов.
  • Высокая конкурентоспособность продукта за счёт его постоянной оптимизации.
  • Большая эффективность рабочей команды: каждый сотрудник постоянно занят своим делом, не тратит время на лишние разговоры, при этом постоянно взаимодействует с коллегами и через Product Owner с заказчиками.
  • Готовый продукт производится в быстрые сроки.
  • Экономия на менеджерах, так как команда управляется изнутри только Scrum-мастером, а извне лишь получает требования к продукту от заказчика.

Недостатки

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

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

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

Обучение Scrum

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

1. «Scrum. Революционный метод управления проектами» Джеффа Сазерленда.

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

2. «Софт за 30 дней» Джеффа Сазерленда.

Эта книга также написана Джеффом Сазерлендом совместно с Кеном Швабером — другим создателем Scrum. В книге описывается процесс быстрой разработки программного обеспечения на основе методики, а дополнение Scrum Guide описывает все роли, артефакты, процессы.

3. «Scrum и XP: заметки с передовой», Хенрик Книберг.

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

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

Читать еще:  Оценка и основные характеристики франшизы

Программы для управления проектами

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

Scrum. Революционный метод управления проектами

Время чтения: 14 минут

В следующих инсайтах Вы узнаете:

Инсайт 1. Забудьте старые подходы и диаграммы Ганта – используйте Scrum.

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

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

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

Какие же идеи лежат в Scrum?

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

Мы подготовили обзор книги:

Автор: Гай Кавасаки

«Стартап. 11 мастер-классов от экс-евангелиста Apple и самого дерзкого венчурного капиталиста Кремниевой долины»

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

Команда должна быть самостоятельна при выборе способов достижения цели.

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

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

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

Команда должна быть многофункциональна.

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

И не нужно создавать слишком большие команды, оптимальное количество человек — от 3 до 9. Чем больше людей, тем тяжелее команде продвигаться вперёд.

Команды, которые начали работать по методологии Scrum, в среднем увеличивали свою эффективность на 300 — 400%, а лучшие — на 800%.

«Если проект не укладывается в сроки, то добавление рабочей силы задержит его еще больше». Из книги Фредерика Брукса “Мифический человеко-месяц»

Инсайт 3. Используйте спринты.

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

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

«Суть системы Scrum заложена в ритме деятельности. Для человека ритм имеет особое значение». Джефф Сазерленд

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

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

А как команда может эффективнее работать во время самого спринта? Лучший вариант для этого — «ежедневные собрания на ходу». Собрания, которые проводятся внутри группы ежедневно, всегда в одно и то же время, и не занимают более 15 минут.

Во время таких собраний каждому участнику группы нужно ответить на 3 вопроса:

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

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

«Время — Ваша жизнь. Поэтому не следует впустую расходовать его — это сродни медленному самоубийству». Джефф Сазерленд

Инсайт 4. Избавляйтесь от всех видов потерь — они тянут Вас ко дну.

За один раз выполняйте только одну задачу. Многозадачность может выглядеть привлекательно, но на самом деле она просто тратит больше половины (!) вашего времени и сил.

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

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

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

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

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

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

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

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

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

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

По шкале от одного до пяти: как Вы оцениваете свою роль в компании? По той же шкале оцените компанию в целом? Почему Вы так считаете? Назовите что-то одно, что может сделать Вас счастливее в следующем спринте?

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

Инсайт 6. Расставляйте приоритеты правильно — это критически важно для управления проектами.

Последний важный принцип Scrum — расстановка приоритетов. Но кто определяет, что должно быть сделано и почему? В скрам-командах нет начальника и эта роль достаётся владельцу продукта. В методологии Scrum в команде всего три роли:

Читать еще:  Нормативные документы по оформлению путевых листов

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

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

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

Что же это такое цикл OODA? Это аббревиатура от слов:

«Выживает тот, кто быстрее всех справляется с изменением скорости ветра». Джон Бойд, лётчик-истребитель ВВС США, советник Пентагона, создатель концепции цикла OODA

Инсайт 7. Запустите свой первый проект Scrum!

После того, когда Вы увидели, как Scrum может помочь Вам в реализации проектов, возникает вопрос: с чего начать?

Всё просто:

Выберите владельца продукта.

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

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

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

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

Проанализируйте свой «бэклог». Оцените с командой возможность выполнения заданий и необходимое время, которое потребуется на их выполнение. Вместе с командой расставьте условные баллы по каждому заданию, которые будут отражать время их выполнения. Лучше всего это сделать используя последовательность Фибоначчи: 1, 3, 5, 8, 13, где каждое число из этой последовательности — сумма двух предыдущих.

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

Сделайте работу наглядной. Установите на видном месте «скрам-доску» с колонками, где отражены статусы задач, и со стикерами, где отражены задачи. По мере выполнения задач стикеры будут перемещаться. Также сделайте «диаграмму выгорания задач», которая будет ежедневно отображать количество набранных баллов за выполненные задания.

Проводите «ежедневные собрания на ходу». Скрам-мастер и команда собираются вместе каждый день, в одно время, не более чем на 15 минут. Это необходимо, чтобы каждый знал, какая задача и на каком этапе находится, а также есть ли какие-то сложности. Задача скрам-мастера — устранять все возможные препятствия на пути к завершению спринта.

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

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

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

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

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

Все задачи должны иметь следующее:

  • Четкое описание
  • Хронологический порядок
  • Приоритет (определяется командой)
  • Оценка времени на выполнение

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

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

Задачи в спринте (sprint backlog)

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

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

  • Придумать тему для поста в блоге
  • Исследовать тему
  • Определить ключевые слова для поста в блоге
  • Написать пост для блога
  • Продумать визуальное оформление поста
  • Перечитать и отредактировать пост
  • Опубликовать пост в блоге и др.

Скрам-доска (scrum board)

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

Вот пример виртуальной скрам-доски:

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

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

Скрам-собрания

Планирование спринта (sprint planning)

Ежедневные скрам-собрания (daily scrum)

Обзор спринта (sprint review)

Ретроспектива спринта (sprint retrospective)

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

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

Мы в Uplab практикуем Scrum с 2016 года. Первыми методологию начали использовать команды разработчиков. Это было что-то вроде эксперимента, который удачно завершился, и через 3−4 месяца уже все отделы агентства начали применять в своей работе эту технологию проектного управления. Оглядываясь назад, могу сказать, что переход на Scrum потребовал некоторой адаптации, но однозначно оказал мощное положительное влияние на тайм-менеджмент и продуктивность специалистов.

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

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

Ссылка на основную публикацию
Adblock
detector