Временной отрезок, когда команда создает часть продукта, которую можно продемонстрировать заказчику, называется, спринт. Когда он завершается, ответственная команда рассказывает, что было сделано и с какими проблемами/вопросами она столкнулась.

Это короткие ежедневные совещания/встречи. Длятся не больше 15 минут. Проходят утром, либо днем, если есть разница во времени между офисами. Цель стендапов — информировать участников команды о ходе работы над задачами спринта.

Она же ретроспектива. Проводится в последний день спринта. Длится от 60 минут до двух часов. На ретроспективе нужно оценить, хорошо команда справляется или нет. Если есть трудности, то их разбирают подробно.

Метод Scrum — это технология гибкого управления проектами. На первое место здесь выходит команда профессионалов, люди в ней по–настоящему кайфуют от своей работы. Чем они счастливее, тем выше их продуктивность — примерно на 50%. Еще они более лояльны (на 88% больше по сравнению с «несчастными» сотрудниками) и готовы отдавать часть своей жизни для создания классного продукта.

Чтобы добиться максимальной вовлеченности сотрудников, открытости и доверия внутри команд, Скрам использует определенные церемонии. И здесь велико искушение взять несколько из них и внедрить в любой метод управления, например, в waterfall. Все, мы гибкие и успешные (на самом деле нет).

Все церемонии в Scrum взаимосвязаны и зачем–то нужны, кроме того, за всеми ними стоит мощный бэкграунд в виде философии Agile. В этом тексте мы разберемся, что означают церемонии скрам, и как они влияют на компанию в целом.

В Scrum работу над проектом разделяют на части. На каждую из них выделяют отрезок времени. Когда он завершается, ответственная команда рассказывает, что было сделано и с какими проблемами/вопросами она столкнулась.

Временной отрезок, когда команда создает часть продукта, которую можно продемонстрировать заказчику, называется, спринт.

Обязательно фиксируется общая цель спринта, ее нужно достичь в конце.

Перед началом работы, команда обсуждает продолжительность спринта. При работе над следующим продуктом он может меняться, но тоже только после обсуждения и обоснований.

Как правило, спринт длится от одной до четырех недель. В Apple спринт длится 3 недели. Но бывают и исключения. Так в Nokia спринт длился аж 6 месяцев (хотя, стоит задуматься, где сейчас Нокиа, а где Эпл).

Чем срок спринта короче, тем более гибким становится процесс разработки. Команда быстрее получает обратную связь, может внести изменения, что–то исправить или улучшить. Идеальный спринт длится 1-2 недели.

Планирование спринта. За время этой встречи нужно определить цель спринта. Выбрать задачи из бэклога (Backlog) для исполнения.

В Бэклог попадают пожелания и требования заказчика к функционалу и дизайну продукта. Но их не просто записывают подряд, а расставляют по степени важности и ценности для клиента.

Это короткие ежедневные совещания/встречи. Длятся не больше 15 минут. Проходят утром, либо днем, если есть разница во времени между офисами. Но всегда в одно и то же время.

Цель стендапов — информировать участников команды о ходе работы над задачами спринта.

Каждый должен ответить на 3 вопроса:

• Что делал вчера?
• Что буду делать сегодня?
• Какие есть проблемы в работе над проектом? Что делаю, чтобы устранить их?

Стендапы должны проходить динамично. Где–то в команду бросают мяч, у кого он в руках, тот и говорит. Где–то включают таймер. В пандемию, когда многие перешли на удаленку, стендапы проводят в формате видеоконференции.

Проходит в конце спринта. В нем участвует команда проекта, Scrum–мастер, владелец продукта или руководитель проекта, а также заказчики продукта или заинтересованные в нем лица, ответственные за принятие решений (стэкхолдеры).

Спринт–митинг длится от 30 минут до двух часов. На нем команда рассказывает, что было сделано, и демонстрирует те части проекта, которые окончательно готовы.

На спринт ревью происходит синхронизация команды и заказчика. Разработчики получают обратную связь по продукту, понимают, в том ли направлении они двигаются.

Как проходит Sprint Review Meeting:

• Заказчику рассказывают, какие задачи из бэклога были сделаны. Что завершить не успели (или успели все).
• Команда демонстрирует свою работу и отвечает на вопросы о продукте.
• На этом этапе обсуждают, какие задачи из бэклога будет сделаны в следующем спринте. Оговаривают сроки, бюджет и прочие моменты.

У команды проекта задача ответить на два вопроса:

• Что мы можем сделать лучше в следующем спринте?
• С какими проблемами столкнулись в этом?

Ответы фиксируются. Ведь они помогут команде стать эффективнее в следующем «забеге», помогут улучшить проблемные места.

У спринт ревью может быть и другой итог. Например, заказчик понимает, что разработку продукта стоит остановить, так как ситуация изменилась и в нем больше нет экономической целесообразности.

Либо решают ускорить разработку. Тогда нужно продумать, как расширить действующую команду или сформировать дополнительные команды разработки ей в помощь.

Если же на ревью становится заметно, что команда не справляется с задачами, то принимают решение об ее переформатировании, замене участников.

Чего НЕ должно быть на Sprint Review Meeting:

• Владелец продукта представляет проект заказчику от своего лица, а не от команды. Не учитывает мнения ее участников. Это решается обучением специалиста и должно на корню пресекаться скрам–мастером.
• Неправильно, если Product owner сам принимает работу без участия заказчика. Или если он не прислушивается к обратной связи заказчика и не использует ее в дальнейшей работе на продуктом.
• Скука и безучастность участников команды. Спринт ревью должно быть полезным и интересным, а не навязанным. Скрам–мастеру нужно продумывать организацию, техники проведения и вовлечение всей команды.
• На ревью выносят незавершенные задачи. Это возможно, но лишь в редких случаях и всегда обсуждается с заказчиком.
• Заказчики принимают/не принимают функции продукта в рамках ревью. Тут нужно помнить, что это не цель Sprint Review Meeting.
• Заказчик или стэкхолдеры не приходят на спринт ревью. Чтобы этого не происходило, скрам–мастеру нужно «продать» это мероприятие. Сделать его интересным и важным для обеих сторон.
• На ревью перечисляют все, что было сделано в деталях. Лучше кратко, емко и по делу.

Он же ретроспектива. Проводится в последний день спринта. Длится от 60 минут до двух часов (например, для двухнедельного спринта). Участвуют: команда проекта, Scrum–мастер, владелец продукта или руководитель проекта.

На ретроспективе нужно оценить, хорошо команда справляется или нет. Если есть трудности, то их разбирают подробно. Затем находят решения и выписывают план действий. Ведь постоянные улучшения — важная часть философии Agile.

Смотрят на те моменты, которые дали хороший результат, то, что отлично работает. Ведь ретроспектива не только для жалоб. Это нужно, чтобы команда сосредотачивалась на сильных сторонах, а не закапывалась в проблемах.

Полезные практики ретроспективы:

• Позитивное мышление всех участников. Не фокусироваться на плохом. Что было хорошо, но мешало? Как это устранить в будущем.
• Предложить всем участникам написать тезисы с их мнением о том, что в спринте было отлично, где возникали препятствия, их идеи по улучшению и следующему спринту.
• Из идей участников голосованием составить план улучшений. Выделить, что войдет в следующий спринт.
• Если идеи изменений крутые, но слишком сложные и длинные по реализации, их можно включить в список задач, разложить на этапы и следить за прогрессом.
• Учитывать работу над улучшениями при обсуждениях с заказчиками. Особенно это касается темы технического долга. Когда жертвуют проработкой кода ради быстрого решения, создают «костыли». Но потом забывают вернуться к ним и закрыть технический долг.

Главный принцип методологии Agile — отсутствие явного лидера или начальника в команде. Все общаются друг с другом неформально. Но контролировать работу над проектом, мотивировать и направлять сотрудников как–то нужно. Для этого в Scrum существуют роли.

• Владелец продукта или Product owner. Это не заказчик, но человек из команды, который выполняет его роль. То есть он отвечает за видение продукта заказчиком. Принимает решения об изменениях. Связывает команду и заказчика. Здорово, если Product owner видит реализацию проекта на 2-3 спринта вперед.
• Скрам–мастер. Этот человек контролирует весь процесс работы над проектом. Он организует спринты, стендапы и митинги. Следит за порядком на доске, чтобы никто не завис на какой–то задаче. Выявляет проблемы и узкие места в процессе работы. Устраняет их. И в итоге доводит продукт до выпуска.
• Команда разработки. Это 7-9 человек, которые непосредственно работают над продуктом. В этой команде могут быть продажники, программисты и дизайнеры, копирайтеры и аналитики, бухгалтеры и маркетологи. Это не хаотичный набор сотрудников, а только те, кто реально нужен проекту. Участники команды мотивируют друг друга, подтягивают, если нужно. Здорово, если в команде царит дружеская конкуренция.

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

• Довольные и мотивированные сотрудники. Этому способствует работа в команде, неформальное общение, возможность высказываться и предлагать. Люди занимаются любимым делом.
• Отсутствие ненужной бюрократии и документации. На первое время ставим человека, а не бумажки. Например, Apple работает по скрам. В компании сильно заморачиваются над продуктами, и выпустить новый гаджет куда важнее, чем крутую инструкцию по его использованию. Ее можно доделать и после презентации.
• Заказчик получит продукт, который купят. Потому что постоянно есть обратная связь и та самая гибкость в работе.
• Скрам можно использовать даже в небольших стартапах.

• Сложно собрать команду профессионалов. Да еще так, чтобы им было комфортно работать и общаться друг с другом.
• Людей нужно обучить работе со скрам.
• Сложно избежать ошибок в планировании. Особенно на старте. Времени на задачи закладывают то слишком много, то слишком мало.
• Жесткое следование церемониям. Проект разбивается на части, которые делают в несколько спринтов. Со всеми митингами, ревью и ретроспективами. И это действительно важно, если компания хочет получить готовый идеальный продукт.