Sprint (v2)
Временной отрезок, когда команда создает часть продукта, которую можно продемонстрировать заказчику, называется, спринт. Когда он завершается, ответственная команда рассказывает, что было сделано и с какими проблемами/вопросами она столкнулась.
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
- Сложно собрать команду профессионалов. Да еще так, чтобы им было комфортно работать и общаться друг с другом.
- Людей нужно обучить работе со скрам.
- Сложно избежать ошибок в планировании. Особенно на старте. Времени на задачи закладывают то слишком много, то слишком мало.
- Жесткое следование церемониям. Проект разбивается на части, которые делают в несколько спринтов. Со всеми митингами, ревью и ретроспективами. И это действительно важно, если компания хочет получить готовый идеальный продукт.