SCRUM - методология гибкой разработки

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

Что такое Scrum?

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

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

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

Спринты

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

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

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

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

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

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

Авторы Scrum действительно все предусмотрели. Чтобы запланировать предстоящий спринт, нужно провести собрание по планированию спринта. Планирование спринта — это мероприятие, на котором команда сообща отвечает на два основных вопроса: какую работу можно выполнить в этом спринте и как она будет выполняться?

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

Выбранные рабочие задачи и план по их выполнению называется бэклогом спринта. К концу совещания по планированию спринта команда готова приступить к работе. Для этого необходимо просто выбирать задачи из бэклога спринта и менять их статус с «В работе» на «Готово» по мере завершения работы.

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

Завершите цикл спринтов на моем любимом собрании — ретроспективе спринта. Здесь команда может определить области, требующие улучшения в следующем спринте. С этими сведениями можно начинать следующий цикл спринта. Вперед!

Бэклог продукта

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

Что стоит и не стоит делать

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

Что нужно делать:

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

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

  • Убедитесь, что вы правильно оцениваете скорость работы команды и учитываете такие события, как отпуска и общие собрания.

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

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

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

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

Чего не стоит делать.

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

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

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

Кроме того, не берите слишком большой объем неопределенной или рискованной работы. Делите крупные истории либо истории с высокой степенью неопределенности и смело оставляйте часть работы для следующего спринта.

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

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

Планирование спринта — это событие в scrum, которое знаменует начало спринта. В ходе планирования определяется объем работы на спринт и способы выполнения этой работы. Планирование спринта осуществляется при содействии всей команды scrum.

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

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

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

  • "Кто". Планирование спринта невозможно без участия владельца продукта и команды разработчиков. Владелец продукта ставит цель, которая зависит от искомой ценности. Команда разработчиков должна понять, может ли она достичь этой цели (и как это сделать). Если одна из этих сторон отсутствует на мероприятии, планировать спринт становится практически невозможно.

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

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

Подготовка к собранию по планированию спринта

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

Ограничение времени, отведенного на планирование спринта

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

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

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

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

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

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

Когда задачи четко сформулированы, любой может успешно выполнить свою работу. В Jira можно без труда добавить дополнительные поля. Для этого администратору нужно всего лишь нажать кнопку Admin (Администрирование) в задаче.

Небольшой совет напоследок

У команд, которым обзоры итогов спринтов в новинку, есть сильное искушение объединить обзор итогов с ретроспективой. Совещание для обзора итогов спринта не связано с ретроспективой спринта. Найдите время насладиться результатами своих трудов. Смело празднуйте победы. Хорошие обзоры итогов спринтов укрепляют моральный дух команды и мотивируют ее на дальнейшие свершения.

Поделиться:

Теги:

    Сделаем это вместе -
    У вашего бизнеса есть история

    Заказ обратного звонка

    Мы перезвоним вам в течение часа или в удобное для вас время

    Live Chat
    ×
    Мы используем файлы cookie, чтобы обеспечить вам максимальное удобство на нашем веб-сайте. Если вы продолжите использовать этот сайт, мы будем считать, что вы согласны с их использованием.
    Политика конфиденциальности