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-гайд не говорит, когда использовать фреймворк. А значит, стандартов нет.

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

👍ПодобаєтьсяСподобалось25
До обраногоВ обраному3
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

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

Для остальных случаев был давно придуман Agile — набор из 12 принципов. Это не методология и не фреймворк, а способ максимально быстро адаптироваться под изменяющиеся требования бизнеса и рынка. Те же компании ФААНГ и другой Big Tech. преимущественно не используют скрам, а нечто вроде Plan->Build (Iterate)->Ship или Kanban, но не формальные методологии типа скрама.

А по поводу самого требовательного метода это вы погарячились. Есть такое SAFe (Scaled Agile Framework) который нифига не agile и в котором конечного пользователя продукта и не видно в принципе. Но зато он имеет дикий оверхеад по ненужным процессам, терминологии и сертификации.

Из моего 10-летнего опыта фриланса: scrum наиболее эффективен для команды из одного человека.

Води тут більше, ніж у Ніагарському водоспаді

Я ресерчила недавно эту тему (про методологии разработки). Со скрамом есть такая проблема, что иногда люди просто ленятся делать проектирование и планирование — и поэтому внедряют скрам. Или не знают, как делать это самое проектирование и планирование.

Вот к примеру, я не знаю как делать вертолеты. А тут заказчик потенциальный наклевывается, и говорит «Лен, сделаешь мне вертолет?» И инвестиции у него есть, чтобы вертолетик-то сделать. Я, если очень хочется подзаработать, подумаю «ну не признаваться же ему, что я не умею вертолеты делать, скажу давай делать по скраму, пусть платит, а там как-то выясним как его сделать или выпетляем»

Вот за это, вышеописанное, скрам не любят или его ярых фанатов не любят.

Еще, кроме scrum и kanban существует куча итеративных и инкрементальных методологий. Почему именно scrum а не XP например предлагается использовать? Поговаривают, что просто потому что scrum — это модно, а не потому что scrum лучше XP.

Розкрутили. До рівня релігії. Бо на ПМа треба вчитися, а щоб стати скрам мастером, досить закінчити ПТУ викреслено курси.

Agile працює, коли напрямок руху продукту коригується потоком побажань від багатьох клієнтів. Але на вищому рівні завжди є планування.

Якщо виробник продукту може сам визначати напрямок руху — є чудові підходи, такі, як мій улюблений PRINCE2. Чи будь-які варіанти вотерфолу з ітераціями.

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

А ось тут вже давно все вигадано, коли використовувати Скрам: thecynefin.co/...​about-cynefin-framework/2. Не треба нічого придумувати.

Очень ценная схема нужен ли Скрам!
Она только подтверждает вывод, который я давно сделал для себя. Я думаю что можно упростить:
1) У вас есть четкие требования, вы можете сформулировать задачу и знаете какой результат вас устроит? Отдайте это все команде инженеров и они реализуют техническое решение без всякого Срама.
2) Вы сами не знаете чего хотите? У вас есть команда вайтишников, каждый из которых умеет что-то и не знает остального? Подменяйте работу на результат работой на создание видимости прогресса!
Срам — это там, где лошара-клиент платит не за результат, а за процесс. Примерно как общение с прихотерапевтом — платишь за «поговорить», решение проблем никто не гарантирует.

У вас есть команда вайтишников, каждый из которых умеет что-то и не знает остального?

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

Для біороботів без пам’яті і емоцій?

Це багато що пояснює...

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

Scrum master говорит «нет» заказчику? What?!

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

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

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

Скрам для продуктовой разработки. Не для управления проектами. Точка!

Ні, не є. Дуже різні підходи до планування, роботи, командної роботи. І, мабуть найголовніше — у проекта є дедлайн, який нам відомий вже на старті (так, рідко хто попадає в дедлайні, але вони є), у продукта немає ніякого попередньо сформованого дедлайну. Ось тут можна подивитись більше www.solutionsiq.com/...​-a-project-and-a-product

+1. Причем статья, в которой авторы Скрама его презентовали, так и называлась: „The New New product development game” а не „The new project management methodology” или „The new software engineering approach”

В книжці Коберна 2003-го року скрам виглядав досить осмислено.

Але те, що з нього роздули — це просто якийсь СММІ для ідіотів.

Підписатись на коментарі