Скрам: как внедрить эффективное управление проектами

Скрам — это набор базовых рекомендаций по организации процессов в работе команды. Чаще всего команды разработчиков в IT. Скрам появился как одна из методологий аджайла, поэтому он гибкий, построен на спринтах и готовит членов команды к возможным изменениям. Мы в Oko тоже работаем по scrum, по нему же разрабатывали свою CRM. Рассказываем, как это работает.

Что такое scrum. Разработчики называют его фреймворком, но мы бы не использовали столь узкую терминологию. Я бы сказал, что это набор рекомендаций по организации процессов в команде. Вы не получаете конкретных инструкций по разработке продукта. Зато есть конкретный порядок организации процессов — как работать команде, как принимать решения, как внедрять изменения.

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

Scrum относят к agile-подходам. Аджайл — это такая философия, комбинация подходов и методик управления, система ценностей для команды. Аджайл предполагает гибкий подход к разработке ПО (на самом деле не только ПО) и строится вокруг 4 ценностей: взаимодействия между людьми, коммуникации с заказчиком, готовности к оперативным изменениям и ориентации на работающий продукт (а не на документацию). Если что, у аджайла есть свой манифест. Все этим ценности применяются в scrum и kanban (это другая методология аджайла).

Scrum строится на ценностях аджайла из манифеста.

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

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

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

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

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

Главное правило в работе скрам-команды — концепция «3-5-3»:

• 3 роли
• 5 событий
• 3 артефакта

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

Роли — это зоны ответственности в команде. Есть всего три роли:

1. Владелец продукта — scrum product owner
2. Разработчики — developers
3. Скрам-мастер — scrum master

При этом владелец продукта, этот совсем не заказчик и не конечный выгодоприобретатель. А разработчики — далеко не всегда (или не только) программисты. Тут есть сложности перевода, но мы сейчас все объясним.

У каждой роли в скрам-команде есть свои задачи. Если кто-то из них не действует в своей роли эффективно, другие страдают.

Владелец продукта — scrum product owner

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

А еще владелец единолично принимает решения и определяет, какие задачи должна решать команда в первую очередь. У разработчиков есть право голоса, но это все рекомендации. Окончательное решение за владельцем.

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

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

Разработчики — developers

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

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

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

Скрам-мастер — scrum master

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

Какие функции выполняет. Главная задача — обучение команды методологии скрама. Мастер отвечает за соблюдение командой регламентов, условий, сроков и ищет пути для оптимизации процессов. Кроме задач организатора и тренера, мастер решает вопросы обеспечения — рассчитывает и согласует ресурсы команды, устраняет возможные препятствия, которые мешают прогрессу. Также мастер отвечает за фасилитацию взаимодействия группы со всеми заинтересованными лицами.

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

События еще называют церемониями (да, звучит странно). В scrum все события крутятся вокруг спринтов. Спринт — это единица времени, за которую команда выпускает часть продукта. Обычно спринт длится 1–4 недели и имеет конкретную цель. Например, добавить в приложение платежную систему или разработать новый раздел сайта, внедрить процесс регистрации, построить 1 комнату дома.

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

Все события так или иначе связаны со спринтом. Всего их пять:

1. Планирование спринта
2. Проработка бэклога
3. Ежедневные встречи — стендапы
4. Обзор спринта
5. Ретроспектива

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

Планирование спринта

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

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

Проработка бэклога

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

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

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

Ежедневные встречи — стендапы

Это такой формат планерок, коротких ежедневных совещаний на 10–20 минут. Обычно стендапы проводят в начале рабочего дня — чтобы обсудить выполненные за прошлый день работы, обменяться мнениями, обсудить косяки и попросить совета. Каждый член команды в финале формирует рабочий план, по которому будет отчитываться на следующем стендапе.

Обычно каждый участник докладывает:

1. Какие задачи были решены за прошедший рабочий день
2. Какие задачи планируется решить сегодня
3. Что может помешать

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

Обзор спринта

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

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

Ретроспектива

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

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

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

Если использовать скрам при строительстве дома, то:

1. Проработка бэклога — составление подрядчиком перечня работ с учетом их приоритета. Например: проектирование → заливка фундамента → строительство каркаса стен → прокладка инженерных коммуникаций → работа с кровлей → отделка и пр.
2. Планирование — обсуждение прорабом и бригадой перечня работ, которые можно выполнить за спринт. Например, заливка фундамента за 1 неделю
3. Стендап — ежедневное обсуждение выполненных работ: сколько бетона залили сегодня, какой объем зальем завтра, сможет ли бетонщик замешать нужное количество бетона и пр.
4. Обзор — бригада презентует фундамент заказчику. Подрядчик проводит испытания, замеры и решает, готов ли фундамент к строительству каркаса стен, выдержит ли он необходимую нагрузку. Подрядчик принимает работу и актуализирует план работ
5. Ретроспектива — бригада вместе с мастером и подрядчиком обсуждают проблемы, задержки с поставками стройматериалов, необходимость привлечения новых людей в бригаду

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

Есть всего три артефакта:

• бэклог продукта
• бэклог спринта
• инкремент

Бэклог продукта

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

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

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

Пример простого бэклога продукта с описанием задач и оценкой затрачиваемых ресурсов команды.

Пример более сложного бэклога с описанием пользовательских историй, оценкой сложности, расстановкой приоритета и тегами.

Бэклог спринта

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

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

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

Инкремент

Это цель, которую команда ставит на спринт и которую нельзя изменять в процессе. Инкремент — сумма всех элементов бэклога, которые команда выполняет за 1 итерацию с учетом ценности всех инкрементов, достигнутых за все прошлые спринты. Текущий спринт всегда заканчивается готовностью нового инкремента: владелец принимает работоспособный элемент бэклога, который соответствует «критериям готовности», введенным командой.

Возвращаемся к нашей строительной бригаде. Для нее:

1. Бэклог продукта — это строительный паспорт объекта, проектная документация, согласованная в архитектурном бюро
2. Бэклог спринта — объем работ на неделю. Например, при заливке фундамента это: 1) разметка, 2) земляные работы, 3) возведение опалубки, 4) армирование, 5) заливка, 6) гидроизоляция.
3. Инкремент — итоговая цель на неделю — готовый фундамент

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

• в строительстве
• в образовании
• в маркетинге
• при реализации бизнес-проектов
• в финансовой сфере
• в проектировании
• в энергетике и пр.

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

1. Аудит бизнес-процессов
2. Планирование, разработка проекта внедрения
3. Настройка софта
4. Подключение отдела продаж
5. Подключение и настройка интеграций
6. Обучение менеджеров по продажам
7. Масштабирование на другие отделы

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

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

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

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

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

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

1. Это набор рекомендаций по организации процессов в команде. Такой себе подход в управлении проектами. Он построен на принципах аджайла и предполагает гибкость разработки продукта, готовность к изменениям и нацелен на постоянное улучшение
   
2. Scrum предполагает командную работу короткими итерациями — спринтами. В конце каждой итерации команда выдает жизнеспособный продукт или его часть, готовую к внедрению. Спринт не может закончится без выдачи результата. Если результата нет — спринт не заканчивается
3. Главное правило в работе скрам-команды — концепция «3-5-3»: 3 роли, 5 событий, 3 артефакта. Если чего-то из этих составляющих нет, скрам не сработает
4. Scrum применяется чаще всего в IT при разработке софта. Но подойдет и для других областей, где работает проектное управление, есть неопределенность, рынок постоянно меняется, а компании выпускают сложные продукты
5. Scrum не подойдет, когда есть типовые решения, последствия ошибок слишком высоки, а команда и заказчик не вовлечены в производство