Что такое Scrum и как начать с ним работать
Руководство по Scrum: в чем суть, каков принцип работы и с чего начать
Начните бесплатно с шаблоном Scrum для Jira
Оптимизируйте проект и с легкостью планируйте и отслеживайте работу в спринтах, а также управляйте ею. Шаблон Scrum для Jira включает в себя доски, бэклоги, дорожные карты, отчеты и многое другое.
Что такое Scrum?
Scrum — это методика гибкого управления проектами, помогающая командам структурировать работу и управлять ею на основе определенного набора ценностей, принципов и практик. Как спортивная команда готовится к решающей игре (к слову, scrum — англ. «схватка», элемент игры в регби), так и команда сотрудников компании должна извлекать уроки из полученного опыта, осваивать принципы самоорганизации, работая над решением проблемы, и анализировать свои успехи и провалы, чтобы постоянно совершенствоваться. Scrum содействует этому.
Методика Scrum в ходу у разработчиков приложений, но принципы и опыт ее использования можно применить к командной работе любого рода. Это одна из причин такой популярности методики. Scrum часто представляют как систему для управления проектами с учетом принципов Agile. Участники команды Scrum проводят собрания, используют специальные инструменты и принимают на себя особые роли, чтобы организовать работу и управлять ею.
В этой статье мы обсудим традиционную структуру методологии Scrum с помощью руководства по Scrum и Дэвида Уэста, генерального директора Scrum.org. Мы также приведем примеры наблюдений за тем, как клиенты отходят от этих основ в пользу своих конкретных потребностей. Наш специалист Меган Кук, руководитель отдела по управлению продуктом в Jira и бывший тренер по Agile, поделится советами и рекомендациями в серии видеороликов The Agile Coach.
Статьи по теме Scrum
Сделайте команду сплоченнее с помощью Scrum-досок Jira
Scrum-доска Jira визуально отображает прогресс по ходу разработки.
Получить бесплатноСравнение Agile и 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-команды
Scrum-команда — это небольшая и активная команда, которая ставит целью поставлять продукты твердо обозначенными итерациями. В scrum-команде обычно не так много людей, около 10 человек, но этого достаточно, чтобы выполнить значительный объем работы за спринт. Состав scrum-команды предполагает три конкретные роли: владелец продукта, scrum-мастер и команда разработчиков. Поскольку scrum-команды сочетают в себе несколько дисциплин, в команду разработчиков также входят тестировщики, дизайнеры, специалисты по пользовательскому интерфейсу и инженеры по операциям.
Владелец продукта Scrum
Владельцы ратуют за свой продукт. Их задача — понимать требования бизнеса, клиента и рынка. На основе этого понимания они расставляют приоритеты между рабочими задачами, которые техническая команда будет выполнять в соответствующем порядке. Об эффективных владельцах продукта можно сказать следующее.
- Они составляют бэклог продукта и управляют им.
- Они тесно сотрудничают с руководством компании и командой, сообщая каждому участнику значение рабочих задач в бэклоге продукта.
- Они дают команде понятные указания, чтобы ее участники знали, какие возможности поставить следующими.
-
Они решают, когда поставить продукт, стремясь делать это как можно чаще.
Владелец продукта не всегда выступает его менеджером. Владельцы стремятся создать все условия, чтобы команда разработчиков производила максимальную ценность для бизнеса. Важно, чтобы владельцем продукта был один человек. Вряд ли команда разработчиков захочет получать разные указания от нескольких владельцев одновременно.
Scrum-мастер
Scrum-мастера следят за применением принципов Scrum в своих командах. Они обучают команды, владельцев продуктов и остальную компанию тонкостям scrum-процесса и стараются оптимизировать применение этой практики.
Успех Scrum-мастера зависит от того, насколько хорошо он разбирается в работе, которую выполняет команда, и может помочь команде повысить прозрачность работы и оптимизировать процесс поставки продукта. Это главный координатор, который составляет перечень требуемых ресурсов (кадровых и материально-технических) для собраний по планированию спринта и обзору его итогов, стендапа и ретроспективы спринта.
Команда разработчиков Scrum
На scrum-команды ложится вся основная работа. Они специалисты по принципам сбалансированной разработки. Самые успешные scrum-команды сплочены, находятся в одном месте и обычно состоят из 5–7 участников. Чтобы определить размер команды, можно обратиться к известному «правилу двух пицц», которое сформулировал глава Amazon Джефф Безос: в команде должно быть столько участников, чтобы им хватало двух пицц.
Каждый участник команды обладает своими компетенциями. Участники обучают друг друга выполнению разных задач, чтобы ни один из них не стал препятствием на пути к цели. Успешные scrum-команды способны к самоорганизации, и их подход к проектам пронизан командным духом. Все участники команды помогают друг другу, чтобы успешно завершить спринт.
Scrum-команды составляют план на каждый спринт. Они прогнозируют объем работы, который способны выполнить за итерацию, используя в качестве ориентира показатели своей скорости в прошлых спринтах. Благодаря фиксированной продолжительности итерации команда разработчиков может проанализировать правильность оценки сложности и процесса поставки продукта, что, в свою очередь, значительно повышает точность ее прогнозов со временем.
Артефакты Scrum
Артефакты Scrum — это важная информация, используемая scrum-командой для описания продукта и работ, которые необходимо выполнить для его создания. В Scrum есть три артефакта: бэклог продукта, бэклог спринта и инкремент с вашими критериями готовности. Это три константы, над которыми scrum-команда должна размышлять во время спринтов и с течением времени.
- Бэклог продукта — это главный список задач, которые необходимо выполнить. Его ведет владелец либо менеджер продукта. Это постоянно меняющийся перечень функциональных возможностей, требований, улучшений и исправлений, из которого берутся задачи для бэклога спринта. По сути, это список задач команды. Владелец продукта регулярно просматривает бэклог продукта, меняет в нем приоритеты и поддерживает его актуальность по мере появления новой информации или изменений на рынке, в связи с которыми отдельные задачи утрачивают смысл или возникают новые способы решения проблем.
- Бэклог спринта — это список рабочих задач, пользовательских историй или исправлений багов, отобранных командой разработчиков для реализации в текущем цикле спринта. Перед каждым спринтом проводится собрание по планированию спринта (его мы обсудим далее в статье), на котором команда выбирает, какие задачи из бэклога продукта нужно выполнить в рамках спринта. Бэклог спринта может не быть фиксированным и может меняться по ходу спринта. Однако ничто не должно мешать достижению основной цели спринта — того, чего команда хочет добиться за текущий спринт.
- Инкремент (или цель спринта) — это готовый к использованию конечный продукт по итогам спринта. В компании Atlassian принято представлять инкремент на демонстрации в конце спринта, на которой команда показывает, что она сделала за спринт. Слово «инкремент» не так уж широко встречается в повседневной жизни. Его часто определяют как принятые в команде критерии готовности продукта, контрольную точку, цель спринта или даже полную версию или поставленный эпик. Все зависит от того, какими критериями готовности руководствуется ваша команда и как выбираются цели спринта. Например, некоторые команды предпочитают выпускать что-нибудь для своих клиентов в конце каждого спринта. Для них слово «готово» означает «поставлено». Однако для других команд это может быть непрактично. Представьте, что вы работаете над серверным продуктом, который можно поставлять клиентам лишь раз в три месяца. Вы по-прежнему можете разбивать работу на двухнедельные спринты, но для вас продукт будет «готов», когда вы завершите работу над частью большей версии, которую планируете поставить целиком. Однако не будем забывать, что чем больше времени уходит на выпуск ПО, тем меньше шансов у этого ПО снискать успех.
Как видите, допустимы различные варианты, даже когда речь идет об артефактах, которым ваша команда может придавать ту или иную форму. Это показывает, почему важно оставаться открытыми к совершенствованию, в частности к совершенствованию способа ведения артефактов. Возможно, из-за принятых критериев готовности ваша команда испытывает чрезмерное давление и вам нужно пересмотреть эти критерии.
В отношении методологии нужно сохранять ту же гибкость, что и в отношении продукта. Уделите какое-то время оценке общей ситуации, при необходимости внесите поправки и не пытайтесь добиться чего-либо любой ценой просто потому, что «так принято».
Собрания или мероприятия Scrum
Методика Scrum включает практики, церемонии или собрания, которые регулярно проводят scrum-команды. Именно в Agile-собраниях заметнее всего проявляются различия между командами. Некоторым командам в тягость проводить однообразные собрания; в других рабочие встречи обязательны. Если вы только начинаете знакомство со Scrum, рекомендуется в течение первых двух спринтов провести все собрания, чтобы понять свое отношение к ним. После этого можно организовать короткую ретроспективу, чтобы решить, что нужно скорректировать.
Перечислим основные собрания, в которых может принять участие команда Scrum.
-
Организация бэклога. За это мероприятие, также известное как ведение бэклога, несет ответственность владелец продукта. В число его основных обязанностей входят приведение продукта в соответствие с его концепцией и постоянное отслеживание настроений на рынке и потребностей клиента. Для этого владелец продукта и ведет список, изменяя в нем приоритеты и поддерживая его в актуальном виде на основании информации от пользователей и команды разработчиков, чтобы в любое время можно было приступить к работе над внесенными в него задачами. Подробнее о том, как правильно вести бэклог, можно прочитать здесь.
-
Планирование спринта. На этом собрании команда разработчиков под руководством scrum-мастера планирует работу (объем спринта), которую необходимо выполнить в течение текущего спринта. На собрании выбирается цель спринта. Затем в спринт добавляются конкретные пользовательские истории из бэклога продукта. Эти истории всегда соотносятся с целью. При этом команда Scrum согласовывает такие истории, которые можно будет реализовать на практике в ходе спринта.
В конце собрания по планированию каждый участник команды Scrum должен четко представлять, какие задачи можно выполнить за спринт и как поставить инкремент. -
Спринт. Спринт — это фактический промежуток времени, в течение которого команда Scrum совместно работает над созданием готового инкремента. Как правило, спринт длится две недели, хотя некоторым командам проще спланировать объем спринта на одну неделю или поставить инкремент, обладающий достаточной ценностью, за месяц. Дейв Уэст из Scrum.org рекомендует планировать спринт тем короче, чем сложнее работа и чем больше в ней неизвестных. Но последнее слово всегда за командой. Не стесняйтесь менять продолжительность спринта, если покажется, что она вам не подходит. В течение этого периода владелец продукта и команда разработчиков могут пересмотреть объем спринта, если это необходимо. Это и есть ключ к пониманию эмпирической сути Scrum.
Все мероприятия, от планирования до ретроспективы, проводятся в течение спринта. После того как временной промежуток для спринта определен, он должен оставаться неизменным, пока ведется разработка. Так команда будет извлекать ценные уроки из прошлого опыта и применять выводы к будущим спринтам. -
Ежедневное scrum-совещание, или стендап. Это очень быстрое ежедневное совещание, которое проводится в одно и то же время (обычно утром) в стиле «коротко и по делу». Многие команды стараются уложиться в 15 минут, однако это лишь рекомендация. Такое собрание еще называют «ежедневным стендапом» (от англ. stand up, т. е. «совещание стоя»), что подчеркивает его краткость. Ежедневное scrum-совещание проводится, чтобы все участники команды были в курсе происходящего, не отклонялись от цели спринта и имели план работы на ближайшие 24 часа.
Стендап — подходящее время сообщить обо всем, что мешает вам достичь цели спринта, в том числе о блокерах.
Чаще всего в рамках стендапа каждому участнику команды предлагается ответить на следующие три вопроса, связанные с достижением цели спринта:
• Что мне удалось сделать вчера?
• Что я планирую сделать сегодня?
• Может ли мне что-то помешать?
Впрочем, такое собрание может превратиться в зачитывание записей из ежедневника. Смысл стендапа в том, чтобы все отвлекающие разговоры оставалась в рамках ежедневного совещания, а в остальное время команда могла сосредоточиться на работе. Если дела из ежедневников это все, что вам удается обсудить, не бойтесь внести изменения и проявить творческий подход. -
Обзор итогов спринта. В конце спринта команда собирается для просмотра демонстрации инкремента (или для его изучения) в неформальной обстановке. Разработчики представляют заинтересованным сторонам и коллегам завершенные рабочие задачи из бэклога, чтобы собрать отзывы. Владелец продукта решает, стоит ли выпускать инкремент, хотя в большинстве случаев команда получает зеленый свет.
На собрании по обзору итогов владелец продукта также изменяет бэклог продукта на основании результатов последнего завершенного спринта. Если спринт длится один месяц, отводите под собрание для обзора итогов спринта не более четырех часов. -
Ретроспектива спринта. Ретроспектива проводится, чтобы команда зафиксировала и обсудила все успехи и неудачи спринта, проекта, участников и их взаимоотношений, инструментов или даже определенных собраний. Цель ретроспективы — создать условия, чтобы команда могла уделить внимание всему, что удалось и что нужно улучшить в следующий раз, и не зацикливалась на неудачах.
Начните бесплатно с шаблоном Scrum для Jira
Оптимизируйте проект и с легкостью планируйте и отслеживайте работу в спринтах, а также управляйте ею. Шаблон Scrum для Jira включает в себя доски, бэклоги, дорожные карты, отчеты и многое другое.
Ценности Scrum
В 2016 году в руководство по Scrum было добавлено пять ценностей. Эти ценности определяют направление работы, действия и поведение scrum-команды. Считается, что они необходимы для успеха scrum-команды.
Подтверждение
Из-за небольшого размера и гибкости scrum-команды успех зависит от каждого участника. Именно поэтому каждый участник должен брать такой объем задач, который он сможет выполнить, и не взваливать на себя слишком много. Затем участники должны как можно чаще отчитываться о прогрессе, обычно это происходит на стендапах.
Смелость
Смелость для scrum-команды — это мужество ставить под сомнение существующее положение вещей или что-то, что мешает ей достичь успеха. Участники scrum-команды должны не бояться и располагать свободой пробовать что-то новое. Они должны уметь открыто сообщать о препятствиях, ходе выполнения проекта, задержках и т. д.
Ключевая деятельность
В основе рабочего процесса scrum-команд лежит спринт — конкретный период, в течение которого команда выполняет определенный объем работы. Спринт формирует структуру, а также акцентирует внимание на выполнении запланированных задач.
Открытость
Ежедневный стендап способствует открытости, которая позволяет командам свободно обсуждать текущую работу и блокеры. Scrum-команды в Atlassian часто отвечают на следующие вопросы:
- «Что мне удалось сделать вчера?»
- «Над чем я буду работать сегодня?»
- «Какие проблемы мешают мне двигаться вперед?»
Они помогают осветить прогресс и выявить блокеры. Кроме того, когда каждый сообщает о своем вкладе в общее дело, укрепляются связи внутри команды.
Уважение
Сила команды, следующей принципам Agile, заключается в совместной работе и признании вклада каждого участника спринта. Они отмечают достижения друг друга, а также уважают коллег, владельца продукта, заинтересованные стороны и scrum-мастера.
Scrum, Kanban и agile
Scrum — настолько популярная agile-методика, что слова Scrum и Agile многие ошибочно используют как синонимы. Но есть и другие методики, например Kanban, которая тоже весьма распространена. Некоторые компании даже предпочитают гибридную модель, сочетающую в себе элементы Scrum и Kanban. Ее называют Scrumban или Kanplan — по сути, Kanban с бэклогом.
И в Scrum, и в Kanban используются визуальные средства, такие как доска Scrum или доска Kanban, для отслеживания прогресса по работе. В основе обеих методик лежит деление сложных заданий на мелкие рабочие задачи, поддающиеся выполнению, для повышения эффективности. Однако их подходы к постановке целей различаются.
Scrum строится вокруг небольших итераций с фиксированной продолжительностью. Сначала нужно определить длительность спринта, после чего выбрать пользовательские истории или элементы бэклога продукта, которые можно реализовать в течение этого цикла спринта. В Kanban же количество заданий (или объем незавершенной работы) на текущий цикл задается изначально. Время, затраченное на разработку этих функций продукта, вычисляется постфактум.
У методики Kanban нет четкой структуры, присущей Scrum. В ней есть ограничения WIP, но все остальные аспекты можно в той или иной мере изменить по вкусу. В Scrum же присутствует несколько строго определенных понятий, составляющих неотъемлемую часть этого подхода: обзор итогов спринта, ретроспектива, ежедневное Scrum-совещание и т. д. Scrum также требует формирования многофункциональной команды, чтобы возможность достижения цели не зависела от сторонних участников. Собрать междолжностную команду — нетривиальная задача. В этом плане к Kanban проще адаптироваться, тогда как внедрение Scrum влечет за собой коренную перестройку мышления и деятельности команды разработчиков.
Начало работы со Scrum
Сама по себе методика Scrum проста. Понять правила, артефакты, мероприятия и роли несложно. Она задает структуру, но в ней есть свобода выбора, которая исключает белые пятна в процессе разработки и позволяет в должной мере учесть специфику разных компаний.
Сложные задания можно упорядочивать в легко выполнимые пользовательские истории, а значит, Scrum идеально подойдет для сложных проектов. Благодаря тому, что роли и плановые мероприятия четко разграничены, на протяжении всего цикла разработки сохраняется прозрачность и коллективная ответственность. Частый выпуск продуктов мотивирует команду и гарантирует удовлетворенность пользователей, ведь они видят, как продукт развивается в течение короткого отрезка времени.
И все же, чтобы овладеть Scrum, может понадобиться какое-то время, особенно если команда разработчиков привыкла к стандартной каскадной модели. Новой команде предстоит выбрать scrum-мастера, освоиться в мире коротких итераций, ежедневных scrum-собраний и обзоров итогов спринта. Это может стать настоящим сотрясением основ.
Но преимущества в долгосрочной перспективе перевешивают все сложности, связанные с освоением новых принципов. Scrum успешно применяется в разработке сложного аппаратного и программного обеспечения в самых разных отраслях и на вертикальных рынках. Это хороший довод в пользу внедрения методики в рамках организации.
Чтобы изучить Scrum с помощью Jira, ознакомьтесь с этим руководством.
Связанные ресурсы
Начните бесплатно с шаблоном Scrum для Jira
Оптимизируйте проект и с легкостью планируйте и отслеживайте работу в спринтах, а также управляйте ею. Шаблон Scrum для Jira включает в себя доски, бэклоги, дорожные карты, отчеты и многое другое.
Kanban
Знакомство agile-команд разработчиков с Kanban и преимущества этой методологии для вашей agile-команды.
Читать статью