Scrum: применять или не применять, вот в чем вопрос

Привет, DOU! Меня зовут Серафима. Я работаю проджект-менеджером в компании ITOMYCH STUDIO. Сегодня я решила поговорить о том, для каких проектов подходит Scrum, а для каких — нет. Я уже получила свой первый Scrum-сертификат — PSM I. Поэтому чувствую моральное право вообще говорить на эту тему. Ну что же, начнем.

Scrum: зачем и о чем говорить

Если вы хоть раз интересовались Agile или работой в IT, это слово вам знакомо. Библия скрама Scrum Guide 2020 говорит:

«Scrum is a lightweight framework that helps people, teams, and organizations generate value through adaptive solutions for complex problems».

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

Когда Scrum нужен нам?

Если бы мы сейчас играли в Alias, и мне бы попалась карточка с фразой «Используй скрам», я бы нарисовала ее именно так:

Мы начинаем первый спринт с минимально скомпозированным беклогом. «Маємо, шо маємо». И пока мы создаем наши первые инкременты, любезный владелец продукта накидывает близлежащие планы. Но многое все же скрыто. И вот когда беклог пустеет, и мы думаем, что конец близок, появляются 3 новые стори. Ура.

Давайте разберем ситуацию на примере.

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

Цель есть, что дальше?

Эта группа выбирает человека, который будет «Владельцем продукта». Остальные решили остаться серыми кардиналами (стейкхолдерами). Дальше эта банда нашла компанию, которая сможет реализовать их задумку. Так у них появились Scrum Master и разработчики.

Время первого спринта

Владелец продукта дал задачу — пусть приложение присылает каждые 3 часа поддерживающие слова. Генерировать оно их будет из нашей базы данных.

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

На следующем Refinement митинге владелец продукта раскрыл идею Scrum команде, ответил на вопросы.

Все, тима готова дальше реализовывать продукт.

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

А все начиналось просто с цитат через каждые 3 часа...

Второй пример, когда Scrum — мама успеха

Когда рынок быстро меняется.

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

Собственный опыт — вот, что очень важно

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

Поначалу там была полная анархия. Но лучше быть сиротой, чем с такой матерью.

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

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

• Мы перестали гнаться за тем, чтобы была документация на весь продукт сразу.
• Систематически презентовали инкремент и получали на него фидбэк.
• Улучшали продукт по фидбэку его владельца (клиента) в последующих спринтах.
• Четче планировали нагрузку на спринт благодаря стори-поинтам.
• Обсуждали все ситуации, которые произошли во время спринта. Хвалили друг друга и планировали, как можно ещё улучшить процесс разработки.

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

«Клиент всегда прав»? А он уверен, что неоновое сияние во время введения арифметических формул — отличная идея? Поэтому одна из задач Scrum Master — говорить клиенту «нет». Со временем это получается все лучше и лучше, я вам скажу ;)

Зачем вся эта суета?

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

— Не нужен твой Scrum — Как бабушкин сон.

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

Шаблонное мышление у тебя, друг

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

Мы знаем, что рынок стабилен, есть четко поставленная задача: создать приложение-компас. Больше ничего от нас не надо. Мы создаем дорожную карту, планируем всю работу. Нас можно больше не трогать. Увидимся, когда будет готово.

Время баг-фикса

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

Группа поддержки

Здесь канбан тоже опередил Scrum. Поддержка продукта после релиза — потоковая работа. Она колыхается в поговорке: «то пусто — то густо». Поэтому Scrum тоже пролетает.

«Скажите мне точную дату и время, когда будет готов проект»

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

Scrum же против оценок и дальноглядного планирования. Чтобы понимать объем работ на спринт, скрамчане используют относительную систему: попугаев, собак, футболки, числа фибоначчи, длину удавов... Взяв самую простую задачу, они называют ее чихуахуа. От нее скрамманы и отталкиваются, называя вторую задачу лабрадором или немецким догом. Поэтому о количестве часов на фичу тут и речи идти не может.

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

А личный опыт учит нас не верить опыту чужому

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

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

Если бы мы использовали Scrum, на Sprint Review мы бы показывали то, что клиент уже 5 раз передумал делать.

Мои статьи — мои итоги

Scrum — популярнейший и самый требовательный фреймворк управления. Но и он не сын маминой подруги, чтобы всем угодить. Я выработала для себя схему выбора фреймворка управления. Чтобы понять, нужен ли вам Scrum, ответьте себе на вопросы:

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

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

Я не претендую на гуру Scrum. Поэтому не воспринимайте мою статью как абсолют.

Scrum-гайд не говорит, когда использовать фреймворк. А значит, стандартов нет.

Исходите из своего опыта. И со временем вы проработаете свою систему по выбору метода управления для каждого отдельного проекта. Возможно, она уже у вас есть, и вы можете поделиться своим опытом в комментариях?