Строим рабочий процесс по гибкой методологии и выстраиваем продуктивную коммуникацию.
Разработка IT-продукта — задача большая и амбициозная. Многие команды зачастую даже не знают, с какой стороны подступиться к работе. А коллеги не слишком помогают, а только мешают. Все это из-за отсутствия четкой цели и зависимости одной задачи от другой. Поэтому люди ищут разные подходы к организации рабочего процесса. Один из них — методология SCRUM, которая уже стала стандартом для разработки ПО.
Но это не значит, что SCRUM — это только для программистов. Методология позволяет оптимизировать работу любого отдела. Ведь почему нет? Нигде не сказано обратного. Вот смотрите, какие принципы лежат в основе SCRUM:
-
Спринты для достижения конкретного этапа.
-
Гибкость, готовность доработать рабочий процесс и адаптироваться к ситуации.
-
Участие заказчика в разработке.
-
Взаимодействия внутри команды.
Нигде не написано, что надо быть очень-очень умным и уметь программировать. Эти принципы подойдут маркетологам, отделу кадров, дизайнерам и т. д.
Роли по SCRUM
Кто участвует в процессе? В широком смысле есть только 3 роли:
-
Владелец продукта. Чаще всего это заказчик или официальный представитель. Он ответственен за все решения по продукту: позиционирование на рынке, бизнес-план, составляет список требований для команды. В конце каждой итерации владелец проверяет качество продукта.
-
SCRUM-мастер. Человек отвечает за рабочий процесс, взаимодействия внутри команды и результаты. Мастер тоже участвует в создании итогового продукта.
-
Исполнители. Собственно, те, кто отвечают за выполнение задач. Достижение результата спринта — цель каждого из сотрудников. Для исполнителя важно объективно оценивать свои силы и распределять свою нагрузку.
Как собрать команду
Итак, SCRUM нам подходит, нужно собрать команду. Это обязательно: методология попросту не сработает для совсем маленьких стартапов в 1-2 человека. Но подбирать персонал нужно с умом. Нельзя просто собрать крутых спецов — они должны дополнять друг друга. Если у вас уже есть команда, необязательно всех распускать, но вполне возможно, что потребуются структурные изменения и обучение.
Поскольку SCRUM входит в семейство гибких методологий. Это значит, что команде придется адаптироваться под ситуацию. Причины могут быть разными: от радикальных изменений в вашей сфере бизнеса до банального отпуска одного из сотрудников. Забегая вперед, в конечном виде SCRUM-команды у каждого члена есть своя область ответственности. Но это не значит, что сотрудники должны быть односторонними. Напротив, в идеале все могут делать всё, хотя бы на базовом уровне.
В таком случае команда сможет адаптироваться и выполнить срочную задачу даже в отсутствие ответственного. Не стоит искать универсальных сотрудников, которые могут делать все задачи на высоком уровне. Но обучить навыкам на базовом уровне стоит. Потом сами себе скажете «спасибо».
Методология SCRUM предполагает 4 фазы развития команды
-
Формирование. На этом этапе зоны ответственности неясны и требуется крепкая рука руководства.
-
Конфронтация. Механизм принятия решений и цели команды ясны, но взаимоотношения еще не установлены.
-
Нормализация. Взаимодействие внутри команды отлажено, все имеют общую цель и пытаются улучшать рабочий процесс.
-
Исполнение. Цели и зоны ответственности ясны, команда работает без значительного вмешательства руководства.
Эффективность команды напрямую зависит от фазы, на которой она находится. Изменение состава всегда предполагает перераспределение сфер ответственности и из-за этого всегда приходится откатываться к этапу 1. Поэтому новых сотрудников лучше привлекать к свежему проекту, когда команда в любом случае находится на фазе формирования. Так же и с уходом исполнителей.
Рабочий процесс
У проекта обязательно должен быть бэклог — список задач, которые предстоит выполнить команде. Он может и будет пополняться, то есть не нужно продумывать каждую мелочь с самого начала. У задач должна быть оценка в Story Points. Можете называть их как угодно, хоть листиками, хоть тугриками. Они нужны для оценки трудозатрат. Команда определяет «стоимость» каждой задачи при помощи покера планирования.
Спринт
Работа по SCRUM предполагает формирование спринтов — временных отрезков, за которое команда добивается промежуточной цели. Задачи из бэклога отбираются по приоритету и распределяются между членами команды. Здесь на помощь приходят Story Points, они помогают оценить трудозатраты, чтобы цель спринта была достижима.
На первых порах будет сложно — производительность каждого члена команды неизвестна, а оценка задач пока необъективна. Но в этом и особенность работы по SCRUM: команда становится продуктивнее с каждым спринтом.
Регулярные стендапы
Каждый день или неделю команда собирается, чтобы обсудить три главных вопроса:
-
Какая работа была проделана?
-
Что будет сделано сегодня/на этой неделе?
-
Мешает ли что-то достижению целей?
На встрече присутствуют все: исполнители, SCRUM-мастер и владелец. Частоту встреч команда определяет самостоятельно. Где-то достаточно еженедельных стендапов, а где-то нужны и ежедневные. Подбирайте комфортный темп. Просто обратите внимание, чтобы исполнителям было что сказать по существу. На основе ответов делаются выводы по тому, что можно улучшить в рабочем процессе.
SCRUM-доска
Доска, на которой будет отображен прогресс спринта. Выглядит это как несколько колонок, по которым двигаются задачи. Самые базовые это «Сделать», «В работе» и «Готово». Но могут быть изменения и дополнения с поправкой на ваш проект. Часто добавляется этап «Проверка». Для маркетинга пригодятся колонки «Согласование» и «Публикация». Для более удобной работы есть специальные программы — таск-трекеры.
В целом, можно использовать физическую доску и стикеры, но это не так удобно, как таск-менеджер. А еще менее экологично. Мы, например, используем Аспро.Agile. Но оно и понятно (:
Изменения в ходе спринта
В идеальном мире трудностей и обстоятельств не возникает, и все задачи закрываются в срок. Увы, мы живем в другой реальности и ситуации, когда прогресс отбрасывается назад, случаются регулярно. Это может быть критический баг в разработке или более приоритетные цели, которых не было на момент формирования спринта.
Методология SCRUM поощряет гибкость, поэтому сдвинуть сроки можно. Просто будьте готовы к тому, что такое случается.
Проверка результата
По итогам спринта проводятся тесты ПО или проверка результатов. Поскольку в начале мы ставили конкретную цель, можно произвести сравнение ожиданий и реальности. Чаще всего спринты формируются на неделю, и подведение итогов совпадает со стендапом.
Так, решая по одной задаче, по одному спринту вы доведете продукт до релиза. Это не значит, что на этом ваша работа закончится — едва ли. Скорее всего, бэклог задач останется, туда будут входить дополнительные функции и разного рода «хотелки». Их предстоит реализовывать уже в спринтах обновлений.
В ходе работы вы столкнетесь еще со многими вопросами касательно SCRUM. Мы продолжим рассказывать о методологии в своем блоге. Поэтому вы можете подписаться на нашу рассылку, чтобы не пропустить новые статьи.