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 — методология гибкой работы команды. На сегодняшний день пользуется большой популярностью, применяется во многих крупных компаниях. В этой статье разберемся, когда и при каких обстоятельствах возникла техника, на каких базовых принципах строится ее реализация, что важно учитывать при работе и многое другое.
История появления Scrum
У истоков развития разработки программного обеспечения стоял «водопадный» подход к работе, его использовало большинство команд и делило реализацию продукта на следующие этапы:
Так работали из года в год, пока одна команда новаторов долгое время наблюдала за успешными коллективами: теми, кому удавалось соблюдать дедлайны и делать качественный продукт. В результате у них возникло понимание, что успех кроется в гибкости процесса.
На основе выводов, сделанных по результатам долгих наблюдений, вывели «Манифест гибкой разработки программного обеспечения». В него включили четыре пункта:
В 2001 году они детально описали принципы своей методологии и выпустили книгу «Agile Software Development with SCRUM». На сегодняшний день этот подход считается одним из самых популярных среди разработчиков.
Базовые принципы Scrum
У методологии есть несколько базовых принципов, которые помогают ориентироваться на клиента и давать ожидаемый результат при минимальных ресурсных и временных затратах.
Базовые принципы Scrum:
Scrum-команда
Scrum-команда в большинстве случае состоит из 5-9 человек, реже — из 3-4. В рамках скрама коллектив не может быть больше, потому что усложняется взаимодействие между каждым звеном, что негативно сказывается на эффективности работы.
Состав
В команде есть три основные роли:
Владелец продукта
Владелец — ответственное за разработку лицо. Эту роль занимает заказчик продукта или его официальный представитель. В редких случаях — представитель рынка, на котором впоследствии реализуют запланированный проект.
Владелец отвечает за составление бизнес-плана, в котором отражается ожидаемый экономический эффект. Также в нем он определяет план развития, в котором для каждого пункта рассчитывается коэффициент окупаемости вложений. Еще один важный документ, формированием которого занимается владелец, — список требований, они сортируются по важности.
Если говорить просто, то владелец продукта — центр принятия решения для проектной команды. Он должен быть единственным в рамках проекта, иначе принцип быстрого принятия важных решений нарушается.
Примерный перечень обязанностей владельца:
Скрам-мастер
Скрам-мастер отвечает за соблюдение методологии Scrum в работе: контролирует инициативность и самостоятельность всех членов команды, удовлетворенность получаемыми результатами, атмосферу в коллективе и итоги работы в общем.
Причем важно понимать, что скрам-мастер — это не просто какое-то обособленное лицо, наблюдающее за разработкой со стороны. Он — член команды и должен наравне с контролем принимать непосредственное участие в технической реализации продукта.
Скрам-мастер отвечает за взаимодействие всех членов команды между собой, поддержание работоспособности на высоком уровне, устранение проблем, следованием намеченному графику работ.
Примерный перечень обязанностей скрам-мастера:
Разработчики
Разработчики — те, кто отвечают за техническую реализацию продукта. Как правило, на одну команду приходится 5-9 разработчиков. Первая задача — постановка реально достижимых, прогнозируемых, интересных и значимых целей для каждого спринта.
Вторая задача — достижение поставленных целей каждого спринта в установленные сроки (дедлайн). Достижение цели — растяжимое понятие и определяется в каждом проекте индивидуально. Например, где-то задачу считают выполненной после написания всех кодов, а где-то добавляют еще и окончание тестирования. В общем, все руководствуются собственным видением и опытом.
Ключевые навыки для команды разработчиков — планирование, объективная оценка выполненной работы, умение взаимодействовать с другими членами коллектива.
Примерный перечень команды разработчиков:
Принципы работы Scrum-команды
Успешная работа по методологии Scrum возможна при соблюдении трех принципов:
Процесс работы Scrum-команды
Работа команды, руководствующей методологии Scrum, условно делится на несколько этапов.
1. Планирование списка задач спринта. Каждый спринт начинается с планирования. Все члены команды собираются, оценивают бэклог продукта в целом и выбирают приоритетные задачи, которые необходимо выполнить в рамках текущей итерации. Так формируется список задач (бэклог) текущего спринта.
После этого на основе бэклога оговаривается объем работ и длительность цикла. Также заранее определяют результат: что должны получить по итогам спринта.
2. Проведение регулярных совещаний. Ежедневно или еженедельно команда проводит короткие совещания (не более 15-30 минут). В них участвуют владелец продукта, скрам-мастер и все разработчики. Цель встреч — получить от каждого ответы на три вопроса:
3. Организация скрам-доски. В конференц-зале, где проводятся регулярные совещания, вешается доска, разделенная на три части: «что нужно сделать», «в работе» и «сделано».
В каждой части размещают стикеры разных цветов с основными задачами. По мере выполнения они перемещаются от одной части к другой. Это помогает отслеживать прогресс текущего спринта каждому члену команды.
4. Изменение планов в ходе итерации. Команда должна быть открытой и если один специалист не успевает уложиться в срок, то сообщает об этом владельцу продукта. Он поменяет расстановку задач, оптимизирует рабочее время и поможет уложиться в дедлайн.
То же самое делается и при слишком быстрой работе, когда задачи выполняются быстрее запланированных сроков. Руководитель дополняет бэклог новыми целями по собственному усмотрению, чтобы реализация продукта протекала быстрее.
5. Подведение итогов. После завершения каждого спринта проводится тестирование выполненной части программного обеспечения. В нем также принимают участие потенциальные потребители (фокус-группа). Владелец собирает обратную связь и принимает решения для успешной работы в дальнейшем.
Артефакты Scrum
Scrum-проекты включают в себя три важных документа, их еще называют артефактами:
Журнал продукта
Журнал продукта в самом начале готовит владелец. Документ (артефакт) включает в себя требования, отсортированные по значимости. Первичную версию дополняют разработчики: оценивают стоимость реализации каждого требования.
Бэклог продукта должен включать в себя не только технические аспекты, необходимые для реализации, но и функциональные. Для каждого требования определяется приоритет (например, от 1 до 5). Самые приоритетные описываются детально, чтобы команда смогла оценить их и протестировать.
Владелец продукта обязан не только подготовить журнал продукта, но и предоставить его в оговоренные сроки. В противном случае своевременная реализация проекта невозможна.
Журнал спринта
Как вы помните, в рамках скрам-методологии продукт реализуется мелкими итерациями. Как правило, один спринт — одна функция. Для эффективной работы она разбивается на мелкие задачи так, чтобы на реализацию уходило не больше 2-3 рабочих дней.
Грамотная разбивка функций на задачи позволяет к концу итерации выполнить все необходимое, чтобы определенная часть программного обеспечения работала корректно и представляла ценность для конечного потребителя.
После составления бэклога спринта его оценивает команда разработчиков и сопоставляет с журналом продукта. При наличии существенных отклонений коллектив определяет наиболее приоритетные задачи в рамках текущего спринта и менее важные, которые допустимо перенести на следующую итерацию.
Задача владельца продукта — исключить из бэклога мелкие и незначительные задачи, выполнение которых никак не повлияет на конечный результат работы.
График спринта
График спринта — это расписанный задачами календарь работы в рамках текущей итерации. В нем отображается оставшийся до конца спринта объем работы. Команда регулярно оценивает график и при необходимости оперативно реагирует на какие-либо изменения.
Особое внимание календарю уделяет владелец продукта. По нему оценивается скорость работы и соблюдение дедлайнов. Например, если со временем объем работы не уменьшается, значит, в процессе есть какие-то отклонения и требуется срочная корректировка действий команды.
Как правильно внедрить Scrum-методологию
Для повышения эффективности работы команды необходимо правильное внедрение Scrum-методологии. Допущенные ошибки могут не только ничего не изменить, но и негативно сказаться на продуктивность.
Если вы решились на изменения, проводите внедрение поэтапно:
Кому-то из команды нововведения могут не понравиться. Это естественно, когда люди противятся чему-то новому. Ваша задача — донести до каждого члена команды пользу новой методологии.
Подведем итоги
Scrum — это методология гибкой разработки, основанная на принципах Agile. Ее разработкой занялись в 90-х годах прошлого столетия, а широкую известность она начала обретать в начале 00-х годов. На сегодняшний день скрам используют многие команды, чья деятельность тесно связана с проектами.
Scrum можно внедрить в свою компанию за 6 шагов, но следует тщательно подходить к организации процесса. Специальных знаний от сотрудников методология не требует, здесь скорее вопрос в организации и правильном построении рабочего времени.
При этом не забывайте, что скрам — не волшебная пилюля, если у вас наблюдается постоянный срыв дедлайнов, плохая атмосфера внутри коллектива, внедрение новой техники не решит всех проблем. Поэтому изначально наладьте коммуникации внутри команды, постройте эффективную работу, а затем внедряйте scrum для повышения продуктивности.
Scrum: что это и зачем нужно
Когда команда начинает применять Scrum, ее работа, как правило, становится более слаженной и предсказуемой, а сроки разработки новых продуктов зачастую сокращаются в разы. Но бывает так, что внедрение Scrum проваливается, и вместо пользы компания получает убытки и негативный опыт.
Мы расскажем не только о ключевых особенностях фреймворка Scrum и областях его применения, но и о том, какие основные ошибки мешают командам получить максимум выгоды от внедрения Scrum. И проиллюстрируем, что Scrum (Скрам) — это не доски со стикерами и не «методология разработки», диктующая команде процесс работы.
Статью можно считать первой главой учебника по Scrum, она проиллюстрирована несколькими видео по самым сложным темам Scrum и содержит ссылки для того, чтобы разобраться глубже и чтобы начать применять Scrum у себя. Однако если вы хотите более строгое и более краткое описание — почитайте прокомментированные определения понятий Скрама из глоссария Scrum.
Что такое Scrum
Scrum — легкий фреймворк, который помогает людям, командам и организациям создавать ценность с помощью адаптивных решений комплексных проблем.
Руководство по Scrum 2020
Scrum — легкий фреймворк, который помогает людям, командам и организациям создавать ценность с помощью адаптивных решений комплексных проблем. Для начинающих будет понятнее сказать, что Scrum — это способ организации рабочего процесса. Он содержит минимально необходимое количество элементов, чтобы воплотить на практике ценности и принципы Agile. Слово «фреймворк» («каркас») означает, что из этих обязательных элементов в каждом случае можно построить свой процесс, дополнив Scrum конкретными методами работы.
Однако такое «чисто процессное» определение Scrum не вполне соответствует роли этого подхода в современном управлении (на это и намекает вышеприведенное определение из Scrum Guide 2020). Scrum глубже, чем процессы.
Внедряя Scrum, компании должны быть готовы на серьезную перестройку оргструктуры, продуктового менеджмента и многих других вещей, а отнюдь не только на перестройку процессов уровня отдельных команд (которые, собственно, описываются Скрамом).
К примеру, Scrum требует получать готовую к использованию новую версию продукта каждый месяц или чаще. Это требование не только выявляет кучу процессных дисфункций (долгие сроки согласований и т.п.). Это также влечет за собой, например, изменение поведения бизнес-заказчиков, которые должны быть готовы сотрудничать с разработчиками на порядок чаще, причем напрямую, а не через документы.
Давайте посмотрим, стоят ли выгоды, которые сулит Scrum, той высокой цены, которую приходится платить за столь радикальные организационные изменения (особенно радикальные для крупных бюрократизированных организаций).
Зачем нужен Scrum, и чем он отличается от прежних методологий разработки
Scrum предназначен для быстрой разработки и поставки сложных, принципиально новых продуктов, которых нет на рынке.
Когда зрелого продукта еще нет, а есть только идея и, может быть, первые рабочие прототипы, тогда никто не может дать четкий план, куда должна пойти траектория разработки. Все неопределенно и требует проверки на реальном клиенте. А Scrum позволяет постепенно «развеять» эту пелену неопределенности, двигаясь небольшими итерациями и постоянно проверяя: мы делаем то, что нужно клиентам? приносит ли это пользу?
Водопадная модель
До появления Scrum и других подобных подходов чаще всего применялась водопадная модель разработки, где есть последовательные этапы, например:
— формирование первичных требований;
— анализ требований;
— оценка;
— формирование ТЗ;
— разработка;
— тестирование;
— приемка;
— поставка.
Каждый этап водопадного процесса начинается только по окончании предыдущего. Двигаться можно только вперед, так что результат этапа не должен требовать доработок в будущем. Как следствие, каждый этап удлиняется в силу большого числа согласований. В итоге выпуск сложного продукта растягивается на многие месяцы или даже годы.
Итеративная модель
Такие методологии как RUP, появившиеся в конце XX века, были более эффективны за счет итеративной модели: все или некоторые этапы выполняются несколько раз в цикле, а при обнаружении проблем есть возможность вернуться на предыдущий этап. Тем не менее, и здесь первый результат виден клиенту после первой итерации только по окончании всех последовательных этапов. Это может оказаться слишком долго относительно ожиданий заказчиков в XXI веке.
Основная проблема всех подобных методологий и методов разработки — в неполноте и несвоевременности обратной связи от клиентов. Это приемлемо для типовых продуктов, когда потребности клиентов во многом известны по прошлому опыту. Но неприемлемо в ситуации высокой неопределенности требований, которая имеет место для новых инновационных продуктов.
Фреймворк Scrum – эмпирический подход
В середине 1990-х годов Кен Швабер и Джефф Сазерленд создали фреймворк Scrum, который помогает разрабатывать новые продукты быстрее и с постоянной обратной связью от клиента. В его основе – эмпирический подход к управлению. Это означает, что видение продукта и даже процесс его разработки не детерминированы заранее, а адаптируются к данным, поступающим в ходе разработки. Это недешево, но выгоднее полной переделки неудачных продуктов, созданных по обычному детерминированному процессу в условиях неопределенности.
Термин «Scrum» Швабер и Сазерленд позаимствовали из регби (не путать с американским футболом). Scrum означает состояние команды перед стартом матча, когда они сцепившись, стоят и ждут, когда судья вбросит мяч, и они рванут, чтобы опрокинуть своих соперников и доставить мяч на другой конец поля. То есть, Scrum означает готовность совершить рывок.
Основы работы по Scrum
Выделим 3 главные особенности процесса разработки, основанного на Scrum.
Работа ведется итерациями, которые в Scrum называют спринтами
Результатом работы может считаться лишь то, что готово к использованию
То есть, это не может быть какой-то промежуточный результат типа дизайна или непротестированного кода программного продукта. Как правило, это то, что может принести ценность клиенту (конечному потребителю продукта). На этапе формулировки требований в Scrum это называется элементом бэклога продукта, а на планировании спринта он переходит в бэклог спринта.
По окончанию спринта элемент считается выполненным, лишь если он полностью готов к использованию, т.е. соответствует критериям готовности. Впрочем, необязательно результат спринта (который в Scrum называется инкрементом продукта) передавать для использования клиентами сразу после спринта, т.е. решение об этом принимается по ситуации.
Продукт разрабатывает самоуправляемая команда
В Scrum-команду, помимо разработчиков продукта, входят также владелец продукта как ответственный за успех продукта представитель заказчика/клиента, и Scrum-мастер как ответственный за эффективность команды в целом. Но никто из них не диктует разработчикам, как работать: разработчики в Scrum образуют самоорганизующуюся команду.
Начиная с 2020 года, Руководство по Scrum сменило фокус с самоорганизованной команды разработчиков на самоуправляемую Scrum-команду. Это еще больше подчеркнуло важный факт: разработчики, скрам-мастер и владелец продукта находятся в одной лодке, ответственность за результат эта Scrum-команда несет как единое целое. Самоуправление в Scrum подразумевает самостоятельность не только в выборе того, кто и как будет делать работу (самоорганизацию), но и в выборе того, над чем именно работать, чтобы достичь цели продукта.
Состав Scrum-команды
Разработчики
В Scrum разработчиками называют отнюдь не разработчиков программного обеспечения. Это любые специалисты, которые вносят свой вклад в продукт. Например, маркетологи (хотя не только они) будут входить в качестве разработчиков в команду, занимающейся разработкой и поддержкой тарифов на услуги компании.
Ответственность разработчиков в целом — делать качественный продукт, совместно находя подходящие для этого решения и не ожидая указаний извне. А их ответственность на уровне отдельного спринта — выполнять те обязательства, которые команда взяла на себя в ходе планирования спринта.
Разработчики в Scrum не имеют каких-либо персональных обязанностей, они рассматриваются как единая команда. Вот особенности Scrum-команды, которые связаны именно с разработчиками (а не с владельцем продукта и Scrum-мастером, которые рассматриваются в следующих разделах):
Постепенно, команда становится все более самоорганизующейся, сплоченной и сработанной, так что ей не нужен «погонщик» в виде какого-то менеджера или лидера, и при этом ее производительность растет. Внутри команды есть лишь Scrum-мастер, который помогает ей становиться такой.
Владелец продукта
С одной стороны, владелец продукта — это человек, который общается с клиентами и другими заинтересованными в продукте лицами (нередко их называют заказчиками).
Владелец продукта отвечает за то, чтобы создать действительно классный и ценный для клиентов продукт.
С другой стороны, владелец продукта работает с разработчиками, отвечает на их вопросы по элементам бэклога, своевременно уведомляет об изменениях, приходящих со стороны бизнеса/клиентов. Никто не имеет право ставить задачи разработчикам в обход владельца продукта. Как член Scrum-команды, он участвует в мероприятиях Scrum: в планировании, обзоре и ретроспективе спринта.
Иногда владельца продукта путают с менеджером проекта. Это совсем не одно и то же:
Подробнее об отличиях владельца продукта и менеджера проекта смотрите в 4-минутном видео от Дмитрия Кустова:
Scrum-мастер
Добиться самоуправления в Scrum-команде очень сложно. Для этого в команде есть специально обученный человек — Scrum-мастер, отвечающий за эффективность команды и за правильность процесса разработки с точки зрения Scrum. Он помогает команде стать самоуправляемой и приучает разработчиков к тому, что они (хотя и вместе с владельцем продукта) несут ответственность за продукт. Он учит людей договариваться между собой, помогает им сплотиться и больше доверять друг к другу.
Scrum-мастер — не начальник, он не ограничивает и не наказывает. Его роль — помочь команде разобраться, какие препятствия мешают ее работе на максимуме эффективности. И научить ее устранять эти препятствия, будь то процессные дисфункции внутри команды, плохие коммуникации команды с конкретными внешними людьми/отделами или какие-либо устаревшие регламенты, действующие во всей организации.
Scrum-мастер делает так, чтобы команда договорилась между собой, как она будет устранять препятствия. Самые сложные препятствия, причина которых обычно вне команды, на первых порах устраняет сам Scrum-мастер. Но в идеале даже для этого Scrum-мастер постепенно становится не нужен самоуправляемой команде. Правда, достичь этого высшего уровня самоуправления часто мешают такие факторы как нестабильность состава команды или радикальные изменения в продукте, над которым работает команда.
В чем заключается повседневная работа Scrum-мастера — смотрите в видео от Василия Савунова:
А как директивные руководители постепенно превращаются в Scrum-мастеров — подробно рассказывает статья Василия «От контроля к самоорганизации в команде».
Agile и Scrum: в чем разница и что общего
Agile от Scrum отличается тем, что это общая система ценностей, тогда как Scrum — это все же руководство к конкретным действиям: проведение конкретных встреч, создание конкретных артефактов, конкретное разделение ответственности между людьми.
Scrum является практической реализацией ценностей Agile. Можно сказать, что Agile — это как Конституция, где в сжатой форме общими словами декларируются основополагающие ценности и принципы, а Scrum — это система более подробных законов, через которые реализуется все описанное в Конституции.
Основную цель Agile и Scrum часто формулируют как сокращение Time2Market — времени выпуска на рынок новых продуктов / времени их поставки потребителю.
Достижение этой цели может быть под угрозой как в силу нарушения Конституции (т.е. по причине работы вопреки 4-м ценностям и 12-ти принципам Agile), так из-за нарушения конкретных законов (например, в результате удаления из Scrum каких-либо мероприятий).
Ценности Agile: 
Agile-подходы, среди которых самым популярным сейчас является Scrum, сильно отличаются от формализованных методологий разработки продуктов, где подробно описываются процессы: кто, что и когда должен делать. При работе по Agile на первое место вместо процессов выходят люди, а упор делается на тесное взаимодействие как между разработчиками, так и с заказчиком, а также на готовность к изменениям с обеих сторон.
Agile и Scrum: конкретный пример
Это реальный пример из одного крупного российского банка. Он иллюстрирует не столько процесс на базе Scrum, сколько практическое применение Scrum-командой следующих принципов Agile:
Ситуация: бизнес отдал разработчикам техническое задание про SMS-рассылки для заемщиков с задолженностью, в которых предлагалось простить им пени за просрочку, если они перейдут по ссылке и отправят в банк обязательство погасить долг в такой-то срок. Разработчики почитали ТЗ и оценили срок проекта в 3 месяца, что совершенно не устраивало заказчика.
Scrum предполагает встречи разработчиков с заказчиком вместо общения через документы, и на такой встрече Scrum-мастер предложил обсудить: а для какой цели вообще затевается этот проект?
Оказалось, что бизнес пока не ждет от SMS улучшения показателей просрочки, а цель — «прощупать», на что больше реагируют разные сегменты должников. То есть, это был проект для проверки гипотезы.
Разработчики стали предлагать оптимизацию задания, чтобы достичь той же цели быстрее и дешевле:
В итоге, поговорив с заказчиком, разработчики предложили довольно много оптимизаций, и сообща выработали внятное видение MVP требуемого функционала. И этот MVP (Minimum Viable Product) был сделан всего за 2 недели.
Какие компании применяют Scrum
В первом десятилетии XXI века Scrum стал самым популярным среди гибких подходов к разработке новых программных продуктов. Однако сейчас фреймворк успешно используется во многих других индустриях: в материальном производстве (например, Северсталь, SOKOLOV), в маркетинговых агентствах и дизайнерских студиях, в телеком-компаниях (Tele2, МТТ), в фармакологии (BIOCAD), в розничных сетях (X5 Retail Group, МВидео) и др.
Наиболее известные в мире кейсы внедрения Agile и Scrum — Google, Amazon, Zappos.
Российские кейсы применения Scrum вы можете найти в видеозаписях докладов ежегодной конференции AgileDays от руководителей из таких компаний как UnitedTraders, Технологический Центр Дойче Банка, SEMrush, Uniscan-Research, QIWI, Банк Агророс, Додо Пицца и от десятков других.
Например, в 2016 году у компании Северсталь появилось желание ускорить выпуск на рынок новых марок стали. Изначально этот процесс занимал в среднем 2-2,5 года и иногда к моменту появления их на рынке, они часто не находили спроса, или оказывалось что конкуренты (в частности, Китай) уже закрыли потребность рынка в этой марке стали. Компания запустила первые пилотные команды для разработки продуктов по Scrum. Они оказались успешными — срок разработки новой продукции сократился с 2,5 лет до 4 месяцев.
Другие кейсы применения Agile и Scrum в российских компаниях вы можете почитать в разделе Истории клиентов.
Scrum — это не для всех
Чтобы Scrum был выгоден, нужно немало условий. В частности:
Сколько времени нужно, чтобы перейти на Scrum
Чтобы команда вышла на нужный уровень зрелости и работоспособности, нужно минимум три месяца.
А через год работы по Scrum, при условии постоянства состава и отсутствии непреодолимых внешних препятствий, Scrum-команда вполне может стать своеобразным «спецназом», самостоятельно решать проблемы и как орехи щелкать сложные задачи — в разы быстрее такой же команды до перехода на Scrum.
Из-за ошибок при реализации Scrum иногда выход на вершину эффективности может растянуться на годы. Бывает, что не получив результата, руководитель разочаровывается в Scrum и возвращается к привычной модели управления. Посмотрим некоторые из таких ошибок.
Почему работа по Scrum может быть неэффективной
Попытка внедрить Scrum там, где он не подходит
Подробнее о том, когда и зачем нужны Agile и Scrum, вы узнаете из бесплатных видеоуроков Алексея Пименова (11 видео, 65 минут).
Неверное понимание зон ответственности
Типичный пример: владелец продукта не наделен полномочиями формировать видение и состав продукта, он скорее является бизнес-аналитиком, поэтому не может сказать «нет» заказчику.
Бывает еще хуже, когда несколько заказчиков одного продукта не могут договориться между собой.
Не меньше проблем бывает и с зоной ответственности Scrum-мастера.
Во всех таких случаях времени у Scrum-мастера не хватает, поэтому речь уже не идет о развитии самоуправления и кросс-функциональности команды — с помощью коучинга или иных продвинутых инструментов Scrum-мастера.
И тогда Scrum лишь добавляет формальностей в работу над продуктом, но не дает значительного роста эффективности команды.
Scrum без Agile: карго-культ Scrum
Зачастую переход к Scrum ассоциируется исключительно с 4-мя встречами (ежедневный скрам, планирование, обзор и ретроспектива спринта) и со Scrum-досками. После такого перехода:
Другими словами, в компании есть все атрибуты Scrum: бэклог, доска, ежедневные встречи и что-то похожее на демонстрацию результата в конце спринта. Формально все вроде бы соблюдают методику, но вот про ценности Agile забывают. Дмитрий Павлов в своей статье Антипаттерны Agile-команд называет подобное поведение «Scrum-турбацией».
И тогда, например, демонстрационная часть обзора спринта превращается в отчет руководству. Начальник (который в терминах Scrum относится к «заинтересованным лицам» продукта) может на обзоре просто ругать команду за несоответствие между ТЗ и результатом — вместо того, чтобы вместе с командой договориться о следующих шагах и стимулировать команду следовать потребностям бизнеса. А ведь одна из задач обзора спринта как раз в том, чтобы наладить сотрудничество между теми, кто создает продукт и теми, кто его будет использовать или продавать.
Что касается Scrum-доски:
Когда у людей нет Agile-мышления, даже наличие всех элементов Скрама не позволяет сделать команды быстрыми и самостоятельными, продукты — своевременными и успешными, а клиентов и руководителей — довольными.
Применение практик Scrum без Agile-мышления нередко называют «карго-культом», и это — очень частая причина неудачного внедрения Scrum.
Подробнее об Agile-ценностях и карго-культе смотрите в 5-минутном видео Артемия Анцупова:
Как правильно применять Scrum в вашей ситуации
Вы уже разобрались, как должен работать Scrum в теории? И эта статья не разубедила вас в том, что Scrum подходит вашей команде / вашей компании?
Тогда за ответами на вопросы по правильному применению Scrum в вашем кейсе приглашаем вас на онлайн-курс Agile и Scrum, который мы проводим с 2018 года и постоянно совершенствуем. С 2019 года онлайн-занятия курса проходят исключительно в формате практики в мини-командах и разбора вопросов Аджайл-коучем, а вся теория записана на видео и изучается в любое удобное время.
На тренингах ScrumTrek вы также можете подготовить себя или своих подчиненных к работе по Scrum в качестве владельца продукта или Scrum-мастера, а также получить множество других инструментов для повышения эффективности на всех уровнях.
Кейсы и материалы для статьи предоставил Василий Савунов, Agile Coach, партнер ScrumTrek. Их дополнил и оформил Алексей Евдокимов, владелец продукта из ScrumTrek.