Close

Scrum

Узнайте о методологии Scrum от экспертов

Просмотр тем

Что такое Scrum?

Scrum — это методология, помогающая командам вести совместную работу. Как спортивная команда готовится к решающей игре (к слову, scrum — англ. «схватка», элемент игры в регби), так и команда сотрудников компании должна извлекать уроки из полученного опыта, осваивать принципы самоорганизации, работая над решением проблемы, и анализировать свои успехи и провалы, чтобы постоянно совершенствоваться. Scrum содействует этому.

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

В этой статье мы рассмотрим, из чего состоит традиционная платформа Scrum. В этом нам помогут руководство по Scrum и Дэвид Уэст, генеральный директор компании Scrum.org. Мы также рассмотрим на примерах, как наши клиенты отходят от базовых принципов ради достижения своих уникальных целей. Для этого специалист нашей компании, менеджер группы продуктов Jira Software и бывший тренер по agile Меган Кук поделится советами и рекомендациями в рамках серии видеороликов «Тренер по agile»:

Статьи по теме Scrum

[ПРОДОЛЖЕНИЕ]

Платформа

Понятия Scrum и agile часто путают, потому что Scrum строится вокруг идеи о постоянном совершенствовании, которое является главным принципом agile. И все же Scrum — это методология работы, а agile — это образ мышления. Перейти на agile не так-то просто; вся команда должна стремиться изменить свой подход к созданию ценности для клиентов. Но можно просто начать использовать методологию, такую как Scrum. Это направит мышление в нужное русло и поможет практиковать принципы agile в повседневном общении и работе.

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

Методология Scrum | Atlassian — тренер по agile

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

Артефакты Scrum

Сначала определим три артефакта Scrum. Артефакт — это то, что мы создаем, например инструмент для решения проблемы. В Scrum существует три артефакта: бэклог продукта, бэклог спринта и инкремент с вашими критериями готовности. Эти три постоянные присутствуют в каждой команде Scrum, мы постоянно к ним обращаемся и уделяем им время.

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

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

Профессиональный совет

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

Собрания или мероприятия Scrum

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

 

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

  1. Организация бэклога. За это мероприятие, также известное как ведение бэклога, несет ответственность владелец продукта. В число его основных обязанностей входят приведение продукта в соответствие с его концепцией и постоянное отслеживание настроений на рынке и потребностей клиента. Для этого владелец продукта и ведет этот список, изменяя в нем приоритеты и поддерживая его в актуальном виде на основании информации от пользователей и команды разработчиков, чтобы в любое время можно было приступить к работе над внесенными в него задачами. Подробнее о том, как правильно вести бэклог, можно прочитать здесь.

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

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

  3. Спринт. Спринт — это фактический промежуток времени, в течение которого команда Scrum совместно работает над созданием готового инкремента. Как правило, спринт длится две недели, хотя некоторым командам проще спланировать объем спринта на одну неделю или поставить инкремент, обладающий достаточной ценностью, за месяц. Дейв Уэст из Scrum.org рекомендует выбирать спринт тем короче, чем сложнее работа и чем больше в ней неизвестных. Но последнее слово всегда за командой, и вам не стоит бояться менять продолжительность спринта, если покажется, что она вам не подходит. В течение этого периода владелец продукта и команда разработчиков могут пересмотреть объем спринта, если это необходимо. Это и есть ключ к пониманию эмпирической сути Scrum.

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

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

    Стендап — самое время сообщить обо всем, что мешает вам достичь цели спринта, в том числе о блокерах.

    Чаще всего в рамках стендапа каждому участнику команды предлагается ответить на следующие три вопроса, связанные с достижением цели спринта:

    •      «Что мне удалось сделать вчера?»
    •      «Что я планирую сделать сегодня?»
    •      «Может ли мне что-то помешать?»

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

  5. Обзор итогов спринта. В конце спринта команда собирается для просмотра демонстрации инкремента (или для его изучения) в неформальной обстановке. Команда разработчиков представляет рабочие задачи из бэклога, которые на тот момент считаются завершенными, на суд заинтересованных лиц и коллег. Владелец продукта решает, стоит ли выпускать инкремент или нет, хотя в большинстве случаев инкремент выпускается.

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

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

Три важнейшие роли, от которых зависит успех применения Scrum

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

Владелец продукта Scrum

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

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

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

Scrum-мастер

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

Успех scrum-мастера зависит от того, насколько хорошо он разбирается в работе, которую выполняет команда, и может помочь команде повысить прозрачность работы и оптимизировать процесс поставки продукта. Это главный координатор, который составляет перечень требуемых ресурсов (кадровых и материально-технических) для собраний по планированию спринта и обзору его итогов, стендапа и ретроспективы спринта.

Команда разработчиков Scrum

На команды Scrum ложится вся основная работа. Они специалисты по принципам сбалансированной разработки. Самые успешные команды сплочены, находятся в одном месте и обычно состоят из 5–7 участников. Чтобы определить размер команды, можно обратиться к известному «правилу двух пицц», которое сформулировал глава Amazon Джефф Безос (в команде должно быть столько участников, чтобы им хватало двух пицц).

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

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

Scrum, Kanban и agile

Scrum — настолько популярная agile-методология, что слова Scrum и agile многие ошибочно используют как синонимы. Но есть и другие методологии, например Kanban, которая тоже пользуется популярностью. Некоторые компании даже предпочитают гибридную модель, сочетающую в себе элементы Scrum и Kanban. Ее называют Scrumban или Kanplan — по сути, Kanban с бэклогом.

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

Scrum строится вокруг небольших итераций с фиксированной продолжительностью. Сначала нужно определить продолжительность спринта, после чего выбрать пользовательские истории или элементы бэклога продукта, которые нужно реализовать в течение этого цикла спринта. В Kanban же количество заданий (или объем невыполненной работы — лимит WIP), которые нужно выполнить в текущем цикле, фиксировано изначально. Затем ведется обратный отсчет времени, которое уйдет на реализацию этих возможностей.

Методология Kanban не так структурирована, как Scrum. В ней есть лимит WIP, но все остальные понятия в той или иной мере допускают вольную трактовку. В Scrum же присутствует несколько строго определенных понятий, обязательность которых проистекает из самого применения платформы: обзор итогов спринта, ретроспектива, ежедневное scrum-совещание и т. д. Scrum также требует формирования многофункциональной команды, чтобы успех достижения цели не зависел от сторонних участников. Собрать многофункциональную команду — задача не из легких. В этом плане Kanban проще адаптировать, а применение Scrum влечет за собой коренное изменение образа мышления и характера работы команды разработчиков.

За что мы любим Scrum?

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

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

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


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

 

Claire Drumond
Claire Drumond

Клэр Драмонд работает в Atlassian как специалист по маркетинговым стратегиям, докладчик и писатель. Она создала множество статей для блогов Trello и Atlassian. Материалы, подготовленные с ее участием, регулярно публикуются на Medium, в том числе в категориях HackerNoon, Art+Marketing и PoetsUnlimited. Клэр выступает на технических конференциях по всему миру, рассказывая о методиках agile, преодолении разрозненности и развитии эмпатии.

продолжение темы
Sprints