Что такое scrum, как его реализуют и для чего применяют

Определение

Agile (agile software development, от англ. agile – проворный) – это семейство «гибких» подходов к разработке программного обеспечения. Такие подходы также иногда называют фреймворками или agile-методологиями.

Agile возник в IT-среде, но затем распространился и в другие сферы – от промышленной инженерии до искусственного интеллекта.

Смысл Agile сформулирован в Agile-манифесте разработки ПО: «Люди и взаимодействие важнее процессов и инструментов. Работающий продукт важнее исчерпывающей документации. Сотрудничество с заказчиком важнее согласования условий контракта. Готовность к изменениям важнее следования первоначальному плану».

Agile-манифест – главный документ всех «гибких» подходов к разработке. Он был создан в 2001 году группой энтузиастов-программистов, которые хотели понять, что именно лежит в основе разработки востребованного и полезного IT-продукта.Agile предполагает, что при реализации проекта не нужно опираться только на заранее созданные подробные планы

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

К отдельным agile-подходам относятся scrum и kanban.

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

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

Kanban – это «подход баланса». Его задача – сбалансировать разных специалистов внутри команды и избежать ситуации, когда дизайнеры работают сутками, а разработчики жалуются на отсутствие новых задач.

Вся команда едина – в kanban нет ролей владельца продукта и scrum-мастера. Бизнес-процесс делится не на универсальные спринты, а на стадии выполнения конкретных задач: «Планируется», «Разрабатывается», «Тестируется», «Завершено» и др.

Главный показатель эффективности в kanban – это среднее время прохождения задачи по доске. Задача прошла быстро – команда работала продуктивно и слаженно. Задача затянулась – надо думать, на каком этапе и почему возникли задержки и чью работу надо оптимизировать.

Для визуализации agile-подходов используют доски: физические и электронные

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

Как внедряют

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

1. Найдите настольную игру getkanban и поиграйте в нее с коллегами. Официальная версия стоит $450, но в интернете есть и другие варианты.

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

3. Подумайте, какие стадии проходит любая задача. В простейшем варианте это может быть «Запланирована → В работе → Завершена». Вариант посложнее: «Запланирована → Дизайн → Разработка → Интеграция → Готово». Статусы зависят от того, что именно вы делаете.

4. Проставьте ограничения на статус задач так, как подсказывает логика. Если у вас два дизайнера и три программиста, пусть в колонке дизайна будет максимум 2 задачи, а на доске «В разработке» — 3.

5. Проведите первое совещание. Обсудите, как организуете работу. Когда будете релизить продукт, а когда собираться на совещания.

6.Перенесите несколько задач из бэклога в «Запланировано» и запускайте процесс.

7. Следите, чтобы карточки путешествовали между колонками, когда задача перешла из одного статуса в другой.

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

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

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

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

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

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

Главное и в Kanban, и в Scrum — это люди.

Мнение автора и редакции может не совпадать. Хотите написать колонку для Нетологии? Читайте наши условия публикации. Чтобы быть в курсе всех новостей и читать новые статьи, присоединяйтесь к Телеграм-каналу Нетологии.

Как и зачем появилась scrum-методология

До появления Scrum в мире разработки программного обеспечения было принято использовать «водопадный подход». Работа над продуктом велась по следующему плану.

1. Определить требования к продукту.
2. Спланировать весь проект от начала до конца.
3. Написать код.
4. Протестировать продукт.

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

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

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

Манифест гибкой разработки ПО 

 1. Люди важнее инструментов. 2. Качество продукта важнее документации. 3. Взаимодействие с заказчиком важнее контракта. 4. Готовность к изменениям важнее установленного плана.

Эти четыре пункта стали основой для появления Agile, гибкого процесса разработки программного обеспечения. Позже были созданы12 принципов, которые и сейчас используются в любой agile-методологии.

12 принципов Agile

 1. Главное — хорошее ПО и довольный заказчик. 2. Готовность к изменениям в любой момент. 3. Полностью рабочее ПО — как можно чаще. 4. Встреча команды — лучше всего для обмена информацией. 5. Заказчик и команда разработки должны работать вместе. 6. Доверять людям делать свою работу. 7. Есть рабочее ПО — есть прогресс. 8. Гибкие процессы — непрерывное развитие. 9

Внимание к качеству способствует гибкости. 10

Простота процесса позволяет не делать лишней работы. 11. Самоорганизующаяся команда лучше работает. 12. Постоянное стремление к большей эффективности.

Agile и водопад, весы

Одна из методологий гибкого процесса разработки программного обеспечения, которая базируется на agile-принципах, — Scrum.

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

Ценности Agile простыми словами

Ценности Agile родились в 2001 году в Agile-манифесте — в результате обобщения многих тогдашних «методологий разработки» их авторами.

Ценности — это то общее, что определяет приоритеты в работе, независимо от конкретного процесса и предмета работы. Каждая из 4-х ценностей Agile сформулирована в виде «X важнее Y», где X — это:

1. люди,
2. работающий продукт,
3. сотрудничество с заказчиком,
4. готовность к изменениям.

Посмотрим, зачем нужны эти ценности Agile.

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

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

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

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

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

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

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

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

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

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

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

Чтобы не откладывать риски проектов на последние стадии разработки (когда будет уже поздно уменьшать содержание работы, сдвигать срок или усиливать команду), Agile предлагает не только итеративность работы, но и готовность к изменениям на всех стадиях.

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

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

Что такое scrum-board?

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

Скрам-доска похожа на многоколоночный список элементов, позволяющий команде разработчиков:

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

• Контролировать процесс работы. Наблюдать за сотрудниками и грамотно распределять между ними задачи/функции.

• Следить за прогрессом текущего спринта. Чтобы задачи вовремя попадали в список выполненных. 

• Проводить аналитические совещания с целью обсудить успехи компании. 

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

Структура скрам-доски

Скрам-борд делится на несколько блоков. Мы рассмотрим 6 распространенных блоков (их может быть больше или меньше).

1. Stories. Одна story – это информация об особенности продукта, которую желает видеть большое количество пользователей. Новый дизайн, новая настройка, новая функция. Это может быть что угодно. Со stories начинается целеполагание. Лидеры команды решают, чем будет заниматься команда в грядущий спринт. 
2. Надо сделать. Story нужно поделить на части. На конкретные задачи, которые разработчики смогут решать. Берем не функцию в ее глобальном понимании, а какую-то минимальную часть, посильную и компактную. 
3. Делается. Это те «куски» story, которые уже разобрали. Над ними ведется работа в конкретный период. Задача лидера команды отслеживать продолжительность нахождения карточек в категории «Делается». Чем меньше этот период, тем лучше.
4. Сделано. Те части story, что уже были закончены. Этот раздел доски помогает отслеживать прогресс и анализировать работу. 
5. Проверяется. Выполненные задачи, нуждающиеся в дополнительной проверке или контроле качества кода. Несмотря на то, что эта колонка часто располагается правее колонки «Сделано», карточки из «Делается» попадают сюда раньше.
6. Отложено. Функции, которые почему-то не получается реализовать в текущем спринте. Отсюда они переносятся на следующий «забег».

Физические доски

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

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

Цифровые скрам-доски

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

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

• Цифровой доской можно пользоваться хоть вдесятером одновременно. Без помех и неудобств. 

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

• Визуальную составляющую цифрового скрам-борда можно настроить под свои предпочтения.

Мнение автора: новое руководство — способ монетизации услуг скрам-мастеров

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

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

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

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

Вот неполный список обязанностей скрам-мастера:

1. Отвечать за эффективность команды: организовать коучинг, налаживать самоуправление, следить за кросс-функциональностью разработчиков, устранять организационные препятствия.
2. Делать так, чтобы работа над проектом не выбивалась из срока, не распылялась на лишние задачи, не теряла в качестве и соответствовала цели продукта.
3. Помогать владельцам продукта определить главную цель, подготовить список задач для каждого спринта и наладить общение с заказчиками.
4. Налаживать связь между несколькими командами.
5. Популяризовать Scrum.

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

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

Что такое Scrum. Суть методики

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

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

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

Scrum не требует внедрения каких-либо дорогостоящих инструментов. Схему методики Scrum вкратце можно описать следующим образом:

1. Для начала необходимо выбрать «Владельца продукта» — человека, обладающего видением того, что вы собираетесь создать или достигнуть.
2. Затем нужно собрать «Команду», в которую войдут люди, непосредственно выполняющие работу. Они должны обладать навыками и знаниями, которые помогут воплотить идею владельца продукта в жизнь.
3. Нужно выбрать «Скрам-мастера» — того, кто будет следить за ходом реализации проекта, обеспечивать проведение коротких собраний и помогать команде устранять препятствия на пути достижения цели.
4. Приступая к работе, нужно создать максимально полный список всех требований, предъявляемых к продукту или цели. Пункты этого списка должны быть расставлены по приоритету. Список носит название «Бэклог продукта». Он может развиваться и изменяться на протяжении всего срока реализации проекта.
5. Участники команды должны оценить по своей системе оценок каждый пункт на предмет сложности и затрат, которые потребуются для его выполнения.
6. Затем участники, скрам-мастер и владелец продукта должны провести первое скрам-собрание, на котором они запланируют спринт —определенное время для выполнения части заданий. Продолжительность спринта не должна превышать один месяц. За каждый спринт команда нарабатывает определенное количество баллов. Команда должна постоянно стремиться к тому, чтобы превзойти в новом спринте количество наработанных баллов за предыдущий спринт, то есть ее цель — постоянно превосходить свои собственные результаты — «наращивать динамику производительности».
7. Чтобы все участники были в курсе состояния дел нужно завести скрам-доску с тремя колонками: «Нужно сделать, или бэклог»; «В работе»; «Сделано». На доску участники клеят стикеры с заданиями, которые в процессе работы поочередно перемещаются из колонки «Бэклог» в колонку «в работе», а затем в «сделано».
8. Ежедневно проводится скрам-собрание. По выражению Джеффа Сазерленда «это пульс всего процесса Scrum». Суть его проста —ежедневно, на ходу, пятнадцать минут на то, чтобы все дали ответы на три вопроса: «Что ты делал вчера, чтобы помочь команде завершить спринт?», «Что ты будешь делать сегодня, чтобы помочь команде завершить спринт?», «Какие препятствия встают на пути команды?».
9. По завершении спринта команда делает его обзор — проводит встречу, на которой участники рассказывают, что сделано за спринт.
10. После показа результатов работы за спринт участники проводят ретроспективное собрание, на котором обсуждают, что команда делала хорошо, что можно сделать лучше, что можно улучшить прямо сейчас.

Самостоятельная практика Agile

Если вам не повезло, и в вашем учебном заведении даже нет намёков на новые технологии, вы можете воспользоваться советом из книги «К чёрту всё! Берись и делай!» Ричарда Брэнсона и запустить их самостоятельно.

Основатель Virgin Group Ричард Брэнсон по праву считается королём Agile-управления в бизнесе. Он внедрил большое количество инновационных стратегий, которые позволили повысить мотивацию и удовлетворённость сотрудников. Такой подход помог Брэнсону стать миллиардером и завоевать симпатии подчинённых.

Вот несколько вариантов, как это сделать:

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

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

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

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

Планирования Спринта члены Команды ищут ответы на следующие вопросы соответственно:

• Что будет разработано в Инкременте, являющимся результатом работы следующего Спринта?
• Как максимально эффективно выполнить работу по созданию Инкремента?

Часть первая: Что будет сделано в этом Спринте?

В этой части Команда Разработчиков пытается спланировать функциональность, которая будет разработана во время Спринта. Владелец Продукта представляет Команде Разработчиков упорядоченный Журнал Продукта и вся Скрам Команда старается достичь единого понимания работы, которую предстоит проделать на протяжении Спринта.
Входными для этой встречи являются Журнал Продукта, последний разработанный Инкремент продукта, возможности Команды Разработчиков, а также последний показатель ее продуктивности. Количество элементов из Журнала Продукта, которые Команда способна выполнить до окончания Спринта определяется самой Командой. Только Команда Разработчиков может реально оценить объем работы, который она в состоянии завершить до окончания Спринта.
После того, как Команда Разработчиков спрогнозирует элементы Журнала Продукта, которые она выполнит в данном Спринте, Скрам Команда приступает к формированию Цели Спринта. Цель Спринта – это цель, которая будет достигнута в результате Спринта благодаря реализации Журнала Продукта и которая указывает Команде Разработчиков, почему она работает именно над этим Инкрементом функциональности.

Часть вторая: Как выбранная работа будет проделана?

После того, как объем работы Спринта определен, Команда Разработчиков решает каким образом на протяжении Спринта воплотить отдельную функциональность в “готовый” Инкремент продукта. Требования Журнала Продукта, выбранные для выполнения во время ближайшего Спринта вместе с планом их разработки, называют Журналом Задач Спринта (Sprint Backlog).

Как правило, Команда Разработчиков начинает планировать систему и работу, благодаря которой Журнал Продукта можно превратить в работающий Инкремент продукта. Работа может быть разной степени трудоемкости и сложности. Однако обычно во время Планирования Спринта Команда Разработчиков планирует такой объем работы, который она в состоянии выполнить за Спринт. До окончания этой встречи работа, запланированная Командой Разработчиков на первые дни Спринта, разбивается на требования, которые можно выполнить за день или менее. Команда Разработчиков сама организовывает свою работу, планируя поэтапность выполнения требований из Журнала

Спринта как во время встречи по Планированию Спринта, так и, при необходимости, на протяжении всего Спринта.
Владелец Продукта может присутствовать на второй части Планирования Спринта, чтобы иметь возможность объяснить задания из Журнала Продукта и, при необходимости, помочь найти альтернативы. Если же Команда Разработчиков решает, что у нее слишком много, либо слишком мало работы, она может повторно обсудить требования Журнала Спринта с Владельцем Продукта. Команда может пригласить людей со стороны, чтобы они посоветовали что-то с технической или же экспертной точки зрения.
До окончания встречи по Планированию Спринта Команда Разработчиков должна быть в состоянии объяснить Владельцу Продукта и Скрам Мастеру, каким образом она собирается работать в качестве самоуправляемой команды, чтобы достичь Цели Спринта и создать ожидаемый Инкремент продукта.

Цель Спринта

Цель Спринта придает работе Команды Разработчиков некоторую гибкость в отношении разработки функциональности во время Спринта.
Пока Команда работает, эта цель служит для нее ориентиром. Для ее достижения Команда Разработчиков реализовывает функциональность и технологию. Если же работа оказывается сложнее, чем ожидалось, тогда Команда Разработчиков договаривается с Владельцем Продукта об изменении объема Журнала Спринта в текущем Спринте.
Цель Спринта может быть важным этапом на пути к более высокой цели в разработке конечного продукта.

Planning poker и Story Points

Подход к коллективной оценке под названием  “покер планирования” (Planning poker)  получил свое название благодаря Джеймсу Гренингу (James Grenning) в 2002 году, но лишь благодаря Майку Кону этот метод получил широкое распространение и стал обычной практикой в Scrum, наряду с относительными оценками.

Произошло это потому, что в 2005 году вышла книга Майка Кона “Agile Estimating and Planning”, в которой подробно рассматривались способы коллективной оценки, и давались подробные разъяснения об относительных оценках в Story Points или идеальных часах.

Там же рассказывалось о дельфийском методе оценки, и его адаптации для Scrum в виде “покера планирования”.

Книга изобилует графиками, пояснениями, расчетами, поясняющими идею относительных оценок. Например, вот визуализация распределения времени завершения для разных оценок в Story Points:

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

Ежедневные Скрамы

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

• Что было сделано со времени прошлой встречи?
• Что планируется сделать до следующей встречи?
• Что ему мешает в выполнении запланированных заданий?

Члены Команды Разработчиков используют Ежедневные Скрамы для оценки прогресса продвижения к Цели Спринта, а для оценки отклонения от планируемого завершения работ из Журнала Спринта. Ежедневные Скрамы усиливают вероятность того, что Команда Разработчиков достигнет Цели Спринта. Часто Команда Разработчиков встречается сразу же после Ежедневного Скрама для перепланирования оставшейся работы по Спринту. Ежедневно Команда Разработчиков должна быть в состоянии объяснить Владельцу Продукта и Скрам Мастеру как она намеревается работать в качестве самоуправляемой Команды для достижения цели и создания ожидаемого инкремента продукта за время, оставшееся до окончания Спринта.

Скрам Мастер ответственен за то, чтобы Команда Разработчиков не пропускала такие совещания, однако ответственность за проведение Ежедневного Скрама лежит на Команде Разработчиков. Скрам Мастер обучает Команду Разработчиков удерживать время проведения Ежедневного Скрама в границах не более 15 минут.
Скрам Мастер обеспечивает соблюдение того, чтобы участвовали в Ежедневных Скрамах только члены Команды Разработчиков. Ежедневный Скрам не является статус-совещанием, а скорее совещанием для членов Команды, работающей над превращением требований из Журнала Продукта в Инкремент готового продукта.

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

Заключение: обязанности скрам-мастера

Итак, скрам-мастер имеет много важных и непростых обязанностей по отношению к скрам-команде:

1. Чтобы  «помочь Scrum-команде фокусироваться на создании инкрементов с высокой ценностью» ( Scrum Guide 2020), скрам-мастер приучает команду коллективно принимать решения и вместе отвечать за результат. Делает это он с помощью эффективного проведения встреч Scrum, особенно планирования и обзора спринта.
2. Чтобы люди могли конструктивно общаться и не ссорились, скрам-мастер обеспечивает, «что все события Scrum … позитивны, продуктивны и не выходят за рамки ограничений по времени», эти встречи, а также «коучит участников команды в части самоуправления» ( Scrum Guide 2020).
3. Чтобы «способствовать устранению препятствий, мешающих прогрессу Scrum-команды» ( Scrum Guide 2020), скрам-мастер проводит ретроспективы, вовлекая там людей в устранение сначала внутренних препятствий, находящихся в зоне контроля команды, а затем и внешних препятствий, на которые команда может влиять.
4. И конечно, скрам-мастер обучает команду всем элементам Скрама, помогает понять их смысл и правильно их применять.

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

При реализации Scrum есть много нюансов, и большинство из них касаются именно работы скрам-мастера. Как говорится в Руководстве по Скраму, «Scrum прост для понимания, но сложен для овладения в совершенстве».

А если вам понравились картинки Scrum-встреч из этой статьи, рекомендую скачать для своей команды плакат по Scrum Guide 2020, содержащий эти картинки и не только их: все понятия Scrum в одном месте!