На каких проектах нужен scrum-мастер
– рассказывает Дмитрий, PM

Scrum-мастер точно не нужен лёгкому, строго ограниченному по времени и функциональности проекту. Потому что там scrum не нужен 🤷‍♀️ Например, это разработка интернет-магазина на Битриксе с минимальной кастомизацией.

А вот нужен он, когда у нас есть некий продукт, который будет долгое время развиваться. Для этого набирается команда, и она в плюс-минус неизменном составе ведёт продукт до конца. Здесь может не быть чётко сформированного ТЗ. Ведь когда мы говорим про гибкие методики, мы можем стартовать только с идеи.

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

Классический кейс, что scrum-мастер работает вместе с командой с самого начала. Основной смысл его деятельности – это обучить команду основам scrum, фасилитации* мероприятий scrum и самостоятельной работе с коллективной ответственностью. Как тренер)
*Фасилитировать ≠ модерировать. Ну например, мы собрались на планирование, каждый участник должен иметь понимание: что нам нужно иметь на входе, что – на выходе, зачем вообще это мероприятие нужно. То есть важно не просто управлять ходом мероприятия, а доносить его сакральный смысл.

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

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

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