В начале пути, прежде чем обсуждать задачи и присваивать их себе, члены команды принимают решение, какой продолжительности будут спринты в течение всего проекта. Изначально выбранная командой длительность спринтов на протяжении всего проекта остается неизменной. В расчете учитывается не только то, сможет ли команда в определенный период выдать минимально жизнеспособный продукт, но и то, насколько часто Заказчик, потребители и подрядчики смогут участвовать в демонстрации результата в конце спринта.
На практике проверено, что спринт не должен быть больше, чем четыре недели, так как в противном случае он превратится в обычную процессную деятельность. То есть исчезнет скорость и напряжение, а следом и мотивация. В нашей консультационной работе оптимальными стали две недели спринта. Как только заканчивается один спринт, сразу же создается следующий.
В исключительном случае, а такой может произойти в любом проекте, Владелец продукта может отменить или перенести спринт из соображений целесообразности.
В Agile вне IT-отрасли этот документ может использоваться факультативно, но не обязательно. Мне не приходилось встречать этот документ в своей консалтинговой работе. В этой диаграмме отражается динамика работы команды в течение спринта, чтобы сориентировать участников, какой объем работы уже сделан, что остается до окончания спринта и успевает ли команда создать минимально готовый продукт.
Теперь наступил момент планирования спринта: команда обсуждает, что ей необходимо взять из бэклога продукта, чтобы создать промежуточный продукт и представить его заинтересованным сторонам, то есть создается цель спринта. Для того чтобы каждый человек четко знал, какой объем работы будет выполнять, он выбирает из бэклога продукта необходимые опции и присваивает им свое имя.
Каждый день в одно и то же время, изначально выбранное командой, около SCRUM-доски проходит стендап (в методологии SWAY, о которой я буду говорить позднее, это мероприятие называется «дейли», но его суть от этого не меняется) – 15-минутная встреча всех без исключения членов команды для синхронизации действий. В этом моменте важно напомнить, что у доски говорит каждый член команды, никто не молчит и не отвечает уклончиво. На стендапе обсуждается три вопроса: что было сделано вчера, что делается сегодня и что планируется делать завтра. Все более серьезные разговоры и обсуждения SCRUM-мастер выносит за рамки стендапа.
Мне приходилось встречать мнение о том, что методология SCRUM настолько жесткая, что люди долго не выдерживают работать в таком ритме, поэтому длительность жизни команды не превышает трех месяцев. Однако в своей консалтинговой практике я не встречала такого ограничения. Напротив, появляется потребность в таких встречах и сверке деятельности и настроений, эти встречи становятся своеобразным тимбилдингом для всех участников. Это как раз о том, что, прежде чем внедрять методологию SCRUM, необходимо осознать и принять ценности и принципы Манифеста Agile. Остальное – дело техники.
И тогда понятно, что стендап – это не отчет, а сонастройка действий команды. И все, что происходит внутри команды, делается на основе доверия и эмпатии. Иначе у методологии нет души. И тогда это действительно не Agile, а муштра.
Как раз на этом мероприятии происходит встреча Заказчика и потребителей с командой проекта. Это демонстрация того, что было сделано за спринт, тестирование минимально жизнеспособного продукта всеми заинтересованными сторонами и определение его сильных и слабых сторон. Желательно, чтобы итогом обзора стала возможность реализации сделанного продукта, чтобы команда ощутила, что она в скором времени уже способна создавать прибыль для бизнеса. Но это, конечно, идеальный вариант, к которому надо стремиться.
Если мы вернемся к образу слона, то в момент обзора спринта мы созываем гостей, чтобы они попробовали, хорошо ли приготовлен наш кусочек, и высказали свои замечания, которые будут учтены в следующем спринте.
После обзора и принятия всех возможных замечаний, команда намечает следующий спринт, корректируя задачи и формируя новый минимально готовый продукт.
Это один из элементов самоуправляемости команды. Ретроспективы проводятся один раз в полтора-два месяца. Их цель заключается в том, чтобы обсудить все вопросы, поделиться мнениями, определить, что из прошлого периода можно взять в будущий. Для обсуждения в ретроспективе выделяются четыре основные области: что было хорошо в прошедшем спринте, минусы этого же периода, идеи, которые возникали в промежутке между спринтами, но не были припаркованы в работе над проектом, и как итог – план изменений или дальнейших действий. Возможно, достигаются новые договоренности, если прежние уже изжили себя.
Фасилитирует ретроспективу SCRUM-мастер. Его задача направлять дискуссию и следить за тем, чтобы высказывались как можно больше участников.
