Всем привет! В этом модуле мы подробнее рассмотрим то, как устроена работа Scrum-команды в спринте. А в этом видео подробнее рассмотрим события, которое называется планирование спринта. Цель этого события спланировать работу Scrum-команды на текущий спринт. Участвует в этом событии вся Scrum-команда, то есть, владелец продукта, команда разработки и Scrum-мастер. Для проведения этого события требуется, чтобы у нас уже был подготовлен бэклог с элементами, которые готовы для планирования, то о чем я рассказывал в предыдущем модуле. А здесь надо отметить, что все события в Scrum-е имеют так называемый тайм-бокс, то есть максимальное ограничение по продолжительности. Планирование спринта ограничено восемью часами для спринта длиной в один месяц. Планирование спринта отвечает на два вопроса, что может быть реализовано в продукте в этом спринте и как именно это будет реализовано. Встреча проходит следующим образом. Вначале, команда разработки выбирает из подготовленного бэклога из самых приоритетных его элементов те, которые по ее мнению могут быть реализованы в текущем спринте. Как это понять? Какие именно она успеть сделать? В первом спринте она в буквальном смысле определяет это на глаз по ощущениям, вот это мы успеваем, а вот это уже не успеем. В последующих спринтах, она может опираться на метрику, которая называется скорость команды. Про нее я еще подробнее расскажу в следующих видео. После того как команда разработки выбрала элементы, которые она будет реализовывать в этом спринте. Вся Scrum-команда формулирует цель спринта. Цель спринта - это такая бизнес-цель нашего продукта, которая может быть достигнута благодаря реализации выбранных элементов бэклога. Нужно помнить, что мы делаем функции в продукте не просто так, а для того чтобы они принесли какую-то ценность нашим пользователям и, соответственно, эта ценность может быть выражена в бизнес-метриках продукта. Например, увеличение количества ежемесячных или ежедневных пользователей. После того, как выбранные элементы и выбрана цель спринта, команда разработки разрабатывает план по достижению этой цели. Этот план мы разрабатываем путем декомпозиции выбранных элементов бэклога на задачи. Давайте рассмотрим как это происходит на примере, который я уже приводил в предыдущем модуле, а именно приложение для заказа такси. Итак возьмем бэклог, который мы составили на основе карты истории и его наиболее приоритетные элементы. Напоминаю, я, как пассажир, могу указать адрес отправления и адрес назначения текстом, чтобы заказать такси. Я, как пассажир, могу принять звонок от водителя, чтобы знать когда мне нужно выходить. Я, как пассажир, могу видеть марку, цвет и номер автомобиля, чтобы найти его, когда выйду на улицу. Я, как пассажир, могу видеть сумму поездки, чтобы оплатить поездку наличными. И я, как пассажир, хочу видеть расчетное время прибытия, чтобы иметь возможность скорректировать свои планы. Допустим, команда выбрала первые четыре из этих элементов бэклога основываясь на глаз или основываясь на метрики скорость команды. Как правило, Scrum-командой используется такой очень удобный инструмент, который является лучшей практикой дополняющий Scrum, которая называется Scrum-доска. В буквальном смысле это физическая доска висящая на стене, на которой размещаются стикеры. Эта доска состоит из трех колонок, такая таблица, еще не начато, в работе и готово. Соответственно, наши элементы, которые команда отобрала для планирования размещаются в первой колонке, которая называется не начато. Затем происходит декомпозиция этих элементов на задачи. Scrum-мастер берет первый элемент на доске, зачитывает его и задает команде разработки вопрос: "что необходимо сделать, чтобы переместить этот элемент бэклога в готово?" Команда начинает разбивать его на задачи, например, нужно разработать макет экрана мобильного приложения, где у нас будет возможность указать адрес отправления и пункты назначения текстом и с кнопкой заказать. Нам нужно разработать базу данных для хранения данных пользователей и заказов, нужно реализовать серверную часть, которая будет связывать воедино разных клиентов, мобильные приложение. Необходимо наконец реализовать мобильное приложение для IOS, а точнее экран заказа в мобильном приложении для IOS. Точно также нужно реализовать этот экран в приложении для android. Все эти задачи тоже размещаются на доске на стикерах других цветов. Важно, чтобы задачи и элементы бэклога отличались, например, цветом стикеров. Как только команда закончила декомпозицию работ, то есть расписала все задачи поэтому элементы бэклога, Scrum-мастер может задать уточняющий вопрос: "а нужно ли сделать что то еще, чтобы переместить этот элемент бэклога в готово, то есть, чтобы мы могли поставить эту функцию нашим пользователям в обновлении продукта, которое будет произведено в конце спринта или в инкременте продукта, как это называется в Scrum-е". Команда может вспомните что-то еще, что необходимо сделать, например, мы должны опубликовать новость о том, что мы сделали эту новую функцию на нашем сайте и добавить эту задачу на доску. И так продолжается до тех пор, пока команда не ответит на этот вопрос отрицательно, то есть скажет, что нет, это все, что нужно сделать, чтобы доставить эту функцию нашим пользователям. После этого мы переходим к следующему элементу бэклога и так до тех пор, пока все элементы бэклога выбранные для реализации в этом спринте не будут декомпозированы на задачи. Важный момент, на планирование спринта, ни задачам, ни элементам бэклога не назначаются и не выбираются ответственные из команды разработки. Почему? Потому что это препятствует коллаборации, то есть взаимодействию разработчиков в течение спринта и поиску оптимальных решений по реализации той или иной задачи. То, что получилось у команды, то есть выбранные элементы бэклога, что мы сделаем в этом спринте и задачи, то есть план, как мы именно это сделаем, называется бэклогом спринта и владеет бэклогом спринта команда разработки. То есть, это означает, что никто, кроме самой команды разработки не может вносить изменения в этот бэклог, даже владелец продукта и кто бы то ни было другой, например, руководитель компании, в которой работает Scrum-команда не может просто прийти к команде в середине спринта и как бы впихнуть другую работу. Это важно, потому что, только таким образом можно достичь максимальной эффективности и производительности команды разработки в спринте. Вы спросите, а что если, например, у нас обнаружен баг в середине спринта, имеется в виду в приложении, которым уже пользуются пользователи, то есть баг на продакшене. Конечно же команда разработки обязана в этом случае отреагировать и исправить этот баг, поэтому хорошей практикой является не исчерпывать на планировании полностью всю скорость команды, а оставлять небольшой задел на такие непредвиденные обстоятельства и баги, где-то 10-20%. В общем, это зависит от вашей команды. Качественно проведенное планирование спринта позволяет команде разработки в течение спринта полностью сосредоточиться на работе и достичь своей максимальной производительности. Таким образом, результатом планирования спринта, является цель спринта и бэклог спринта, состоящий из выбранных для реализации элементов бэклога и плана по их реализации, то есть задач. В следующем видео мы подробнее рассматриваем роль команды разработки и Scrum-мастера. Scrum-команда должна работать физически в одном помещении, то есть сидеть прямо в одной комнате и работать плечом к плечу, тогда это дает наилучший результат по производительности. Но бывает так в реальности, что команда разработки разделена и, например, работает из разных городов. Поэтому в следующем видео мы рассмотрим электронные инструменты, альтернативы физическим доскам и стикерам, поймем в чем их преимущества и недостатки.
