Проект приостановлен. Менторские проверки, группы и активности недоступны. Предлагаем только самостоятельное обучение на платформе.
Українська
Українська
Русский
Українська
Українська
Русский

Сообщение об ошибке

Вы собираетесь отправить сообщение о следующей ошибке:

Пожалуйста, опишите суть ошибки

5 ситуаций, когда Scrum не нужен, и что с этим делать

Мы написали эту статью вместе с Олегом Свирским, Senior Product Manager в Vimeo. Вот его фейсбук.

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


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


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

После этой статьи будет полезно прочитать о том, как использовать фреймворки.

Что такое этот ваш Scrum

Scrum — подход к разработке, в котором команды работают по спринтам от 1 до 4 недель. Команды состоят из 5-9 человек и самостоятельно распределяют задачи между собой. 


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

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

Но не всем командам удобно работать по Scrum. Разберем пять таких ситуаций.

Марк и дизайнеры

Ситуация:

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

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

После планирования спринта Марку написал дизайнер Крис.

Привет, Марк! Хотел дать обратную связь по работе в рамках спринта. Мне и второму дизайнеру Майку неудобно планировать задачи на неделю вперед.


Привет, Крис! Расскажи подробнее, почему.
Мы работаем одновременно с пятью командами разработчиков. Все работают над разными фичами. Поэтому сложно планировать заранее — почти каждый день приходят новые задачи. Мы просто решаем их по мере появления. Заканчиваем одну и приступаем к следующей.
Хм, понятно. Попробуем организовать вашу работу иначе.

Решение:

В этой ситуации поможет фреймворк Kanban. На Kanban доске команда будет видеть, сколько задач нужно сделать («To-do»), сколько выполнено («Done»), а сколько находится в работе («Doing»). 

Kanban даст больше гибкости в управлении потоком задач. Разработчики будут добавлять свои задания в колонку «To-do». А дизайнеры будут выполнять одну задачу за другой. В отличие от Scrum, они могут принимать сколько угодно запросов от других команд.

Но тут важно не забывать про WIP (Work in Progress). Это ограничение на число задач, которые может одновременно делать один сотрудник. Дизайнеры Крис и Майк могут брать каждый раз по одной задаче. К следующей они приступят, когда закончат делать текущую. Такой подход поможет им не терять фокус, а разработчикам — эффективно использовать ограниченные ресурсы.

сравнение Scrum и Kanban

Попробуйте решить одно из заданий по этой теме из нашего нового курса «Взаимодействие с командой разработки».

Задание

В какой ситуации лучше использовать в работе Kanban, а не Scrum?


Выберите несколько вариантов
Гайд по лучшим статьям skillsetter
В нашем блоге уже больше 150 статей про рост продуктов и карьеру в IT. Для удобной навигации мы объединили их в тематические подборки.
Выбрать подборку

Мэри и сложная задача

Ситуация:

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

После встречи она решает уточнить у Боба, что ему мешает сделать свою часть работы.

Привет, Боб! Расскажи, пожалуйста, с какими трудностями ты сейчас столкнулся во время работы?
Привет, Мэри! Никак не могу закончить интеграцию с платежным сервисом. Выскакивает ошибка. Два дня уже ломаю голову, в чем причина. Мне кажется, что я не успею доделать к релизу модуль оплаты для сайта.

Решение:

Каждый участник Scrum-команды во время спринта делает свой кусок работы. Но бывает так, что программист может столкнуться со сложной задачей, и для ее решения понадобится еще чья-то помощь. Так появилось парное программирование.


Пара состоит из двух человек: драйвер и навигатор. Драйвер пишет код, а навигатор проверяет каждую строчку кода и говорит драйверу, что делать дальше. 


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

Мэри решает предложить Бобу попробовать парное программирование.

Может быть тебе стоит найти себе напарника и попробовать вместе с ним парное программирование? Свежий взгляд не помешает. Так больше шансов, что вы успеете закончить задачу вовремя.
Может быть ты права и действительно стоит попробовать. Но вообще я не очень люблю болтать во время работы. Проще поискать в Google. 

Кажется, Боб испытывает дискомфорт в работе и общении с другими разработчиками. Как Мэри лучше объяснить ему преимущество парного программирования перед одиночным?


Выберите несколько вариантов
Бесплатный курс по продакт-менеджменту
За 3 дня вы научитесь мыслить как продакт и успешнее справляться с задачами на работе и в жизни
Начать учиться бесплатно

Адам и масштабный проект

Ситуация:

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


Предстоит разработка нового продукта, поэтому вы решаете организовать работу по Scrum и проводите спринт-планирование.

После планирования Адаму пишет Джессика, тимлид одной из команд разработки.

Привет! Моя команда и команда Стивена пока не закончили обсуждение. Правильно понимаю, что нам нужно еще раз встретиться, чтобы завершить планирование?
Привет, Джессика! Все верно. Чуть позже напишу время и место встречи.
Окей. Меня только напрягает, что команды Лизы и Майка хотят приступить к разработке уже завтра. Тебе не кажется, что так мы рассинхронизируемся?

Решение:

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


Здесь поможет подход SAFe  (The Scaled Agile Framework). Он предлагает инструменты для управления масштабными проектами, где участвует много команд. 


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

Задание

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

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

Как в этом случае вернуть мотивацию разработчикам и улучшить качество фич?


Выберите один из вариантов

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

сравнение фреймворков Scrum и SAF

Лиза и не самоорганизованные команды

Ситуация:

В компании Лизы три команды разработчиков работают вместе над созданием модуля по аналитике: 

  • группа #1 отвечает за базы данных, 

  • группа #2 делает коннектор, который передает данные из баз в модуль, 

  • группа #3 строит графики и диаграммы на основе полученных данных. 


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

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

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

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

Привет, Лиза! Думаю, дело в том, что нас слишком много и мы не можем самоорганизоваться.

Мы с тимлидами иногда не можем даже решить, какую задачу какой команде дать.

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

Мне кажется тут все очевидно...

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

Решение:

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

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

Посмотрите, как улучшилось время на подготовку к релизам после того, как в команде появился релиз-менеджер. Похожих результатов добилась у себя и компания «Додо Пицца».

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

Читайте лучшие статьи по продакт-менеджменту

Раз в неделю будем отправлять свежий дайджест вам на почту. Наc читает 25000 человек 🚀

Алекс и компания, где и так все работает

Ситуация:

Продакт-менеджер Алекс предложил руководству компании начать работать по Scrum. До этого Алекс уже внедрял Scrum и успешно работал по нему. Сейчас он хочет использовать этот подход в текущей команде.

Алексу пишет тимлид команды Джессика с целью обсудить его новую идею.

Привет, Алекс! Слышала, ты хочешь внедрить в работу нашей команды Scrum. Не уверена, что это хорошая идея.
Привет, Джессика! Почему ты так решила?
Наша команда работает сейчас над крупным и сложным проектом. Если мы начнем резко менять все наши процессы, можем замедлиться и не успеть сделать все в срок.
А вдруг, когда мы внедрим Scrum, эффективность команды вырастет в 2 раза, и мы закончим проект еще быстрее, чем рассчитывали?
У нас сейчас и так хорошие стабильные показатели каждую неделю. Работаем на 7 баллов из 10. 
А можем работать на 10 из 10.
Может так и будет, а может и нет. Но точно знаю, что эффективность команды упадет на несколько баллов и продержится на таком уровне пару месяцев, прежде чем восстановится. И не факт, что в итоге, все станут работать лучше. 

Решение:

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


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


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

Резюмируем

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


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

Рекомендуем почитать

Телеграм-каналы про IT

100 лучших телеграм-каналов о маркетинге, росте продуктов и карьере в IT

статья о go to market strategy

Как выйти на новый рынок: кейс от опытного предпринимателя

шаблон формулировки гипотезы для локальных проблем

Как сформулировать data-driven гипотезу за 5 шагов: на примере RPG игры

← Читать другие статьи в блоге Получить реальные навыки