Фреймворк scrum что это

Что такое Scrum и как правильно использовать его в рабочем процессе

Фреймворк scrum что это. Смотреть фото Фреймворк scrum что это. Смотреть картинку Фреймворк scrum что это. Картинка про Фреймворк scrum что это. Фото Фреймворк scrum что это

Что такое Scrum

Коротко говоря, Scrum — это способ организации рабочего процесса. Он пришел из мира разработки программного обеспечения и сейчас применяется в разных сферах бизнеса. Метод изобрели программисты Кен Швабер и Джефф Сазерленд. Они наблюдали за тем, как работают американские военные и спецназ и пришли к выводу, что основа успеха состоит в качественной командной работе. Сам же термин пришел из регби и в переводе с английского означает «схватка».

Scrum принадлежит к Аgile — семейству »гибких» подходов к организации процессов. Он состоит из минимального количества элементов, которые помогают успешно организовать работу. При помощи метода Scrum можно быстро и эффективно разработать принципиально новый продукт, аналогов которому нет на рынке.

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

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

Состав scrum-команды

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

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

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

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

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

Основные принципы работы по Scrum

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

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

Чем Scrum отличается от Kanban

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

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

Преимущества Scrum

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

Вице-президент «Ренессанс страхование» Владимир Тарасов рассказал РБК Трендам, к каким результатам пришла компания после применения метода:

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

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

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

Недостатки Scrum

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

Владимир Тарасов:

«Scrum не подходит для текущей операционной деятельности. Он больше ориентирован на проекты. У нас не классический Scrum. Мы объединили текущую работу по конкретным страховым случаям с проектами и задачами на улучшение процесса, разработку и испытание новых инструментов. Scrum не дает ответа, как сочетать операционную работу с проектами. Мы придумали свои собственные инструменты сочетания несочетаемого. Сам фреймворк это допускает».

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

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

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

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

Как внедрить Scrum для управления бизнес-процессами

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

Как внедрить Scrum в компанию

Подробную инструкцию по внедрению Scrum и о его процессах можно посмотреть в гайде или в книге от соавтора методологии Джеффа Сазерленда «Scrum: революционный метод управления проектами». О том, как правильно распоряжаться ресурсами и повышать личную эффективность, читайте в материале РБК Трендов про бережливое производство в жизни.

Источник

Скрам (Scrum)

Определение Скрама

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

Руководство по Scrum 2017

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

Эти слова из Scrum Guide требуют пояснений:

Фреймворк scrum что это. Смотреть фото Фреймворк scrum что это. Смотреть картинку Фреймворк scrum что это. Картинка про Фреймворк scrum что это. Фото Фреймворк scrum что это

Особенности Скрама

Scrum — прост. …
Фреймворк Scrum намеренно неполный, и определяет только части, необходимые для реализации теории Scrum.
Руководство по Scrum 2020

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

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

В частности, в Скраме отсутствуют конкретные рекомендации по техникам проведения скрам-мероприятий. Например, до 2020 года в Руководстве по Скраму в качестве примера приводился конкретный формат проведения мероприятия «Ежедневный Скрам» (с ответами каждого участника на 3 вопроса). Если команда не понимала ценностей Agile и Scrum, то этот формат зачастую приводил к бессмысленному механическому ритуалу проведения Ежедневного Скрама, поэтому его убрали даже как пример.

Скрам-команда

Вот, пожалуй, главная особенность Скрама в сравнении с другими подходами, следующими ценностям Agile-манифеста:

Основная единица Scrum — небольшая команда людей, Scrum Team. … Scrum Teams являются кросс-функциональными, то есть, их участники обладают всеми навыками, необходимыми для создания ценности в каждом Sprint. Также они самоуправляемы, то есть, сами решают, кто, что, когда и как делает.
Руководство по Scrum 2020

Именно c самоуправлением и кросс-функциональностью связан тот факт, что Скрам, несмотря на всю его простоту, достаточно сложно применять на практике. Откуда возникает потребность в самоуправлении/кросс-функциональности и как она реализуется в Скраме для IT-команд — рекомендуем посмотреть в 10-минутном видео от Асхата Уразбаева:

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

Скрам – эмпирический подход к управлению

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

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

Скрам сегодня – это не только про разработку программного обеспечения

Связь Скрама с другими подходами

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

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

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

Например, «давно работающие по Аgile» команды могут переходить со Скрама на какой-то собственный скрамоподобный процесс или на Scrumban. При этом они уменьшают время, затрачиваемое на мероприятия Скрама, получают возможность изменять длительность итерации (спринта) по ходу работы или даже отказываются от оценок работы на спринт, используя безоценочное (no estimate) планирование на основе собранной статистики. Для зрелых команд это полезно, но это не Скрам.

Однако для начинающих Agile-команд Скрам является отличным выбором, так что неудивительно, что этот фреймворк является самым популярным среди гибких подходов как в России, так и во всем мире.

Резюме: как описать Скрам простыми словами

Если обойтись почти без англицизмов, то вышесказанное можно сформулировать так:

Подробнее о Скраме вы можете почитать в статье Scrum: что это и зачем нужно.

Понимаете ли вы Скрам?

Ответьте на 8 вопросов теста по Agile/Scrum, получите подборку ссылок на статьи/видео/курсы и рекомендации в зависимости от результата теста.

Адаптация (Adaptation)

Один из трёх Принципов Скрама. При обнаружении отклонений от допустимых пределов одного или несколько элементов процесса или продукта, и если эти отклонения могут привести к бесполезности продукта, следует внести соответствующие изменения – либо в процесс, либо в разрабатываемые материалы (продукт).

Скрам предписывает четыре формальных мероприятия для инспекции и адаптации:

Инспекция (Inspection)

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

Прозрачность (Transparency)

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

Эмпиризм (Empiricism)

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

Мы хотим, чтобы компании были крутыми, а люди в них — счастливыми

Источник

Что такое Scrum, для чего он нужен и кому подходит

Фреймворк scrum что это. Смотреть фото Фреймворк scrum что это. Смотреть картинку Фреймворк scrum что это. Картинка про Фреймворк scrum что это. Фото Фреймворк scrum что это

Фреймворк scrum что это. Смотреть фото Фреймворк scrum что это. Смотреть картинку Фреймворк scrum что это. Картинка про Фреймворк scrum что это. Фото Фреймворк scrum что это

Фреймворк scrum что это. Смотреть фото Фреймворк scrum что это. Смотреть картинку Фреймворк scrum что это. Картинка про Фреймворк scrum что это. Фото Фреймворк scrum что это

Фреймворк scrum что это. Смотреть фото Фреймворк scrum что это. Смотреть картинку Фреймворк scrum что это. Картинка про Фреймворк scrum что это. Фото Фреймворк scrum что это

Фреймворк scrum что это. Смотреть фото Фреймворк scrum что это. Смотреть картинку Фреймворк scrum что это. Картинка про Фреймворк scrum что это. Фото Фреймворк scrum что это

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

Откуда возник Scrum

В 1986 году в статье для Harvard Business Review японские учёные Икуджиро Нонака и Хиротака Такеучи рассказали, что проекты с небольшими командами из разнопрофильных специалистов систематически приносят лучшие результаты. Они назвали это «подходом регби». В 1991 году в книге «Нечестивые проблемы, праведные решения» подход впервые называют регбийным термином «scrum».

Но Scrum в более-менее том виде, что мы знаем сейчас, появился позже — в 1995 году Кен Швабер и Джеф Сазерленд впервые представили методику на конференции OOPSLA. В течение следующих лет они продолжали работать над Scrum. Сейчас это детальнейше описанная методика, по которой есть и своё собственное руководство (The Scrum Guide), и куча книг, и даже пара аккредитующих компаний: Scrum Alliance и Scrum.org.

В чём идея Scrum

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

Согласно Scrum, над проектом должна работать небольшая команда от 3 до 9 человек (если у тебя команда больше, придётся её разбить на несколько небольших). Команда работает непрерывно, короткими итерациями (спринтами) продолжительностью 1–4 недели. В конце каждого спринта команда должна создать что-то ценное для заказчика. То есть работа не просто разбивается на итерации. Каждая итерация должна иметь смысл и приносить пользу.

Как работает Scrum

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

Итак, над проектом работает так называемая scrum-команда. Она состоит из разработчиков (а также маркетологов, дизайнеров и любых других специалистов, которые нужны в проекте) и людей, которые берут на себя особые роли: владельца продукта (Product Owner) и scrum-мастера.

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

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

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

Артефакты

Ещё в Scrum есть три сущности, называемые артефактами:

События

В основе Scrum лежат спринты, но с ними связано ещё несколько важных событий, без которых Scrum не Scrum.

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

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

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

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

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

Плюсы Scrum

Управление проектом по Scrum со всеми этими ежедневными стендапами со стороны выглядит, как тотальный контроль, но у методики есть и свои плюсы:

Минусы Scrum

Правда минусов тоже немало. Кроме проблем с тщательным следованием всем ритуалам (создание бэклога, митинги и т. д.), есть ещё:

Кому подходит Scrum

Сейчас Scrum распространился за пределы разработки ПО — его используют и в маркетинге, и в бизнесе, и в образовании, и много где ещё. Проще всего очертить границы применения Scrum на уровне целей. Scrum можно применять для разработки продуктов и регулярных его обновлений, а также поиска новых решений и технологий. Причём не только в работе, но и в личных делах. Даже приготовление борща можно организовать по Scrum.

Источник

Почему Scrum не сработал, или Уверены ли вы, что точно знаете, что такое фреймворк?

Фреймворк scrum что это. Смотреть фото Фреймворк scrum что это. Смотреть картинку Фреймворк scrum что это. Картинка про Фреймворк scrum что это. Фото Фреймворк scrum что это

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

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

Как Scrum появился в вашей компании?

Последние лет 5 Scrum стал настолько популярен, что о нём не говорит разве что моя бабушка. И это логично, ведь основные причины такой популярности в том, что Scrum прост для понимания, и для его применения есть подробное Руководство (Scrum Guide), помогающее командам эффективно создавать сложные продукты с высокой ценностью и в условиях высокой неопределённости. Более того, Scrum уже давно выходит за пределы разработки программных продуктов. Сами основатели этого фреймворка в обновлённой версии Scrum Guide от ноября 2020г., признаются, что «следят за тем, как Scrum всё больше используется в постоянно растущем комплексном мире». Но есть и подводные камни –например, из-за такой популярности на этот фреймворк его часто применяют совершенно не подкованные в нём люди.

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

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

Если вы действительно хотите применить гибкие подходы к управлению, то начинать следует с изменения структуры управления в организации, меняющую среду работы людей. Только в этом случае их образ мышления будет меняться, а новые методы работы будут соответствовать их восприятию собственных действий. В пример можно взять «Сбербанк»: результатом полноценного внедрения Scrum которого стало создание глобальной структуры, обеспечивающей необходимый уровень гибкости организации. Изменяя способ выполнения работы, мы меняем и тип мышления сотрудников. Scrum не может возникнуть из неоткуда, он должен поддерживаться и внедряться в первую очередь со стороны руководства организации – а иначе он обречён.

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

Это наталкивает нас на мысль о ещё одной причине неудачного внедрения Scrum: это требует слишком больших изменений и приносит слишком много боли как сотрудникам, так и руководству. Если корпоративная культура в организации в достаточной степени соответствует принципам Agile, внедрение Scrum происходит достаточно гладко – он более осознанно воспринимается сотрудниками, создаётся необходимое напряжение и выход из зоны комфорта, который в свою очередь способствует изменению культуры и обеспечивает успешное внедрение Scrum и Agile-трансформацию организации. Но в тех случаях, когда организационная культура далека от принципов Agile, попытка внедрения Scrum чаще всего приводит к печальным результатам.

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

В какой системе Вы существуете?

Фреймворк scrum что это. Смотреть фото Фреймворк scrum что это. Смотреть картинку Фреймворк scrum что это. Картинка про Фреймворк scrum что это. Фото Фреймворк scrum что это
Ист. Кеневин (Cynefin): способ думать о ситуациях, проблемах, системах

Часто бывает так, что мы не знаем, когда применять Scrum и в какой среде он совершенно бессмыслен – а из-за этого “таких делов можно наворотить”. Да, Scrum нужен не всегда и не во всём. Чтобы узнать, подходит именно вам Scrum или нет, можно воспользоваться моделью «Кеневин» или Cynefin (англ. Среда обитания), которая позволяет компании определить, в какой системе она существует, а значит выбрать верную модель управления, коррелирующую с компетенцией команды. Разработал методику Дейв Сноуден, в прошлом возглавлявший Институт управления знаниями на базе IBM, а ныне сооснователь центра Cognitive Edge и консультант по вопросам менеджмента знаний.

Схематично модель построения систем представлена на рисунке, мы видим расположенные по периметру окружности, символизирующие системы:
• упорядоченные – простые и сложные;
• неупорядоченные, или комплексные;
• хаотичные.

В центре схемы – зона неопределенности, которую нужно как можно быстрее покинуть.

Опишу каждую подробнее, чтобы понять, в каких системах Agile и фреймворк Sсrum не подходят, а какая – та самая, в которой нужен именно Scrum.

1. Упорядоченные простые системы (Simple, Obvious)
Они понятны, для их решения у команды есть опыт. Уже на старте понятно, что получится в результате, за какие деньги и в какие сроки. Нередко есть инструкция по выполнению этого действия. Самый простой пример – сборка комплектующих на заводе или производство стульев.
Формула принятия решений также проста: Определяем – Классифицируем – Реагируем.

2. Упорядоченные сложные системы (Complicated)
В этом случае заранее не понятно, как решать проблему. Задача не уникальна, однако именно ее команда ранее не решала. Показательным может быть пример создания типового сайта, у команды есть согласованное ТЗ от заказчика, шаблон, план работ, а изменения в процессе работы скорее всего не потребуются. И на выходе получится готовый продукт, по которому предлагаются корректировки и поддержка некоторое время.
Формула принятия решения: Определяем – Анализируем – Реагируем.

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

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

4. Хаотичные системы (Chaotic)
Здесь хорошо работает экспериментальный подход. Хаотичные – абсолютно новые задачи, которые никто и никогда не решал раньше. Попытка разобраться с такой системой – путь к инновациям. Любой способ решения (стабилизации системы) будет новым. Порой нужно действовать вразрез с традиционными методами менеджмента. В реальной жизни это может быть стартап или падающие стены в момент, когда вы читаете эту статью и здесь остаётся только действовать, причём как можно скорее!
Формула принятия решения: Действуем – Определяем – Реагируем.

Успели сориентироваться в какой из систем подходят именно гибкие практики управления? Ответ очевиден, даже если оттолкнуться от определения Scrum – «это лёгкий фреймворк, который помогает людям, командам и организациям создавать ценность с помощью адаптивных решений комплексных проблем», и поэтому его можно применить только в Комплексной, сложной системе: в остальных он будет чувствовать себя не так уверенно, или же будет совершенно бессмысленным, что принесёт большую потерю в деньгах и времени.

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

Попробуйте спросить себя: действительно ли у меня настолько большая изменчивость, для внедрения Scrum? Если ответ отрицательный, не усложняйте, приглядитесь к другим более эффективным практикам, которые существуют для каждой из этих систем. Для упорядоченных простых подходит каскадная методология управления проектами, для упорядоченных сложных систем – подходы PMI, Prince2 и PMBoK, а в хаотичных необходимо действовать как можно скорее, чтобы выжить – поэтому подойдёт экспериментальный метод управления основанный на новых ещё не зарекомендовавших себя подходах.

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

Дальше необходимо определиться с тем, кто будет нести ответственность за применение Scrum в соответствие сo Scrum Guide, и ключевая в этом плане ответственность лежит на Scrum-мастере.

Нашли ли Вы своего Scrum-мастера?

Фреймворк scrum что это. Смотреть фото Фреймворк scrum что это. Смотреть картинку Фреймворк scrum что это. Картинка про Фреймворк scrum что это. Фото Фреймворк scrum что это
Ист. Разница между хорошим Скрам Мастером и отличным Скрам Мастером

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

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

Что может быть показательно? Конечно, уже реализованные успешные кейсы претендента на эту роль. Но если это только начинающий специалист, их может быть недостаточно. В таком случае можно дать команде лично познакомиться со Scrum-мастером, так она точно выберет именно своего. Прекрасная статья на тему того, что должен уметь хороший Scrum-мастер и можете ли вы им стать, написана Василием Савуновым, Agile-коучем компании ScrumTrek.

Важно также помнить, что Scrum-мастер должен тщательно продумать правильный подход к внедрению Scrum в своих командах, т. к. насильственные методы не совместимы с принципами гибкого управления. Иногда это значит, что вместо попыток сделать всё как по учебнику мы последовательно приближаем структуру и правила работы команд к тем, которые прописываются в руководстве. Чтобы минимизировать ошибки начинающего Scrum-мастера, можно почитать о типичных из них в моей статье Разбор полётов-уроки и выводы начинающего Scrum-мастера.

Scrum-мастер помогает людям договариваться между собой, как на уровне организации, так и на уровне команды. Помните один из принципов Agile “люди важнее процессов и инструментов”? Всё дело в них – людях, которые могут брать на себя сложные задачи и совместно решать нетипичные проблемы; но без Scrum-мастера, без возможности договариваться Scrum останется лишь инструментом, способным сократить лишь очереди задач без улучшения продуктивности.

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

Примерные вопросы, которые могут вам помочь:

1. Оцените, насколько Scrum-мастер помогает команде достигать целей (0 – никак, 10 – есть ощутимая помощь)

2. Оцените полезность Scrum-церемоний (0 – трата времени, 10 – есть ощутимая польза):
a. Планирование
b. Дейли
c. Спринт ревью (демо)
d. Ретроспективы

3. Были ли конфликтные ситуации в команде?
a. Если да, как Scrum-мастер помог их разрешению? (0 – никак не помог, 10 – помог команде конструктивно решить конфликт)

4. Насколько согласны с утверждениями (0 – вообще не согласен, 10 – абсолютная правда):
a. «При общении со Scrum-мастером я чувствую, что мою позицию слышат и понимают»
b. «Scrum-мастер помогает нам справляться с возникающими сложностями»
c. «Scrum-мастер стремится сделать нашу команду лучше»

5. Ощущаете ли вы, что продуктивность команды растет?

6. (опционально) Три вещи, за которые вы могли бы поблагодарить своего Scrum-мастера

7. (опционально) Три вещи, которые Scrum-мастеру стоит улучшить

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

Играете ли вы по правилам?

Вы пробовали играть в шахматы 20 фигурками вместо 32? «Зачем мне это делать,» – скажете вы, – «ведь тогда это станет совсем другой игрой с неизвестным исходом». Но, почему-то не задумываясь над этим, мы продолжаем выкидывать, как фигурки с шахматной доски, события или ценности из фреймворка Scrum.

Чтобы правильно внедрить Scrum, важно следовать чётким правилам и работать в рамках практик фреймворка. Кен Швабер в своём блоге пишет: «Scrum – это как игра в шахматы. Вы либо играете по правилам, либо не играете совсем».

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

Уверена, найдутся те внимательные, кто скажет: «а как же гибкость?» Здесь уместно сказать, что Scrum – это фреймворк практик, связанных небольшим набором чётко определённых правил. Фреймворк, в отличии от метода, предлагает более гибкую платформу, обуславливая ряд правил, но не ограничивает применение любых других практик и подходов в зависимости от той или иной рабочей среды. Например, в Guide представлены следующие события Sprint, Sprint planning, daily scrum, sprint review, sprint retrospective, исполнение которых обязательно, но этоне ограничивает проведения любых иных событий (например, встреч Brainstorm ideas или встреч, связанных с Research и шаринга знаний на команду или команды).

Резюмируя

Пожалуйста, не поддавайтесь моде, проанализируйте и соотносите риски с возможностями. Подумайте, в какой системе находитесь и какой стиль управления подходит именно вам.

Определились с тем, что у вас высокоизменчивая комплексная среда, отлично – вливайтесь в Agile! Но помните, что работать в направлении трансформаций должны высокомотивированные профессионалы и особенно тщательно нужно подходить к выбору Scrum-мастера. И конечно же, не поддавайтесь соблазну отменять те правила, что написаны в Руководстве. Может быть, не сразу, но постепенно внедряйте best practice в свой быт и будет вам счастье.

Источник

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *