Что такое Scrum и как это освоить

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

Различие между определениями Agile и Scrum можно найти в руководстве по Scrum и Манифесте Agile. В этом манифесте приведены четыре ценности.

• Люди и взаимодействие важнее процессов и инструментов.

• Работающий продукт важнее исчерпывающей документации.

• Сотрудничество с заказчиком важнее согласования условий контракта.

• Готовность к изменениям важнее следования плану.

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

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

Методика Scrum определяет набор ценностей, принципов и практик, которым следуют scrum-команды при создании продукта или предоставлении услуги. В ней подробно описываются обязанности и зоны ответственности членов scrum-команды, «артефакты», определяющие продукт и работу по его созданию, а также scrum-собрания, помогающие команде в работе.

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

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

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

• Они формируют бэклог продукта.

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

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

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

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

Scrum-мастер

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2. Планирование спринта. На этом собрании разработчики под руководством scrum-мастера определяют объем работы, которую необходимо выполнить в течение текущего спринта. Участники команды выбирают цель спринта, после чего к спринту добавляются конкретные пользовательские истории из бэклога продукта, которые соотносятся с этой целью.  Кроме того, scrum-команда выбирает такие истории, которые участникам будет под силу реализовать в ходе спринта.

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

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

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

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

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

   Чаще всего в рамках стендапа каждому участнику команды предлагается ответить на следующие три вопроса, связанные с достижением цели спринта:
   
   • Что мне удалось сделать вчера?
   • Что я планирую сделать сегодня?
   • Может ли мне что-то помешать?
   
   Впрочем, такое собрание может превратиться в зачитывание заметок из ежедневника. Смысл стендапа в том, чтобы вся болтовня оставалась в рамках ежедневного совещания, а в остальное время команда могла сосредоточиться на работе. Поэтому, если кто-то начинает зачитывать свой график работы на день с листа, смело вносите изменения в порядок проведения.  Проявите творческий подход!

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

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

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

В 2016 году в руководство по Scrum было добавлено пять ценностей. Эти ценности определяют направление работы, действия и поведение scrum-команды. Считается, что они необходимы для успеха scrum-команды.

Обязательность

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

Смелость

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

Сфокусированность

В основе рабочего процесса scrum-команд лежит спринт — конкретный период, в течение которого команда выполняет определенный объем работы. Спринт формирует структуру, а также акцентирует внимание на выполнении запланированных задач.

Открытость

Ежедневный стендап способствует открытости, которая позволяет командам свободно обсуждать текущую работу и блокеры. Scrum-команды в Atlassian часто отвечают на следующие вопросы:

• «Что мне удалось сделать вчера?»

• «Над чем я буду работать сегодня?»

• «Какие проблемы мешают мне двигаться вперед?»

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

Уважение

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

.

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 с помощью Jira, ознакомьтесь с этим руководством.