Stand up
Это короткие ежедневные совещания/встречи. Длятся не больше 15 минут. Проходят утром, либо днем, если есть разница во времени между офисами. Цель стендапов — информировать участников команды о ходе работы над задачами спринта.
Sprint Retrospective Meeting
Она же ретроспектива. Проводится в последний день спринта. Длится от 60 минут до двух часов. На ретроспективе нужно оценить, хорошо команда справляется или нет. Если есть трудности, то их разбирают подробно.
Церемонии Scrum
Метод Scrum — это технология гибкого управления проектами. На первое место здесь выходит команда профессионалов, люди в ней по–настоящему кайфуют от своей работы. Чем они счастливее, тем выше их продуктивность — примерно на 50%. Еще они более лояльны (на 88% больше по сравнению с «несчастными» сотрудниками) и готовы отдавать часть своей жизни для создания классного продукта.
Чтобы добиться максимальной вовлеченности сотрудников, открытости и доверия внутри команд, Скрам использует определенные церемонии. И здесь велико искушение взять несколько из них и внедрить в любой метод управления, например, в waterfall. Все, мы гибкие и успешные (на самом деле нет).
Все церемонии в Scrum взаимосвязаны и зачем–то нужны, кроме того, за всеми ними стоит мощный бэкграунд в виде философии Agile. В этом тексте мы разберемся, что означают церемонии скрам, и как они влияют на компанию в целом.
Sprint
В Scrum работу над проектом разделяют на части. На каждую из них выделяют отрезок времени. Когда он завершается, ответственная команда рассказывает, что было сделано и с какими проблемами/вопросами она столкнулась.
Временной отрезок, когда команда создает часть продукта, которую можно продемонстрировать заказчику, называется, спринт.
Обязательно фиксируется общая цель спринта, ее нужно достичь в конце.
Перед началом работы, команда обсуждает продолжительность спринта. При работе над следующим продуктом он может меняться, но тоже только после обсуждения и обоснований.
Как правило, спринт длится от одной до четырех недель. В Apple спринт длится 3 недели. Но бывают и исключения. Так в Nokia спринт длился аж 6 месяцев (хотя, стоит задуматься, где сейчас Нокиа, а где Эпл).
Чем срок спринта короче, тем более гибким становится процесс разработки. Команда быстрее получает обратную связь, может внести изменения, что–то исправить или улучшить. Идеальный спринт длится 1-2 недели.
Sprint Planning Meeting
Планирование спринта. За время этой встречи нужно определить цель спринта. Выбрать задачи из бэклога (Backlog) для исполнения.
В Бэклог попадают пожелания и требования заказчика к функционалу и дизайну продукта. Но их не просто записывают подряд, а расставляют по степени важности и ценности для клиента.
Stand Up (v2)
Это короткие ежедневные совещания/встречи. Длятся не больше 15 минут. Проходят утром, либо днем, если есть разница во времени между офисами. Но всегда в одно и то же время.
Цель стендапов — информировать участников команды о ходе работы над задачами спринта.
Каждый должен ответить на 3 вопроса:
Что делал вчера?
Что буду делать сегодня?
Какие есть проблемы в работе над проектом? Что делаю, чтобы устранить их?
Стендапы должны проходить динамично. Где–то в команду бросают мяч, у кого он в руках, тот и говорит. Где–то включают таймер. В пандемию, когда многие перешли на удаленку, стендапы проводят в формате видеоконференции.
Sprint Review Meeting
Проходит в конце спринта. В нем участвует команда проекта, Scrum–мастер, владелец продукта или руководитель проекта, а также заказчики продукта или заинтересованные в нем лица, ответственные за принятие решений (стэкхолдеры).
Спринт–митинг длится от 30 минут до двух часов. На нем команда рассказывает, что было сделано, и демонстрирует те части проекта, которые окончательно готовы.
На спринт ревью происходит синхронизация команды и заказчика. Разработчики получают обратную связь по продукту, понимают, в том ли направлении они двигаются.
Как проходит Sprint Review Meeting:
Заказчику рассказывают, какие задачи из бэклога были сделаны. Что завершить не успели (или успели все).
Команда демонстрирует свою работу и отвечает на вопросы о продукте.
На этом этапе обсуждают, какие задачи из бэклога будет сделаны в следующем спринте. Оговаривают сроки, бюджет и прочие моменты.
У команды проекта задача ответить на два вопроса:
Что мы можем сделать лучше в следующем спринте?
С какими проблемами столкнулись в этом?
Ответы фиксируются. Ведь они помогут команде стать эффективнее в следующем «забеге», помогут улучшить проблемные места.
У спринт ревью может быть и другой итог. Например, заказчик понимает, что разработку продукта стоит остановить, так как ситуация изменилась и в нем больше нет экономической целесообразности.
Либо решают ускорить разработку. Тогда нужно продумать, как расширить действующую команду или сформировать дополнительные команды разработки ей в помощь.
Если же на ревью становится заметно, что команда не справляется с задачами, то принимают решение об ее переформатировании, замене участников.
Чего НЕ должно быть на Sprint Review Meeting:
Владелец продукта представляет проект заказчику от своего лица, а не от команды. Не учитывает мнения ее участников. Это решается обучением специалиста и должно на корню пресекаться скрам–мастером.
Неправильно, если Product owner сам принимает работу без участия заказчика. Или если он не прислушивается к обратной связи заказчика и не использует ее в дальнейшей работе на продуктом.
Скука и безучастность участников команды. Спринт ревью должно быть полезным и интересным, а не навязанным. Скрам–мастеру нужно продумывать организацию, техники проведения и вовлечение всей команды.
На ревью выносят незавершенные задачи. Это возможно, но лишь в редких случаях и всегда обсуждается с заказчиком.
Заказчики принимают/не принимают функции продукта в рамках ревью. Тут нужно помнить, что это не цель Sprint Review Meeting.
Заказчик или стэкхолдеры не приходят на спринт ревью. Чтобы этого не происходило, скрам–мастеру нужно «продать» это мероприятие. Сделать его интересным и важным для обеих сторон.
На ревью перечисляют все, что было сделано в деталях. Лучше кратко, емко и по делу.
Sprint Retrospective Meeting (v2)
Он же ретроспектива. Проводится в последний день спринта. Длится от 60 минут до двух часов (например, для двухнедельного спринта). Участвуют: команда проекта, Scrum–мастер, владелец продукта или руководитель проекта.
На ретроспективе нужно оценить, хорошо команда справляется или нет. Если есть трудности, то их разбирают подробно. Затем находят решения и выписывают план действий. Ведь постоянные улучшения — важная часть философии Agile.
Смотрят на те моменты, которые дали хороший результат, то, что отлично работает. Ведь ретроспектива не только для жалоб. Это нужно, чтобы команда сосредотачивалась на сильных сторонах, а не закапывалась в проблемах.
Полезные практики ретроспективы:
Позитивное мышление всех участников. Не фокусироваться на плохом. Что было хорошо, но мешало? Как это устранить в будущем.
Предложить всем участникам написать тезисы с их мнением о том, что в спринте было отлично, где возникали препятствия, их идеи по улучшению и следующему спринту.
Из идей участников голосованием составить план улучшений. Выделить, что войдет в следующий спринт.
Если идеи изменений крутые, но слишком сложные и длинные по реализации, их можно включить в список задач, разложить на этапы и следить за прогрессом.
Учитывать работу над улучшениями при обсуждениях с заказчиками. Особенно это касается темы технического долга. Когда жертвуют проработкой кода ради быстрого решения, создают «костыли». Но потом забывают вернуться к ним и закрыть технический долг.
Роли в Скрам
Главный принцип методологии Agile — отсутствие явного лидера или начальника в команде. Все общаются друг с другом неформально. Но контролировать работу над проектом, мотивировать и направлять сотрудников как–то нужно. Для этого в Scrum существуют роли.
Владелец продукта или Product owner. Это не заказчик, но человек из команды, который выполняет его роль. То есть он отвечает за видение продукта заказчиком. Принимает решения об изменениях. Связывает команду и заказчика. Здорово, если Product owner видит реализацию проекта на 2-3 спринта вперед.
Скрам–мастер. Этот человек контролирует весь процесс работы над проектом. Он организует спринты, стендапы и митинги. Следит за порядком на доске, чтобы никто не завис на какой–то задаче. Выявляет проблемы и узкие места в процессе работы. Устраняет их. И в итоге доводит продукт до выпуска.
Команда разработки. Это 7-9 человек, которые непосредственно работают над продуктом. В этой команде могут быть продажники, программисты и дизайнеры, копирайтеры и аналитики, бухгалтеры и маркетологи. Это не хаотичный набор сотрудников, а только те, кто реально нужен проекту. Участники команды мотивируют друг друга, подтягивают, если нужно. Здорово, если в команде царит дружеская конкуренция.
Плюсы Scrum
Чтобы точно понять, нужно ли вашей компании переходить на скрам, важно разобраться с его плюсами и минусами. Начнем с преимуществ.
Довольные и мотивированные сотрудники. Этому способствует работа в команде, неформальное общение, возможность высказываться и предлагать. Люди занимаются любимым делом.
Отсутствие ненужной бюрократии и документации. На первое время ставим человека, а не бумажки. Например, Apple работает по скрам. В компании сильно заморачиваются над продуктами, и выпустить новый гаджет куда важнее, чем крутую инструкцию по его использованию. Ее можно доделать и после презентации.
Заказчик получит продукт, который купят. Потому что постоянно есть обратная связь и та самая гибкость в работе.
Скрам можно использовать даже в небольших стартапах.
Минусы Scrum
Сложно собрать команду профессионалов. Да еще так, чтобы им было комфортно работать и общаться друг с другом.
Людей нужно обучить работе со скрам.
Сложно избежать ошибок в планировании. Особенно на старте. Времени на задачи закладывают то слишком много, то слишком мало.
Жесткое следование церемониям. Проект разбивается на части, которые делают в несколько спринтов. Со всеми митингами, ревью и ретроспективами. И это действительно важно, если компания хочет получить готовый идеальный продукт.