Scrum

логотип ыскгь

Что такое Scrum?

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

Хотя Scrum, о котором я говорю, чаще всего используется командами разработчиков программного обеспечения, его принципы и уроки могут быть применены ко всем видам командной работы. Это одна из причин популярности Scrum. Часто рассматриваемый как система управления проектами, Scrum описывает набор собраний, инструментов и ролей, которые работают согласованно, чтобы помочь командам структурировать и управлять своей работой.

Структура

Люди часто думают, что Scrum и Agile - это одно и то же, потому что Scrum сосредоточен на постоянном совершенствовании, что является основным принципом Agile. Однако scrum - это структура для выполнения работы, в то время как Agile - это образ мышления. Вы не можете действительно «перейти на Agile», поскольку для этого требуется самоотверженность всей команды, чтобы изменить образ мышления в отношении предоставления ценности вашим клиентам. Но вы можете использовать такую структуру, как Scrum, чтобы помочь вам начать думать в этом направлении и практиковать внедрение принципов Agile в ваше повседневное общение и работу.

Система Scrum является эвристической; она основана на непрерывном обучении и адаптации к изменяющимся факторам. Она признает, что команда не знает всего на начальном этапе проекта и будет развиваться в процессе опыта. Scrum структурирован таким образом, чтобы помочь команде естественным образом адаптироваться к изменяющимся условиям и требованиям пользователей, при этом в процесс встроено изменение приоритетов и короткие циклы выпуска, чтобы ваша команда могла постоянно учиться и совершенствоваться.

Артефакты скрама

Давайте начнем с определения трех артефактов в скраме. Артефакты - это то, что мы создаем, например, инструмент для решения проблемы. В Scrum эти три артефакта - это бэклог продукта, бэклог спринта и инкремент с вашим определением «сделано». Это три константы в скрам-команде, которые мы продолжаем пересматривать и инвестировать в них.

Бэклог продукта - это основной список работ, которые необходимо выполнить, который ведет владелец продукта или менеджер продукта. Это динамический список функций, требований, улучшений и исправлений, который служит исходным материалом для бэклога спринта. По сути, это список «дел» команды. Бэклог продукта постоянно пересматривается, изменяется в приоритетах и поддерживается владельцем продукта, потому что по мере того, как мы узнаем больше или меняется рынок, элементы могут потерять актуальность или проблемы могут быть решены другими способами.
Бэклог спринта - это список элементов, пользовательских историй или исправлений ошибок, выбранных командой разработчиков для реализации в текущем цикле спринта. Перед каждым спринтом на собрании по планированию спринта (о котором мы поговорим далее в статье) команда выбирает из бэклога продукта те элементы, над которыми она будет работать в течение спринта. Бэклог спринта может быть гибким и меняться в течение спринта. Однако основная цель спринта - то, чего команда хочет достичь в текущем спринте, - не может быть нарушена.
Инкремент (или цель спринта) - это пригодный для использования конечный продукт спринта. В Atlassian мы обычно демонстрируем «инкремент» во время демонстрации конца спринта, когда команда показывает, что было завершено в спринте. Вы можете не слышать слово «инкремент» в мире, поскольку часто под ним понимается определение команды «готово», веха, цель спринта, или даже полная версия или отгруженный эпик. Все зависит от того, как ваша команда определяет «готово» и как вы определяете цели спринта. Например, некоторые команды предпочитают выпускать что-то для своих клиентов в конце каждого спринта. Таким образом, их определение «сделано» будет «отправлено» . Однако это может быть нереально для других типов команд. Скажем, вы работаете над серверным продуктом, который может поставляться клиентам только раз в квартал. Вы можете по-прежнему работать в 2-недельных спринтах, но ваше определение «готово» может означать завершение работы над частью более крупной версии, которую вы планируете отправить вместе. Но, конечно, чем больше времени требуется для выпуска программного обеспечения, тем выше риск, что оно не будет соответствовать требованиям.

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

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

Распорядок или события скрама

Одними из наиболее известных компонентов концепции Scrum являются набор последовательных событий, церемоний или встреч, которые команды Scrum проводят на регулярной основе. Распорядок - это то, в чем мы видим наибольшие различия между командами. Например, некоторые команды считают выполнение всех этих церемоний обременительным и повторяющимся, в то время как другие используют их в качестве необходимой проверки. Мы советуем начать использовать все церемонии в течение двух спринтов и посмотреть, как это будет выглядеть. Затем вы можете провести быструю ретроспективу и посмотреть, где вам, возможно, нужно внести коррективы.

Ниже приведен список всех ключевых распорядков, в которых может принимать участие скрам-команда.

Организовать бэклог. Это мероприятие, иногда известное как "приведение в порядок бэклога", входит в обязанности владельца продукта. Основная работа владельца продукта заключается в том, чтобы продвигать продукт к его видению и постоянно следить за рынком и клиентами. Поэтому он/она поддерживает этот список, используя обратную связь от пользователей и команды разработчиков, чтобы помочь расставить приоритеты и сохранить список чистым и готовым к работе в любой момент времени. Подробнее о поддержании здорового бэклога вы можете прочитать здесь.
Планирование спринта. На этом собрании вся команда разработчиков планирует работу, которую необходимо выполнить (объем) в течение текущего спринта. Это собрание ведет скрам-мастер, и на нем команда принимает решение о цели спринта. Затем в спринт добавляются конкретные истории использования из бэклога продукта. Эти истории всегда согласуются с целью, а также согласовываются с командой скрам, чтобы их можно было реализовать в течение спринта.

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

Спринт. Спринт - это фактический период времени, когда скрам-команда работает вместе над завершением инкремента. Две недели - это довольно типичная продолжительность спринта, хотя некоторые команды считают, что неделя - это более простой срок для определения масштаба или месяц - это более простой срок для создания ценного инкремента. Дэйв Вест (Dave West) из Scrum.org советует, что чем сложнее работа и чем больше неизвестных, тем короче должен быть спринт. Но это действительно зависит от вашей команды, и вы не должны бояться изменить его, если он не работает! В течение этого периода, при необходимости, рамки могут быть пересмотрены между владельцем продукта и командой разработчиков. Это составляет суть эмпирической природы Scrum.

Все события - от планирования до ретроспективы - происходят в течение спринта. После установления определенного временного интервала для спринта он должен оставаться неизменным на протяжении всего периода разработки. Это помогает команде извлекать уроки из прошлого опыта и применять их в будущих спринтах.

Ежедневный скрам или стенд-ап. Это ежедневное суперкороткое совещание, которое проводится в одно и то же время (обычно по утрам) и в одном и том же месте, чтобы все было просто. Многие команды стараются провести собрание за 15 минут, но это лишь ориентир. Это собрание также называют «ежедневным стенд-апом», подчеркивая, что оно должно быть быстрым. Цель ежедневного Scrum - чтобы все члены команды были на одной волне, были согласны с целью спринта, и чтобы у них был план на следующие 24 часа.

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

Обзор спринта. В конце спринта команда собирается на неформальную сессию, чтобы посмотреть демонстрацию или проинспектировать инкремент. Команда разработчиков демонстрирует элементы бэклога, которые теперь "выполнены", заинтересованным сторонам и членам команды для получения обратной связи. Владелец продукта может решить, выпускать или не выпускать инкремент, хотя в большинстве случаев инкремент выпускается.
Ретроспектива спринта. Ретроспектива - это место, где команда собирается вместе, чтобы задокументировать и обсудить, что получилось, а что не получилось в спринте, проекте, людях или отношениях, инструментах или даже в определенных церемониях. Идея заключается в том, чтобы создать место, где команда может сосредоточиться на том, что прошло хорошо и что нужно улучшить в следующий раз, и меньше думать о том, что пошло не так.

Но почему именно scrum?

Сама система Scrum проста. Правила, артефакты, события и роли легко понять. Его полупредписывающий подход фактически помогает устранить двусмысленность в процессе разработки, оставляя при этом достаточно пространства для того, чтобы компании могли привнести в него свою индивидуальную изюминку.

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

Однако для полного понимания Scrum может потребоваться время, особенно если команда разработчиков привыкла к типичной водопадной модели. Концепции более мелких итераций, ежедневных собраний Scrum, обзоров спринтов и определения Scrum-мастера могут стать сложным культурным сдвигом для новой команды.

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

По материалам статьи Клэр Друмонд (Claire Drumond) atlassian.com/agile/scrum