[БЕЗ_ЗВУКА] [БЕЗ_ЗВУКА] Всем привет. В этом видео мы подробнее рассмотрим роль скрам-мастера и команды разработки. Напоминаю, что команда разработки выполняет всю работу по созданию нашего продукта. Важно понимать, что все участники такой команды должны быть полностью освобождены от участия в других проектах. Это важно, потому что только так можно достичь максимальной производительности такой команды, и как следствие, максимальной скорости поставки нашего продукта на рынок, то есть time to market. Помогает им в этом скрам-мастер. Главная цель скрам-мастера — это воспитать крутую команду. «Крутую» означает: эффективную, быструю, самоорганизованную. Как же он это делает? Первое, что важно понять, что скрам-мастер не является менеджером, то есть он никому не ставит задачи. Помогает он по-другому: он проводит встречи и помогает на этих встречах группе прийти к общему решению, устраняет препятствия на пути команды разработки и воспитывает в ней самоорганизацию. Чтобы встречи проходили эффективно, первое, что должен делать скрам-мастер, это следить за тем, чтобы они не затягивались. Поэтому в скраме все события имеют вот это максимальное ограничение по продолжительности — time box. При этом, чтобы группа на этих встречах приходила к решению, скрам-мастер использует фасилитационные техники, или фасилитацию. Основной его инструмент — это открытые вопросы. На пути команды разработки может стоять множество препятствий: технических, бюрократических, психологических и других. Как пример: в одной из крупных компаний, в которой я запускал команду, в эту команду попали новые сотрудники для этой компании, и оказалось, что у них нет даже рабочих компьютеров и доступа к необходимой тестовой среде. При этом оказалось, что в этой компании заявка на то, чтобы этим сотрудникам выдали компьютеры, обрабатывается две недели. В этом случае скрам-мастер обязан попытаться, хотя бы попытаться, найти решение вот этой бюрократической проблемы и решить ее, чтобы команда двигалась быстрее. Важно понимать, что скорость команды прямо пропорциональна скорости устранения препятствий на ее пути. Скрам-мастер также воспитывает в команде самоорганизацию. Это очень сложная тема, ей у нас посвящен целый следующий модуль. Я лишь скажу, что в первую очередь это означает, что скрам-мастер не принимает сам решения за команду разработки, даже если он знает это лучшее решение. Если он будет это делать сам, то группа просто не станет принимать таких решений. В моей самой первой команде, где я стал скрам-мастером, я при этом был самым опытным программистом. И на планировании спринта зачастую я видел, что тот или иной элемент бэклога можно реализовать более простым способом, чем команда разработки планировала это сделать. И мне было очень тяжело сдерживаться, чтобы я сам не дал это самое лучшее решение команде разработки, я позволял им ошибиться. Тогда это постепенно привело к тому, что они, во-первых, повысили свою квалификацию, во-вторых, находили это решение сами. Есть шутка про скрам-мастера, что хорошей крутой команде скрам-мастер на самом деле не нужен, потому что она умеет все делать сама, принимать эффективные решения и устранять препятствия на своем пути. Давайте посмотрим чуть более подробно, чем менеджер проекта отличается от скрам-мастера. Менеджер проекта составляет план проекта, раздает задачи и контролирует их исполнение. Скрам-мастер же в отличие от менеджера проводит и помогает проводить встречи, а на самих встречах помогает участникам договориться. Менеджер проекта у нас координирует работу, а скрам-мастер спрашивает у команды, что ей мешает двигаться быстрее, и устраняет эти препятствия на пути команды. Цель менеджера проекта — это закончить проект, то есть достичь его цели в рамках бюджета и времени. А цель скрам-мастера — воспитать или построить эффективную команду. Интересно взглянуть, чем отличается владелец продукта от скрам-мастера. Напоминаю, что цель владельца продукта — это создать крутой и востребованный продукт, а цель скрам-мастера — воспитать крутую, эффективную, быструю команду. Теперь мы знаем цели всех ролей скрама, команды разработки, скрам-мастера и владельца продукта. Давайте попытаемся ответить на вопрос, что будет, если у нас хромает какая-то из этих ролей. Например, что будет, если у нас плохой скрам-мастер, но хороший владелец продукта и классная команда разработки? Скорее всего, мы получим качественно сделанный и востребованный рыночный продукт, но при этом команда будет делать его медленно. Что будет, если у нас плохой владелец продукта? Скорее всего, команда будет быстро делать хороший, качественный продукт, который никому не нужен. И что произойдет, если у нас плохая команда разработки? Скорее всего, такая команда будет быстро делать востребованный продукт, но он будет очень низкого качества с большим количеством багов. В следующем видео мы рассмотрим, как проходит ежедневный скрам. [ЗВУК]