Generated with Avocode. Generated with Avocode. Generated with Avocode. Generated with Avocode. Generated with Avocode. hat Generated with Avocode. Generated with Avocode. Generated with Avocode. Generated with Avocode. Generated with Avocode. Generated with Avocode. path40

Как создать план проекта в Scrum за 5 шагов

Любому проекту нужен план. Каким он будет, зависит от методологии, которую вы выберете. Сегодня говорим о гибких методологиях в управлении: как составить план проекта, если вы работаете по Scrum.

Это статья-кейс, где мы показали прикладное применение методологии, которую scrum-студия «Сибирикс» использует в digital-проектах.

Что нужно знать прежде, чем начать

Что такое план управления проектом

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

Кто готовит план управления проектом

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

Первый шаг. Выясняем требования

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

  1. Задаем вопросы, чтобы выяснить цели клиента: какие задачи он хочет решить с помощью продукта.
  2. Оцениваем общую ситуацию на рынке и конкурентов клиента.
  3. Выясняем целевую аудиторию и какие ее проблемы может решить продукт.

Второй шаг. Составляем структуру проекта

После первого шага у вас много информации. Ее настолько много, что разобраться в ней пока трудно. Что делать? Структурировать все данные. Так вы поймете, все ли понятно или остались невыясненные части.

  1. Используем mindmap.
  2. Группируем информацию: цели, задачи, ЦА продукта.
  3. Заносим в mindmap все, что узнали.
Пример оформления структуры проекта.

Третий шаг. Пишем техническое задание

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

Как выглядит бэклог продукта для интернет-магазина.

Пишем бэклог продукта.

1. Создаем Google-таблицу.
2. В столбец заносим базовые требования к продукту. Детали добавим в процессе работы.

Расставим приоритеты: чем важнее задача, тем больше число ей присваиваем и тем раньше мы приступим к ее выполнению. Например, «1» ― задача с минимальной важностью, «10 000» ― с максимальной. Пределы зависят только от сложности проекта и количества задач, но цифры не должны повторяться в рамках одного бэклога. Приоритеты зависят от важности требования для продукта.

3. Расставляем приоритеты.

В самом начале трудно спланировать, сколько часов займет какая задача, поэтому будем оценивать примерно, в условных единицах. Выбираем самую простую задачу, например, пусть будет «Форма обратной связи». Затраты на ее выполнение минимальны, то есть ставим «1». Остальные задачи оцениваем относительно первой. Сложность растет ― цифра тоже. У нас получилось, что самая сложная задача на данный момент — «Главная страница». Примерные затраты на ее выполнение ― шесть условных единиц.

4. В третьем столбце прописываем примерную оценку затрат команды.

По ходу работы меняем требования местами, если изменился приоритет.

5. Добавляем новые задачи. Если требование выполнено ― удаляем его из бэклога.

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

Важно!

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

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

Четвертый шаг. Делаем прототип

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

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

Пятый шаг. Планируем спринт

Весь процесс работы делим на равные отрезки, в Scrum они называются спринтами. Каждый длится две недели или месяц, зависит от типа проекта.

  1. Определяем цель спринта. Она должна быть реалистичной. Не ставьте цель, которую не сможете выполнить.
  2. Составляем бэклог. Задача Scrum ― создать продукт с минимальной функциональностью для быстрого запуска на рынок. Элементы бэклога спринта нужно сформулировать так, чтобы каждый член команды понимал задачу одинаково. Каждый элемент должен быть осуществимым, чтобы была реальная возможность внедрить его за один спринт.
  3. Оцениваем элементы спринта, чтобы понять сложность и трудоемкость, проще расставить приоритеты и прогнозировать ход проекта.
  4. Выполняем задачи спринта последовательно, учитывая приоритеты.
  5. По итогу каждого спринта оцениваем, что было сделано и достигнута ли цель: сколько задач решено и какие элементы готовы к использованию.
  6. Если есть сомнения по поводу какого-то элемента продукта, лучше запустить его как можно скорее и проверить в деле. Пользователи подскажут, как лучше.
Как выглядит процесс создания интернет-магазина при работе в Scrum.

Мы рассмотрели основные шаги, которые нужны, чтобы составить план проекта в Scrum. Но после составления плана работа только начинается. Дальше ― больше.

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

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

Курс «Управление Digital-проектами»
Курс поможет вам оценить себя как менеджера: разобраться и понять, почему у вас что-то не получается. Определить, какие навыки и знания нужно подтянуть. И сделать это, выполняя практические задания.
  • Живая обратная связь с преподавателями
  • Неограниченный доступ к материалам курса
  • Стажировка в компаниях-партнёрах
  • Дипломный проект от реального заказчика
  • Гарантия трудоустройства в компании-партнёры для выпускников, защитивших дипломные работы

Комментарии

3
Чтобы оставить комментарий,  авторизуйтесь
Василий Зорин
2 дня назад
Автору курса стоит прочитать Scrum Guide прежде чем начинать преподавать. Менеджер проекта в Scrum? Вы серьезно?

Теперь есть вопросы к качеству других курсов на Skillbox.
Andrew Kopanev
2 дня назад
И ведь кто-то купит курс, пройдет, будет применять передовую _методологию_ Scrum и за 5 шагов получать результат!
Alexey Evdokimov
2 дня назад
После фразы "В Scrum за план отвечает менеджер проекта" любой знающий Scrum человек читать статью не станет, но я все же прочитал, чтобы посмеяться.
Итог: если закрыть глаза на некорректную терминологию и неверные акценты (например, "создать план проекта" не может быть целью в Agile), то в статье действительно можно раскопать смысл Скрама, вполне корректный.
Но нехорошо так сильно запрятывать смысл ради SEO, а также выдавать за Скрам скрамоподобный подход Sibirix (который я уважаю, но он заточен под нужды исключительно заказной разработки, и это не совсем Scrum). Нехорошо, потому что новички могут воспринять такие статьи как будто это действительно Скрам описывается, примутся составлять mindmaps вместо живого общения и т.п.

Из смысловых некорректностей отмечу только одно:
"Оцениваем элементы спринта" - это относится НЕ к планированию спринта (хотя, конечно, можно что-то дооценить и на планировании). Для того, чтобы элементы бэклога продукта считались готовыми к планированию спринта, они должны быть оценены (для этого есть процесс уточнения бэклога продукта - backlog refinement). А главное - если у вас верхушка бэклога не оценена на несколько спринтов вперед, то вы не сможете построить release burndown chart (это одна из общепринятых практик, дополняющих Скрам) и тем самым спланировать срок релиза.
Alexey Evdokimov
Skillbox
1 день назад
Спасибо за то, что указали на неточности!

Мы действительно рассказали о прикладном применении Scrum в управлении заказной веб-разработкой. Некоторые термины сознательно упростили, чтобы набрать классов (зачеркнуто) облегчить чтение новичкам. Добавили пометку в статью, чтобы внести ясность.

Обзорная статья по Scrum и Agile есть в другом материале: https://skillbox.ru/media/management/kak_ponyat_scrum/
Хочешь получать крутые статьи по менеджменту?
Подпишись на рассылку

Skillbox