Обзор Agile SCRUM

Основные методы управления проектами в IT-разработке

В IT разработке существует несколько методов управления проектами:

Code & FX

Самый простой и распространенный способ управления. Используется для работы со штатной командой в in-house разработке. Заказчик приходит к разработчикам, рассказывает про свою идею «на пальцах», после чего команда приступает к реализацию идеи.

Плюсы:

  • Минимальные трудозатраты менеджера и требования к его компетенциям
  • Цель проекта в итоге достигается

Минусы:

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

Каскадная водопадная модель (Waterfall)

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

Плюсы:

  • Отсутствие переработок в процессе
  • Конкретные рамки параметров проекта

Минусы:

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

Гибкая итеративная разработка (Agile)

Заказчик или Product Manager создаёт концепцию, в которой в общих чертах описано, какой продукт нужен пользователю. Команда выполняет работу короткими итерациями длительностью 1-3 недели. По итогам каждой итерации собирается обратная связь для корректировки движения. При этом на каждый участок есть четкий, понятный, продуманный план, по которому мы движемся.

Плюсы:

  • Быстрая реакция на все изменения
  • Намного меньше переработок, чем в других методиках
  • Высокое качество продукта

Минусы:

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

Итеративность и инкрементальность

В теории

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

На практике

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

Итеративная, инкрементальная Главная страница сайта, которая опубликована в интернете и доступна конечному пользователю
Итеративная, не инкрементальная Дизайн главной страницы сайта; Прототипы всех страниц сайта
Не итеративная, не инкрементальная Делаем ТЗ, спустя полгода показываем готовый сайт

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

  • Люди и взаимодействия важнее, чем инструменты
  • Работающий код важнее совершенной документации (работающий продукт, создающий ценность важнее качественного ТЗ)
  • Сотрудничество с Заказчиком важнее контрактных обязательств (контракт должен учитывать эффективное сотрудничество с Заказчиком)
  • Реакция на изменения важнее следования по плану (не означает отсутствие плана, значит лишь то что план должен быть такой, чтобы учитывать эти изменения)

Суть agile-подхода изложена в «манифесте», но для заказчика ее можно коротко сформулировать так:

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

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

См. также: Manifesto for Agile Software Development

Что такое Scrum?

Scrum — это одна из нескольких методологий гибкой разработки ПО:

  • Scrum
  • Lean
  • Feature Driving Development
  • Extreme Programming

Почему появился Agile

История возникновения этого подхода стала ответом на запросы отрасли:

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

Заказчик не может сформировать четкие требования к ПО

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

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

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

В традиционных «водопадных» моделях руководитель проекта минимизирует изменения в проекте, используя для этого отдельные процессы — управление изменениями. Но если требования будут меняться раз в месяц, то управление изменениями становится трудоемким и замедляет ход проекта.

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

Новые технологии усилили конкуренцию и потребовали оперативного применения в бизнесе

К середине 90-х разрабатываемое ПО было в основном десктопным и его требовалось устанавливать на каждый отдельный компьютер (например, MS Word). С появлением веб-приложений внедрение новой функциональности стало происходить быстрее: требовалось развернуть приложение на сервере и все пользователи получали к нему доступ. Эта инновация серьезно усилила конкуренцию между компаниями: тот, кто применил новую технологию раньше других – выигрывает рынок и клиентов.

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

Заказчики и разработчики не удовлетворены процессом взаимодействия

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

Основная идея agile – сотрудничество с заказчиком важнее, чем контрактные обязательства. И поэтому agile-методы стремятся к уменьшению объема документации. Это позволяет Заказчику платить только за результат, имеющий ценность для бизнеса.

При этом agile не отказывается от формулирования требований. Заказчик (в agile — владелец продукта, product owner) предъявляет требования в упрощенном виде и на сценариях работы пользователей.

Артефакты в Scrum

В скрам используется четыре артефакта:

  • Product Backlog,
  • Sprint Backlog,
  • Sprint Goal,
  • Sprint Burndown Chart.

Product Backlog

  • Это список всех требований, которые нужно сделать по проекту. Когда в Backlog’e нет требований, проект считается завершенным.
  • Все требования описаны по единому шаблону, который называют User Story (пользовательская история).
  • Требования составлены так, что очевидно и понятно, какую ценность они представляют для пользователя
  • Требования отсортированы по приоритетам, которые пересматриваются каждый спринт.

Состав бэклога:

  • User Story — то, что нужно пользователю и создает для него ценность
  • Technical Story — не несет ценности для пользователя, но нужно реализовать. Элементы работоспособности системы и напрямую не связаны с задачами конечного пользователя.
  • Technical Debt — то, что нужно сделать разработку более эффективной (автоматизация, реинжениринг, документация)
  • Bugs — задачи по исправлению ошибок

См.также:

Sprint Backlog

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

Sprint Backlog — это обязательство команды: что они должны выполнить за ближайшие 2 недели. Каждое требование разделено на задачи, которые представлены на Kanban-доске.

Sprint Goal

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

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

 

Sprint Burndown Chart

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

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

Burndown диаграмма в Jira

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

 

Роли в Scrum

В скрам используется всего три роли:

  • Product Owner
  • Scrum Master
  • Team

Роль Product Owner

  • формулирует требования
  • приоритезирует требования
  • корректирует приоритеты на каждом спринте
  • несет персональную ответственность за ценность требований для рынка/пользователей
  • отвечает за взаимодействие с рынком
  • только один человек
  • концепция, Vision: отвечает за ценность проделываемой командой работы
  • backlog: отвечает за прозрачность и ясность бэклога для команды
  • несёт ответственность перед заинтересованными лицами
  • координирует требования заинтересованных лиц, рынка, технологий

Product Owner — это представитель подразделения, которое владеет разрабатываемым продуктом. Например в банке это может быть Департамент карточных продуктов. Правильно определить Product Ownera не просто, т.к. эта роль требует сочетания следующих качеств:

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

В некоторых случаях допустимо назначить более одного человека на роль Product Owner. Но в этом случае необходимо назначить среди них «главного», который будет авторизовать требования в бэклоге и лично расставлять приоритеты.

 

Роль Scrum Master

  • следит за корректным применением принципов Agile и процессов (ритуалов) Scrum
  • организует работу команды и обеспечивает её всем необходимым
  • защищает команду, несёт ответственность за её эффективность
  • только один человек Scrummaster
  • cоздаёт атмосферу доверия
  • модератор встреч
  • устраняет препятствия
  • отвечает за следование командой принципам и практике SCRUM
  • учит команду
  • помогает команде стать самоорганизующейся

В классическом project management есть Руководитель проекта. В Scrum такая роль не предусмотрена. Лучшим синонимом роли Scrum Master будет «администратор». Скрам Мастер организовывает работу команды проекта, но не вмешивается в её работу.

  • Скрам мастер не назначает людей на задачи — это делает сама команда;
  • Мастер не заставляет людей делать работу — это ответственность команды;
  • Мастер не указывает Product Owner какие требования он должен написать — это работа владельца продукта.

Тем не менее, если скрам-процесс проходит с нарушениями (кто-либо из команды опаздывает на daily-meeting), то мастер должен вмешаться и исправить ситуацию.

 

Team (команда проекта)

  • кросс-функциональная
  • взаимозаменяемая
  • самоорганизующаяся
  • с фиксированным составом (в ходе спринта)
  • 4-10 человек
  • коллективное принятие решения и ответственность перед другими участниками команды
  • наличие общей цели
  • доверие и прозрачность действий

Команда отвечает за разработку продукта итерациями (спринтами). Команда определяет самостоятельно:

  • продолжительность спринта
  • емкость (capacity) команды
  • размер её фокус фактора (коэффициент слаженности)
  • трудоемкость требований, которые будут реализованы в спринте
  • очередность выполнения задач и много другое.

Команда НЕ принимает решений:

  • какие требования являются приоритетными — это делает Product Owner.

 

Ритуалы (процессы в Scrum)

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

Ритуалы в скрам это:

  • Sprint Planning Meeting
  • Daily Meeting
  • Sprint Review
  • Retrospective

Sprint Planning Meeting (встреча по планированию спринта)

  • выполняется всей командой перед началом спринта
  • команда выбирает требования из Product Backlog и формирует Sprint Backlog
  • если требуется учесть взаимосвязи между операциями, то это делается здесь
  • команда декомпозирует требования (requirements) на задачи (tasks)
  • каждая задача проходит оценку в трудозатратах или универсальных единицах
  • во время встречи Product Owner отвечает на вопросы команды.

Структура встречи:

  • представление и пояснение Product Owner’ом списка требований
  • вопросы со стороны команды
  • /рекомендуется перерыв/
  • декомпозиция требований на задачи (tasks)
  • оценка задач по методу Planning Poker.

Встреча простая по сути, но крайне сложная по содержанию. В начале проекта может занимать 5-6 часов. И только после 3-4 спринта встреча становится более оперативной и длится 2-3 часа.

 

Daily Meeting (ежедневная встреча команды)

Встреча проводится ежедневно. Основные принципы:

  • проходит ежедневно и только в одно и то же время;
  • встреча проходит только стоя;
  • поэтому длительность встречи не более 15 минут;
  • чтобы успеть каждый должен ответить всего на 3 вопроса: что я делал вчера, чем я занимаюсь сегодня, какие есть проблемы?

Цель митинга: поделиться информацией

  • Не предназначена для решения проблем, лишь для их выявления
  • Ведёт Scrum Master
  • Аудитория — команда
  • Все проблемы становятся видны сразу

Вопросы:

  • Что ты сделал вчера?
  • Что ты будешь делать сегодня?
  • Какие у тебя проблемы?

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

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

Встреча команды эффективно проводить напротив Kanban доски, на которой отражены все задачи спринта.

 

Sprint Review — сдача спринта Product Owner

По завершению каждого спринта команда обязана провести демонстрацию полученного результат. Ценность этого ритуала я поясню отдельно.

Ценность Scrum для обычного заказчика во многом состоит в том, что результат работ (плохой или отличный, не важно) будет продемонстрирован в любом случае. Это знает и команда и Product Owner и другие заинтересованные лица. Если команда не проводит демонстрацию (иное название Sprint Review), то это дискредитирует все преимущества гибких процессов.

Структура встречи:

  • команда зачитывает требования из Sprint Backlog
  • по каждому критерию приемки происходит демонстрация полученных результатов
  • каждый вопрос со стороны Product Owner’а записывается, чтобы иметь возможность ответить на них позже
  • каждое новое требование Product Owner’a выписывается, чтобы позже включить его в Product Backlog.

На встрече могут присутствовать любые сотрудники организации или просто заинтересованные лица. Важно, чтобы право голоса имели только участники Scrum процесса (Product Owner, Team, Scrum Master).

 

Retrospective

Ритуал, который направлен на обмен опытом внутри команды и конструктивное улучшение процесса разработки. Встреча проводится после Sprint Review. На встрече присутствует вся команда и Scrum Master. На встрече может присутствовать Product Owner, если считает нужным.

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

  • какие решения должна принять команда, чтобы сделать процесс более предсказуемым?
  • какие проблемы мешают команде выполнять взятые на себя обязательства?
  • как улучшить взаимодействие с Product Owner’ом?
  • какие ошибки совершает команда и почему.

Решения должны быть записаны на отдельной доске. После всеобщего голосования решения принимаются к исполнению со следующего спринта. Scrum Master контролирует ход встречи и следит за её регламентом.

Требования:

  • Предполагаем что все сделали всё возможное (без обвинений)
  • Не обсуждаем продукт, обсуждаем процесс

Рассказываем, чем занимались в итерацию:

  • Плюсы
  • Минусы
  • Проблемы
  • Решения

Пользовательские истории

Userstory

Не предписывает конкретных вариантов достижения цели и описывает кейс пользователя.

Шаблон для описания userstory:

«Я, как <роль> могу <цель> для того, чтобы <причина/результат>».

Примеры:

 

  • «Как менеджер, я могу видеть загрузку своих подчинённых, чтоб грамотно распределять задачи»

 

  • «Как менеджер по продажам, я хочу видеть всю информацию по клиенту, когда поступает звонок»

 

  • «Как интернет-маркетолог компании я хочу видеть внутри сайта статистику заходов на сайт по каждому источнику рекламы»

 

Feature

Описывает какое-либо готовое решение задачи пользователя и описывает способ реализации. Пример: «Как менеджер, я могу использовать отчет “Утилизация персонала” ».

Лучше формулировать требования в формате userstory, чтобы команда сама могла выбрать оптимальное решение с учетом своего опыта.

 

Task Board

В жизни реальных айтишников выглядит так:

 

Этапы в Scrum

  1. Product owner создаёт концепцию продукта. Описывает, какой продукт нужен пользователю. Результат описания фиксируется в бэклоге.
  2. Product owner создаёт Product Backlog. Список пользовательских историй (фич), упорядоченных по приоритету реализации.
  3. Product owner проводит встречу по планированию спринта. Встреча с заинтересованными лицами для определения самых приоритетных фич бэклога, которые мы забираем в разработку на ближайший период, например итерацию. Заинтересованные лица — команда, менеджер продукта, заказчик, инвестор и другие.
  4. Product owner формирует отобранный бэклог и формирует цели спринта. К примеру, топ 5-10 элементов на ближайший спринт. Команда декомпозирует требования (пользовательские истории, фичи) в задачи
  5. В течение спринта команда выполняет весь объем задач на спринт, который длится от 1 до 4-х недель. Каждые 24 часа в течение 10-15 минут Scrum Master проводит ежедневную встречу с командой проекта в одно и то же время.
  6. По завершению спринта Product owner демонстрирует заинтересованным лицам результаты спринта.
  7. Product owner проводит ретроспективу спринта с командой.
  8. Цикл из шагов 3 – 7 повторяется до тех пор, пока в бэклоге не останется требований. После этого проект считается завершенным.

Планирование в SCRUM

Планирование бэклога

  1. Собрать все заинтересованные стороны и попросить их представить все их идеи по продукту в виде юзерстори:
    1. Product Owner
    2. SCRUM Master
    3. Dev team
    4. Заказчик
    5. Инвестор
    6. Пользователь
    7. Маркетолог
    8. Продажник
    9. и других
  2. Собрать все юзерстори в одну карту (storymap)
  3. Оценить каждую юзерстори в условных единицах (инженерные дни или относительные единицы)

 

Рассчитываем Velocity

Velocity — фактическая скорость движения команды.

  1. Оцениваем каждую юзерстори из бэклога. В среднем, в бэклоге содержится от 50 до 100 юзерстори. Выбираем условные единицы, например человеко-днях. Оцениваем каждую юзерстори в условных единицах по методу «Покер планирования». Для этого Product Owner озвучивает описание требования, а каждый участник команды в ответ кладёт карточку с оценкой трудозатрат. Участники, которые показали самые высокие и самые низкие значения аргументируют свою позицию, после чего процедура голосования повторяется до тех пор, пока вся команда не придёт к средним значениям.
  2. Проходим 1 спринт и смотрим, сколько юзерстори удалось реализовать в условных единицах, по которым мы каждую из них оценили. Получаем Velocity — фактическую скорость команды.

Пример:

Команда: 5 человек

Длительность спринта: 10 рабочих дней

Средняя оценка юзерстори: 2 рабочих дня

План производительности команды: 5×10=50 человеко-дней

Факт выполненных юзерстори: 9 штук

Факт производительности команды: 9х2=18 человеко-дней

Velocity = 18 человеко-дней. Это фактическая скорость, с которой команда выполняет объем задач из бэклога в рамках спринта.

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

Пример, спринт 1: Юзерстори на 3, 5, 2, 1, 7 человеко-дней. Суммарно — 5 юзерстори на 18 человеко-дней.

Также мы можем рассчитать сроки завершения проекта:

Объем бэклога в юзерстори: 70 юзерстори

Средняя оценка юзерстори: 2 человеко-дня

Объем бэклога в идеальных человеко-днях: 140 человеко-дней

Команда: 5 человек

Планируемый срок: 28 рабочих дней

 

Длительность спринта: 10 рабочих дней

Velocity команды: 18 рабочих дней

Планируемый срок выполнения с учетом факта Velocity: (140×10)/18 = 77 рабочих дней

 

Условные единицы Velocity

  • В человеко-днях — каждый участник команды говорит оценку с учетом риcков
  • В идеальных инженерных днях — если никто не будет мешать и всё будет идеально
  • В стори-поинтах — берем самую простую юзерстори, в оценке которой все согласны, и назначаем её в качестве условной единицы. Например, мы знаем, что юзерстори «Я, как пользователь, хочу оставить заявку с почтой и телефоном через форму на сайте» занимает в среднем 2 часа. Мы назначаем эту юзерстори в качестве одной условной единицы и оцениваем все остальные юзерстори относительно неё. Таким образом, если интеграция с CRM-системой занимает в 5 раз больше времени разработчиков, её можно оценить как 5 сторипоинтов.

Release Chart

Burn Down

Шкала Y — Сторипоинты

Шкала X — Итерации

Пример:

Объем бэклога в сторипоинтах: 360

Velocity: 60 сторипоинтов за спринт

Длительность выполнения бэклога: 360/60=6 спринтов

Burn Up

Шкала Y — Сторипоинты

Шкала X — Итерации

Пример:

Объем бэклога в сторипоинтах: 100

Velocity: 6 сторипоинтов за спринт

Длительность выполнения бэклога: 100/6=16 спринтов

В процессе работы над проектом произошло 2 изменения:

 

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

 

  • Product Owner после одного из Sprint Review решил внести новые юзерстори в бэклог. Общий объем бэклога увеличился на 20%.

 

Все эти изменения были учтены в Release Burn Up Chart и исходя из этого мы узнали новую длительность выполнения бэклога.

Объем бэклога в сторипоинтах: 120

Velocity: 13 сторипоинтов за спринт

Длительность выполнения бэклога: 100/13=8 спринтов

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

Sprint Burndown Chart

Ежедневно ставим точку на графике с указанием оставшихся единиц работ (например человеко-часов). Если не успеваем — выкидываем самую низкоприоритетную фичу.

Планирование итераций

  • Product Owner предоставляет User Stories
  • Product Owner и команда формируют цель итерации
  • Команда оценивает или переоценивает User Stories
  • Команда декомпозирует их на технические задачи и оценивает их
  • В течение итерации требования не меняются. Добавить новые требования можно в бэклог и выполнить их в порядке приоритетов в следующих спринтах.

Материалы

  1. Manifesto for Agile Software Development
  2. SCRUM Wikipedia
  3. Agile/Scrum для начинающих. Что такое гибкая методология?
  4. Обратная сторона Agile
  5. Экстремальный аджайл — танцуют все!
  6. 6 Способов убить Agile
  7. Ещё раз про семь основных методологий разработки
  8. Все, что вы хотели знать о Scrum, но боялись спросить
  9. «Scrum. Революционный метод управления проектами». Книга за 15 минут
  10. Agile Board. Как мы планируем в Яндекс.Картинках и как к этому пришли