Как внедрить Scrum в процессы управления и развития компании

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

Первая причина - это повышение эффективности. В современном мире всё очень быстро меняется. Если мы создадим стратегию на 5 лет, на 3 года или даже на 1 год, то единственное, что мы знаем на 100%, что всё в итоге окажется не так, как мы предполагали. Хочется иметь такую стратегию, которая могла бы постоянно корректироваться (например, раз в 2 недели), а вместо стратегии на 5 лет мы бы имели понимание, куда мы движемся. Что-то подобное обещал нам Scrum.

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

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

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

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

Шаг 1: Изучение Scrum

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

Шаг 2: Выбор сервиса

Основной инструмент Scrum - это доски, колонки и задачи. Есть обширное количество сервисов для этого, самые популярные - это Trello, Wrike, Jira.

Я выписал, что нам нужно от сервиса. И оказалось, что большинство популярных сервисов нам не подходят. На всех площадках под задачей реализованы комментарии, их можно писать, чтобы лучше взаимодействовать с командой. Но это подходит для IT, а нам под каждой задачей нужен был чат, как в Telegram. Мы должны были хотеть много общаться по каждой задаче - шутить, накидывать идеи, короче, не ограничивать себя сухими фразами. Только так из этого могло что-то получиться. Мы нашли YouGile, сервис, который давал такую возможность.

Шаг 3: Собираем задачи в "Неначатые"

Для начала мы создали доску: Бруноям.

В ней появилось 4 колонки:

Дали себе 2 недели, чтобы собрать все идеи и новые проекты в колонку “Неначатые”.

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

Шаг 4: Первый спринт

Спринт - это 2-х недельный отрезок времени, на который мы планируем задачи. Эти задачи попадают в колонку "План".

Сначала обсуждаем все задачи из колонки "Неначатые". Далее, выбираем те задачи, которые хотели бы выполнить в эти 2 недели.

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

Шаг 5: Задачи без исполнителей и "Стратегия"

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

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

Шаг 6: Расчёт часов и оценка задач

До этого мы оценивали так: брали задачу и кто-то говорил: "ну это точно 4 часа", остальные обычно соглашались. Теперь же решили более точно подойти к этому вопросу. Повторюсь, это следует делать только тогда, когда все участники команды осознают, зачем нужно это дополнение.

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

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

Порядок действий получился таким:

Шаг 7: Product Owner и Scrum Master

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

Эта простая роль, её мы ввели сразу.

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

Мы не можем вести один проект, а ведём сразу 10-20 на одной доске. В итоге у нас Product Owner отвечает за конкретный проект в стратегии и должен всегда знать на 2-3 спринта вперёд, что нужно делать по этому проекту. В нашем случае эта должность чуть сложнее, чем обычно.

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

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

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