Курсы Product Live возвращаются в SkillFactory. Найти их можно здесь →
Close
Курсы Product Live возвращаются в SkillFactory. Найти их можно здесь →
Close

Scrum

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

В английском языке scrum — спортивный термин, который на русский можно перевести как «схватка». Перевод во многом раскрывает смысл методики: команда получает опыт, делает на его основе выводы, анализирует успехи и неудачи, работает над самоорганизацией, и, таким образом, совершенствуется.

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

Платформа

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

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

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

Артефакты Scrum

Артефакты Scrum
У Scrum есть артефакты, то есть, создаваемые объекты, инструменты. Всего таких артефакта три — это бэклог продукта, инкремент с критериями готовности и бэклог спринта. Они остаются неизменными, участники команды регулярно обращаются к ним.
1
Бэклог продукта
1
Бэклог продукта
Бэклог продукта — основной перечень задач, над выполнением которых работает скрам-команда. За ведение бэклога отвечает продуктовый менеджер или владелец. Перечень регулярно меняется — в нем появляются новые требования, возможности, коррективы. На их основе формируется список задач для другого артефакта Scrum – бэклога спринта.

Бэклог продукта должен оставаться актуальным. В нем могут и должны меняться приоритеты. Это необходимо для сохранения гибкости и оперативности реагирования на изменения.

После того, как бэклог сформирован, его необходимо поддерживать в состоянии актуальности, то есть, вносить изменения по мере того, как реализуются пункты списка. Задача владельцев продукта — изучать бэклог, пересматривая его перед каждым планированием итерации. Цель — проверять, насколько правильно расставлены приоритеты, и менять их, ориентируясь на выводы предыдущей итерации. «Груминг» — этим термином в Agile обозначают процесс пересмотра бэклога.

Со временем бэклог может стать довольно внушительным. В этом случае product owner меняет схему работы с ним — выделяет задачи в группы: долгосрочные и краткосрочные. Перед тем, как поставить задаче статус краткосрочной, ее нужно глубоко проработать. Проработка включает:
  • формирование пользовательских историй;
  • обсуждение нюансов совместной работы со специалистами;
  • оценка возможных сложностей и «подводных камней» разработки.
Долгосрочные задачи не всегда продумываются от и до. В этом нет ничего страшного, однако участники команды должны оценивать их — для того, чтобы правильно расставить приоритеты. Оценка может быть приблизительной — она изменится после того, как у команды появится понимание долгосрочных задач, и после того, как участники приступят к их выполнению.

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

Бэклог — это связующий элемент между командой и владельцем продукта. Product owner может менять приоритеты в любое время, ориентируясь на обратную связь, которую он получает от клиентов. Также product owner меняет расстановку приоритетов, получая обновленные требования к продукту и уточненные прогнозы. Владельцы продукта, ориентированные на то, чтобы команда работала эффективно, стараются в процессе работы вносить минимум изменений. Такой подход мешает команде, снижает концентрацию, а иногда подрывает моральный настрой и даже дестабилизирует рабочие процессы.
2
Бэклог спринта
2
Бэклог спринта
Бэклог спринта — перечень рабочих задач, историй пользователей и устраненных ошибок. Кто формирует и дополняет этот список по методике Scrum? Команда разработчиков. Она же реализует задачи из списка текущем цикле.

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

Под термином «инкремент» нередко понимают критерии, по которым определяется стадия готовности продукта, цель спринта, точку контроля, а иногда и финальную версию. Здесь все зависит исключительно от того, на какие именно критерии готовности ориентируется scrum team, и по какому принципу ставятся цели спринта. Распространенная практика — выпуск готового решения по итогам каждого спринта. Некоторые команды, напротив, отказываются от такого подхода, не считая его практичным.

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

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

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

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

Организация бэклога

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

Планирование спринта

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

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

Спринт

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

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

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

Ежедневное Scrum-совещание (стендап)

Стендап — это короткое совещание по методам Agile Scrum: управление проектами и разработка продуктов подразумевают проведение таких мероприятий. Стендапы планируются на каждый день, в одно и то же время. Как правило, они проводятся в утренние часы и в одном и том же месте. Стандартная продолжительность стендапа – 15 минут, однако это не правило, а рекомендация.

Цель стендапов — держать каждого участника команды в курсе событий, позволять ему следовать цели и оперативно получать готовый план работы на ближайшие сутки. В рамках стендапа участники команды могут рассказывать о препятствиях на пути к намеченной цели.
Распространенная практика — тестирование в Scrum: предложение участникам команды ответить на три простых вопроса, каждый из которых имеет отношение к цели спринта:
  • «Что я смог сделать за предыдущий день?»
  • «Что я собираюсь сделать за сегодняшний день?»
  • «Есть ли у меня препятствия?».
Важно, чтобы стендап не превращался в вереницу докладов — все должно быть по существу, в краткой и понятной форме.

Обзор итогов спринта

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

По результатам такого собрания product owner может внести изменения в продуктовый бэклог, ориентируясь на итоги предыдущего спринта. Процесс может плавно перейти в стадию планирования очередного спринта. Как определить, сколько времени потребуется на обзор итогов? Это просто: если продолжительность спринта — 30 дней, значит, на обзор итогов должно уходить максимум четыре часа.

Ретроспектива спринта

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

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

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

Ретроспектива способствует укреплению базовых концепций Agile как манифеста гибкого подхода. В числе таких концепций и ценностей:
  • на первом месте — люди и взаимодействие между ними, инструменты и процессы — на втором;
  • готовность меняться важнее, чем следование готовому плану.
Смысл ретроспективы и ее суть — взаимодействие с людьми. Цель взаимодействия — разработка и внесение изменений и совершенствования. Это действительно укрепляет базовые принципы Agile.

Три слагаемых успешности применения Scrum

Три слагаемых успешности применения Scrum
В Scrum-команде участникам отводятся определенные роли. Всего их три — product owner (владелец продукта), scrum-мастер и разработчики. Так как команда выполняет множество разных функций, в ее составе могут быть дизайнеры, специалисты в сфере UX, тестировщики, инженеры.
1
Product owner (владелец продукта Scrum)
1
Product owner (владелец продукта Scrum)
Владельцы заинтересованы в своем продукте и его улучшении. Они должны понимать, какие требования к нему есть у клиентов, у бизнеса и у рынка. Эта информация помогает им правильно расставлять приоритетность задач — тех, над которыми техническая команда будет работать в определенном порядке.

Чем занимается эффективный product owner:
  • формирует бэклог продукта и осуществляет управление им;
  • тесно взаимодействует с топ-менеджментом компании и с командой, объясняет каждому из них значение и суть задач из бэклога;
  • дает участникам команды понятные указания — для того, чтобы они понимали, какие возможности нужно ставить следующими;
  • решает, когда именно нужно ставить продукт (в идеале — так часто, как это возможно).
Product owner — это не всегда продуктовый менеджер. Одна из главных задач владельца продукта – сформировать условия для того, чтобы команда производила то, что для бизнеса будет ценным. Ключевое условие — product owner может быть только один. Если их будет несколько, команда вряд ли захочет работать, получая разные, и, возможно, диаметрально противоположные указания.
2
Scrum-мастер
2
Scrum-мастер
Этот специалист контролирует применение Scrum-принципов в команде. Они берут на себя обучение основам Scrum как участников команды, так и владельцев продуктов и всю компанию, оптимизируя использования практики.

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

Эффективная команда должна быть сплоченной, работающей в одном месте. Ее стандартная численность — от пяти до семи человек. Определить оптимальную численность можно, взяв за основу «правило двух пицц», разработанное основателем «Амазона» Джеффом Безосом. Согласно этому принципу, если участникам хватает двух пицц, значит, команда сформирована.

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

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

Scrum, Kanban и Agile

Scrum, Kanban и Agile
Agile Scrum как методика получила настолько широкое распространение, что эти понятия многие считают синонимами. Однако Scrum — не единственная методика Agile. Кроме нее, есть еще и Kanban, и смешанные модели, сочетающие в себе подходы и принципы и Scrum, и Kanban. В числе таких моделей — Kanplan (Scrumban). Это не что иное, как Kanban, только с бэклогом.

Обе методики — и Kanban, и Scrum – подразумевают применение визуальных средств. Среди них — Scrum-доска: это визуальное средство, по которому можно отслеживать этапы работы. База обеих методик — это эффективность и подход, в рамках которого сложные задачи делятся на более мелкие. Различие между Kanban и Scrum заключается в подходах в достижении поставленных целей.

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

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

Почему стоит выбирать Scrum

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

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

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

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

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