Недавно между тренерами Scrum.org разгорелась дискуссия относительно вопроса, какой Спринт можно считать неудачным. Мы почти сразу пришли к одному мнению.
А, по вашему мнению, что такое неудачный Спринт:
Вопрос действительно очень интересный и я предлагаю разобраться в нем.
Скрам для продукта, а не проекта. Итак, начну с самого банального вопроса – что же такое Скрам и какая его цель?
Скрам – это фреймворк для разработки и поддержки функционально сложных ПРОДУКТОВ. Скрам – это фреймворк, в рамках которого возможно решать сложные адаптивные проблемы и в то же время продуктивно и креативно разрабатывать ПРОДУКТЫ наивысшего качества (Скрам Гайд, 2013).
Я привел цитату из Скрам Гайда для того, чтобы напомнить нам о том, что Скрам фокусируется на разработке креативных ПРОДУКТОВ, а не ПРОЕКТОВ.
Главная цель использования Скрама – создание продукта, который будет востребован конечными пользователями и который будет приносить удовлетворяющий нас Return On Investment (ROI).
Один из самых больших рисков в разработке ПО – создание невостребованного продукта. Скрам снижает этот риск благодаря частым циклам обратной связи. Для получения успешного продукта Скрам Команда регулярно проводит демонстрацию (инспектирует Инкремент) на Обзорах Спринта, где присутствуют ключевые заинтересованные лица и конечные пользователи продукта. Мы получаем жизненно необходимую обратную связь и, получив ее, Владелец Продукта корректирует дорожную карту продукта (адаптируем Беклог Продукта).
Спринты как проекты и эксперименты. С другой стороны, работая в Скраме и фокусируясь на разработке успешного продукта, мы двигаемся вперед при помощи коротких перебежек или проектов, которые называются Спринтами.
Каждый̆ Спринт может считаться проектом длительностью не более одного месяца. Как и проекты, Спринт используется для достижения целей. Спринт состоит из определения того, что нужно разработать, дизайна и гибкого плана, служащего ориентиром при разработке, работы по проекту и полученного в результате продукта (Скрам Гайд, 2013).
Десятки лет мы считали критерием успешности разработки программного обеспечения попадание в золотой треугольник менеджера (Time, Cost, Scope). Как результат – тысячи загубленных проектов, потраченных средств и никому не нужных продуктов, потому что треугольник имеет лишь косвенное отношение к успешности продукта.
Скрам – эмпирический процесс и каждый Спринт в нем является экспериментом.
В конце каждой итерации вы эмпирически инспектируете функциональность, которая была разработана. Объем ее может быть менее или более того, что было спрогнозировано. Тем ни менее, вы знаете, что было сделано и можете принимать решения на основе полученных результатов. Эмпирический процесс не дает определенности, он просто показывает возможности (Кен Швабер, Software in 30 days).
И вот мы, наконец, подходим к самому главному. Учитывая то, что каждый Спринт является экспериментом, а Скрам – эмпирический процесс:
Надо сказать, что эта концепция тяжело укладывается в голове у большинства людей. Мы привыкли считать успешность команды по количеству фич, которые успела команда «наколбасить» за Спринт.
Пример успешного Спринта:
Команда не достигла Цели Спринта, переоценив свои силы на Планировании и взяв слишком много функционала. На Обзоре Спринта мы честно демонстрируем заинтересованным лицам то, что «готово», даже если «готового» совсем мало. Получаем обратную связь, какой бы она ни была. Владелец Продукта принимает решение, финансировать ли следующий Спринт или нет. Ответ может быть как положительным, так и отрицательным. В случае положительного решения, Скрам Команда идет на Ретроспективу, где инспектирует себя, свои процессы и инструменты для того, чтобы провести их адаптацию в следующем Спринте.
Пример неудачного Спринта:
Команда «наколбасила» большое количество функционала и «принесла» на Обзор Спринта ровно то, что обещала («благодаря» некоторому овертайму и сниженному качеству). Но только на Обзоре Спринта никого, кроме Владельца Продукта не оказалось. Конечных пользователей мы вообще никогда не видим, а другие заинтересованные лица слишком заняты, чтобы ходить к нам. Обратная связь отсутствует. На Ретро мы «забиваем», потому что работы много. Начинается следующий «удачный» Спринт.
Подведем итоги:
Удачных вам инспекций и адаптаций, друзья!
Меня привлекли человечный подход, ставка на живое общение и постоянное стремление увеличивать ценность. До этого работал менеджером проекта, и разница на лицо.Денис Сальников из N26 В Скрам-мастера стоит идти, если вы хотите помочь сотрудникам профессионально развиваться и вместе улучшить процесс работы, — у вас будет достаточно влияния, чтобы бросить вызов устаревшей системе управления. Ещё эта роль подойдёт тем, кто хочет выпустить передовой Продукт, — Скрам-мастера больше всего нужны инновационным компаниям.
Я пришла в новый отдел маркетинга, что помочь производителю программного обеспечения освоить рынок b2c. В компании уже был заметен Аджайл, но не было маркетинга как такового, и никто не знал, как маркетологам использовать Скрам. Я стала кем-то вроде проводника знаний о фреймворке.Лана Сан из AGILE CAFÉ 敏捷教育訓練中心 Если вам нравятся правила Скрама или вы хотите попробовать его в своей отрасли, тогда вперёд. Осталось разобраться, каково вам будет в новой роли и как её освоить.
Нужны терпение и навыки фасилитации. Скрам-мастер не может дать ответ напрямую — только подвести к нему.Лана Сан из AGILE CAFÉ 敏捷教育訓練中心 Скрам-мастером стать проще, если вы уже были неформальным лидером в коллективах. Сможете разрешить конфликт любой сложности: с отдельными сотрудниками, между Командой или в компании. Проще будет и оптимистам, которые не боятся изменений. Действия Скрам-мастера дают результат не сразу, и вашего запала должно хватить, чтобы довести всё до конца.
Большая часть работы Скрам-мастера — развитие коммуникаций, и ему пригодится умение договариваться со всеми в формате win-win.Михаил Скляренко из «Моего дела» Скрам-мастером стать сложнее, если вы не айтишник и не эйчар. Тренер Unusual Concepts Сергей Лобин советует найти опытного коллегу в качестве ментора. Ещё сложнее придётся людям, которые любят контролировать каждый шаг Команды.
Людям с сильным эго и глубокими техническими познаниями труднее всего воздерживаться и не влиять на принятие всех решений.Денис Сальников из N26 Если вы обладаете подходящими качествами или ваши качества хотя бы не усложнят работу, осталось воспользоваться одним — готовностью учиться.
Практика нужна, чтобы строить Скрам в компании, фасилитация — чтобы хорошо проводить встречи, а коучинг — чтобы лучше работать с людьми.Андрей Редин из «Альфа-Банка» Обучаться правилам Скрама — обязательное условие. Иначе вы не сможете оценить, насколько строго их соблюдают, и не сделаете компанию гибкой. В процессе обучения важно усвоить ценности Аджайла, чтобы знать, когда от правил Скрама можно отступить в пользу Продукта. Обучаться можно у аккредитованных тренеров. Это необязательно, но существенно увеличит шансы сдать экзамен и получить международный диплом.
Нельзя рассчитывать, что знание наизусть Руководства по Скраму без усвоения ценностей Аджайла поможет стать хорошим Скрам-мастером.Михаил Скляренко из «Моего дела» Обучаться коучингу можно в Международном Эриксоновском Университете или на тренингах. Есть тренинги по конфликтологии, бюджетированию — все они расширят ваш кругозор. Обучаться фасилитации стоит у крутого фасилитатора. Сергей Лобин советует Дмитрия Лазарева.
Умению слушать людей научиться тяжело. Но фасилитация ещё на старте поможет завоевать доверие сотрудников и компании.Сергей Лобин из Unusual Concepts Если вы уже обучены, поищите стажировку. В каждой компании свой Скрам, и чем больше увидите, тем лучше поймёте суть. Говорят, в «Альфа-Банке» уже пробуют стажёров. Можете устроиться и в штат. Полноценную роль Скрам-мастера предлагают в крупных компаниях. Спасибо Денису Сальникову, Лане Сан, Михаилу Скляренко, Андрею Редину и Сергею Лобину за помощь со статьёй.
Блин, я не соглашусь с примерами удачных и не удачного спринта и с определением неудачного спринта.
Вы пишите - "Неудачный Спринт – тот, в конце которого мы ничему не научились. Мы не инспектировали результаты и не провели адаптацию продукта и процессов".
Вот это определение, для процесса подходит очень хорошо. у нас есть процесс ради процесса. А целью всей работы и в частности внедрения гибких методологий является ускорение разработки, быстрый вывод фичи/продукта в бой. И при неудачном спринте, когда мы цели не достигли - мы этого не делаем.
Вот пример: пререквизиты - за спринт мы делаем 20 SP. Цель спринта: создание мега крутой платежной карты(9SP), еще 9SP различные задачи.
В конце спринта мы выполнили 100% "различные задачи". а вот цели задачи на 100% не закончили.
Бизнес посмотрел, что данное предложение не актуально, может потому что конкуренты раньше выпустили и все. Спринт провалили, у бизнеса убытки. Это конечно достаточно утрированно, но зато видно, почему спринт провалили.
Да команда соберется обсудит, что можно было улучшить, но спринт уже провален, следующий спринт может быть будет лучше.
Пример успешного думаю приводить не стоит, достигли цели спринта - значит спринт успешный. Даже если мы заявили, что выполним 20 задач + 1 задачу для достижения цели спринта и выполнили только ее, а 20 даже не трогали. Главное мы достигли цели спринта.
В конце спринта мы ничему не научимся, спринт направлен на решение задач, а выводи и предложения для улучшения процессов на ретро. Вот где действительно строятся процессы под продукт.
PS: дописал коммент и вижу что статья чертовски старая ) Слава привет.
[…] мы разбирались в таком тонком вопросе, что же такое неудачный Спринт. Я часто замечаю, что, несмотря на кажущуюся простоту […]
[…] количества предположений. Спринт можно считать неудачным только в том случае, если не прошла инспекция и […]
Согласен, если прошла инспекция и адаптация того, что они сделали.
Не соглашусь насчет достаточности, потому что главную обратную связь должны давать конечные пользователи - те люди, которые и будут пользоваться продуктом. Иначе все наше предприятие может закончиться тем, что продукт будет никому не нужен. Мы считаем, что если на Обзоре Спринта не присутствуют конечные пользователи - это дурной знак.
Совершенно верно и они должны интегрироваться и выкатывать готовый рабочий инкремент каждый Спринт, как и в случае с одной командой.
Сюда остается добавить только, что в этот же день на бирже акции компании рухнули вниз. :)
Спасибо за комментарий, thumbs up!
Илья, спасибо за очередную хорошую статью. Хотел прокомментировать итоги - с радостью соглашусь с третьим пунктом. Первый и второй в некоторой степени очевидны, и как по мне не сильно связаны с "удачностью спринта". Кроме того, как мне кажется - в некоторых случаях вполне даже хорошо, когда команда просто делает определённое количество фич, на которые закоммитилась. Если ПО "правильный" - он даст достаточную обратную связь, а улучшать свой процесс команде никто не мешает и без бизнес-пользователей. Не всегда же одна скрам команда делает один продукт - команд может быть много, и может быть много суб-продуктов, разработка которых согласовывается с глобальными целями организации - тогда как раз и надо, чтобы на самом первом уровне - уровне "атомарных" команд - вовремя и качественно делались маленькие фичи, из которых на уровнях выше и соберётся большой супер-продукт.
И немного чернухи - неудачный спринт, это когда маршрутка с дев. командой, дружно едущей на планирование, сбивает стоящих на остановке ПО и СМ :)))