Учебное руководство по scrum
Ознакомившись с пошаговыми инструкциями в этом учебном руководстве, вы сможете вести проект Scrum, расставлять приоритеты в бэклоге и упорядочивать работу в нем в спринты, проводить scrum-собрания и не только — причем прямо в Jira.
Время:
10 минут на прочтение. Прохождение учебного курса занимает 2 недели.
Аудитория:
Вы только начинаете знакомство со Scrum, agile-разработкой ПО или Jira.
Обязательное условие:
Вы создали аккаунт Jira.
Scrum — одна из самых популярных методик реализации agile. В рамках Scrum продукт создается в ходе серии итераций с фиксированной длительностью. Такие итерации называются спринтами. Благодаря им agile-команды могут поставлять результаты работы в регулярном ритме.
Шаг 1. Создание проекта scrum
Создайте аккаунт Jira и войдите в него. Теперь вы можете выбрать шаблон из библиотеки. Выберите Scrum. (Вы можете просмотреть бесплатный шаблон Scrum или узнать, как создать проект Kanban.)
Далее будет предложено выбрать тип проекта. Если ваша команда работает самостоятельно и хочет управлять собственными рабочими процессами и практиками в независимом пространстве, попробуйте шаблон команды Scrum. Подробнее см. в статье о начале работы с проектами команды в сообществе Atlassian.
После создания проекта откроется пустой бэклог. Бэклог, или бэклог продукта, содержит текущий перечень потенциальных рабочих задач команды по проекту.
Шаг 2. Создание пользовательских историй или заданий в бэклоге
В Jira рабочие задачи, такие как пользовательские истории, задания и баги, называются просто «задачами». Создайте несколько пользовательских историй с помощью опции быстрого создания в бэклоге. Если не получается придумать пользовательские истории, просто используйте примеры историй, чтобы начать работу и познакомиться с процессом.
В пользовательских историях рабочие задачи описываются нетехническим языком и с точки зрения пользователя. Как {тип пользователя}, я хочу {цель}, чтобы {извлечь пользу}.
Чтобы создать пользовательскую историю, в качестве примера представим веб-сайт.
Как клиент я хочу иметь возможность создавать аккаунт, чтобы можно было видеть мои предыдущие покупки.
Обычно пользовательские истории в общих чертах прописывает владелец продукта, после чего команда разработчиков определяет конкретные задания, которые нужно выполнить, чтобы завершить историю за следующий спринт. Команда разработчиков также должна оценить относительные трудозатраты для завершения работы над историей.
Создав несколько пользовательских историй, можно приступать к расстановке приоритетов в бэклоге. В Jira расположить истории в порядке приоритетности можно путем их перетаскивания, чтобы выстроить последовательность, в которой будет идти работа.
Это всего лишь первые примеры историй в проекте. Вы продолжите создавать истории на протяжении всей работы. Agile-методики подразумевают непрерывное обучение и адаптацию.
Шаг 3. Создание спринта
Создайте первый спринт в бэклоге, чтобы приступить к его планированию.
При работе в scrum команды планируют выполнить ряд пользовательских историй или других рабочих задач за фиксированный отрезок времени, также известный как спринт. Как правило, спринты продолжаются одну, две или четыре недели. Продолжительность спринта определяет команда, но начинать рекомендуется с двух недель. Это достаточно большой промежуток, чтобы что-то закончить, и при этом достаточно краткий промежуток, позволяющий команде регулярно получала отзывы о работе. Определив график спринтов, команда постоянно работает по нему. Спринты фиксированной продолжительности помогают развивать навыки оценки сложности и прогнозировать будущую скорость команды по мере работы над бэклогом.
Шаг 4. Проведение собрания по планированию спринта
В начале спринта следует провести собрание по планированию спринта со всей командой. На собрании по планированию закладывается основа для успешного спринта. В ходе него вся команда обсуждает цель спринта и истории из бэклога продукта, в котором уже расставлены приоритеты. Команда разработчиков составляет подробные задания и оценивает сложность наиболее важных историй. Затем эта же команда выбирает определенное количество историй, которые она обязуется выполнить за спринт. Из этих историй и плана их выполнения складывается бэклог спринта.
Добавьте оценки сложности, выраженные в очках, к историям. Для этого нужно ввести число в поле Story Point Estimate (Оценка сложности в очках). К историям можно добавить дополнительную информацию. Кроме того, можно нажать значок Create Subtask (Создать подзадачу), чтобы разбить работу над историей на еще более мелкие составляющие.
Закончив с этим, перетащите истории, которые были выбраны на собрании по планированию спринта, в только что созданный спринт. Теперь это бэклог вашего спринта.
Состав участников: (обязательно) команда разработчиков, Scrum-мастер, владелец продукта.
Когда проходит: в начале спринта.
Продолжительность: как правило, два часа на каждую неделю итерации. То есть двухнедельный спринт нужно начинать с четырехчасового собрания по планированию. Собрание заканчивается, когда достигнуты все его цели.
Назначение: планирование работы в спринте. Команда согласует цель спринта и бэклог спринта.
При создании спринта владелец продукта обычно определяет цель спринта. Она задает тему для работы, которую планируется выполнить в ходе спринта. Цель спринта также дает определенную свободу в выборе историй, которые нужно выполнить за спринт. Спринт считается законченным успешно, если достигнута его цель.
При традиционном подходе команды разработчиков ПО оценивают сложность работы во временном исчислении: дни, недели, месяцы.
Многие agile-команды, напротив, предпочитают оценку сложности в очках. С их помощью можно оценить относительные трудозатраты по шкале, напоминающей последовательность Фибоначчи (0, 0,5, 1, 2, 3, 5, 8, 13, 20, 40, 100).
Оценки помогают рассчитать, какой объем работы следует добавить в следующий спринт в зависимости от размера команды. Пройдет несколько спринтов, и ваша команда сможет точнее определять объем работы, который она способна выполнить за каждый спринт, чтобы не брать на себя непосильные задачи.
Шаг 5. Начало спринта в Jira
Назовите спринт. Некоторые команды выбирают название спринта, отталкиваясь от его цели. Если между задачами в спринте есть что-то общее, выберите название, связанное с этой темой. Вы можете назвать спринт как угодно.
Укажите продолжительность спринта, дату его начала и дату завершения. Эти даты должны быть выбраны в соответствии с графиком работы команды. Например, некоторые команды начинают спринты в понедельник, а завершают их утром в пятницу на следующей неделе. Другие команды предпочитают начинать и заканчивать спринты в середине недели. Решать вам! Если вы не можете сказать точно, сколько должен продолжаться ваш спринт, рекомендуем выбрать две недели.
Добавьте цель спринта, которая была согласована на собрании по планированию спринта.
После начала спринта откроется вкладка Active sprints (Активные спринты) проекта.
В этой вкладке ваша команда будет работать: брать элементы из столбца To do (Предстоит сделать) и переносить их в столбец In Progress (В процессе), а потом и в столбец Done (Завершено).
Если вы используете шаблон команды Scrum, вкладка будет называться Board (Доска).
Шаг 6. Проведение ежедневных стендапов
Когда спринт начнется, проводите совещания для своей команды каждый день (как правило, по утрам), чтобы узнать, кто над чем работает. Такие совещания помогают узнать, не столкнулся ли кто-то из команды с трудностями при выполнении заданий спринта.
Состав участников (основной): команда разработчиков
Когда проходит: раз в день, как правило, утром
Продолжительность: не более 15 минут. Не занимайте конференц-зал и не давайте участникам стендапа садиться. Если все будут стоять, собрание не займет много времени.
Назначение: ежедневный стендап проводится, чтобы быстро сообщить всем о делах в команде и спланировать работу на день. Это не полноценная планерка. Мероприятие должно быть легким и непринужденным, но информативным. Пусть каждый участник команды ответит на следующие вопросы.
- «Что мне удалось завершить вчера?»
- «Над чем я буду работать сегодня?»
- «Есть ли препятствия в моей работе?»
Когда отчитываешься о том, что было сделано вчера, перед своими коллегами, проявляется личная ответственность. Никто не хочет оказаться участником команды, который постоянно делает одно и то же и не движется вперед.
Подсказка. В некоторых командах используют таймеры, чтобы заканчивать вовремя. Другие бросают друг другу мячик, чтобы никто не выключался из обсуждения. Многие команды, участники которых находятся в разных городах, устраивают сеансы видеоконференции или группового чата, чтобы преодолеть разрозненность. Ваша команда уникальна, а значит, ваш стендап должен быть таким же!
Во время ежедневного стендапа можно обращаться к активным спринтам на доске Scrum, чтобы все участники видели задания, над которыми они работают.
Шаг 7. Просмотр диаграммы Burndown
Во время спринта рекомендуется сверяться с диаграммой Burndown. В Jira на такой диаграмме показан объем работы, фактически выполненный в ходе спринта, и плановый объем работы. Jira автоматически обновляет диаграмму Burndown по мере завершения рабочих задач. Чтобы просмотреть эту диаграмму, нажмите Reports (Отчеты) на боковой панели и выберите Burndown Chart (Диаграмма Burndown) из раскрывающегося списка отчетов.
На диаграмме Burndown показан объем работы, фактически выполненный в ходе спринта, и плановый объем работы. Горизонтальная ось x диаграммы отражает время, а вертикальная ось y обычно отражает сложность истории в очках.
С помощью диаграммы Burndown отслеживайте, какой объем работы осталось выполнить до конца спринта и с какой вероятностью будет достигнута цель спринта. Отслеживая изменения в объеме работы на протяжении итерации, команда сможет регулировать прогресс и вносить корректировки в свой график.
- Команда постоянно завершает спринты раньше срока, потому что берет на себя недостаточно работы.
- Команда постоянно не выполняет спринты в срок, потому что берет на себя слишком много работы.
- В линии диаграммы Burndown прослеживаются резкие спады вместо плавного снижения, потому что работа не была разбита на мелкие составляющие.
- Владелец продукта меняет объем работы посреди спринта.
Шаг 8. Просмотр отчета по спринту
Чтобы проанализировать спринт, вы можете в любой его момент или после него просмотреть отчет по спринту.
Отчет по спринту содержит диаграмму Burndown и перечень выполненных задач, невыполненных задач и всей работы, которая была добавлена после начала спринта.
Шаг 9. Проведение собрания по итогам спринта
The sprint review, or sprint demo, is a sharing meeting where the team shows what they've shipped in that sprint. Each sprint usually produces a working part of the product called an increment.
На этом собрании участники подробно рассказывают о проекте. Проводится также сеанс мозгового штурма, чтобы решить, что делать далее.
Состав участников (основной): команда разработчиков, scrum-мастер, владелец продукта.
Необязательно: заинтересованные лица
Когда проходит: как правило, в последний день спринта
Продолжительность: как правило, два часа для двухнедельного спринта
Назначение: изучение этапа работы и совместное обновление бэклога продукта.
Вопросы, которые нужно задать:
- «Выполнила ли команда план по спринту?»
- «Имело ли место добавление (удаление) задач в ходе спринта?»
- «Осталась ли работа, которую не удалось завершить в течение спринта?»
- Если да, то почему?»
Шаг 10. Проведение ретроспективы спринта
После завершения спринта команде следует провести ретроспективу. Зафиксируйте ход и результаты ретроспективы документально. Почему бы не в Confluence?
Состав участников: команда разработчиков, scrum-мастер, владелец продукта.
Когда проходит: в конце итерации.
Продолжительность: как правило, 90 минут для двухнедельного спринта.
Назначение: команда проверяет саму себя, в том числе процессы, инструменты и командное взаимодействие. Зачастую в бэклог следующего спринта добавляются задачи на усовершенствование.
Ретроспективы — это не только время для накопленных жалоб. Ретроспективы помогают определить, что работает (и пусть команда продолжит сосредоточиваться на этих аспектах), а что нет (уделите время поиску нестандартных решений и разработке плана действий). Постоянное совершенствование — это опора и движущая сила развития в agile-компании, и ретроспективы играют в нем ключевую роль.
Вопросы, которые нужно задать:
- «Что нам удалось сделать хорошо в ходе спринта?»
- «Что мы могли сделать лучше?»
- «Что мы сделаем лучше в следующий раз?»
Подсказка. Даже если у команды все складывается хорошо, не переставайте проводить ретроспективы. Через ретроспективы команда получает актуальные указания, как сделать так, чтобы успех сохранился.
Шаг 11. Завершение спринта в Jira
В конце спринта необходимо завершить его.
Если какие-то задачи в спринте остались незавершенными, можно сделать следующее.
- Переместить задачи в бэклог.
- Переместить задачи в будущий спринт.
- Переместить задачи в новый спринт, который для вас создаст Jira.
Шаг 12. Повторение шагов, начиная с шага 2
Сейчас у вас есть базовая информация о том, как составлять бэклог с помощью пользовательских историй, упорядочивать пользовательские истории в спринты, начинать спринт и проводить scrum-собрания. Вы можете решить, подходит это вашей команде или же требуется углубить знания.
Когда команда выполнит приведенные выше инструкции, можно приступить к изучению более сложного материала: «Применение расширенных методик Scrum с помощью Jira».
