Как использовать Agile и Scrum для управления проектами

Для чего внедрять гибкие методологии

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

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

Управление проектами в стиле Agile и Scrum — иной подход. В основе — итерации, небольшие задачи с минимумом функций. Можно разработать основные функции, запустить ПО и постепенно дополнять его.

Плюсы методологии:

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

Agile — это подход к разработке большого проекта. Философия, которая позволяет создавать продукт с постоянно меняющимися требованиями.

Начните с бэклога

Scrum — это метод управления проектами, он входит в философию Agile. Ключевое отличие от классической, водопадной схемы создания ПО заметно сразу — для начала разработки не нужно техническое задание.

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

Лайфхак — обратите внимание на столбец Приоритет на примере. Используйте не привычный список 1, 2, 3, 4. Попробуйте четырехзначные цифры — так вы сможете просто добавить строку между ними и выставить подходящий приоритет. Например, между 1 000 и 2 000 напишите 1 050.

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

Внедряйте спринты

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

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

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

Сделайте список версий продукта — от ПО с минимумом функций до полностью реализованного. Укажите к каждой версии прогноз по сроку выполнения.

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

Распределите роли в команде

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

К разработчикам есть несколько требований:

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

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

Контролируйте процессы

Диаграмма сгорания — это наглядная демонстрация того, как команда «переваривает» все задачи проекта. Красная линия — план. Синяя — то, что делает команда. Диаграмма обновляется каждый день. Вы сразу видите, когда есть отклонения от плана: можно спокойно «крутить гайки» или менять приоритеты в бэклоге.

Контролируйте работу команды с помощью двух scrum-показателей:

• Focus Factor — коэффициент, который показывает, сколько задача должна была выполняться по плану, а сколько вышло в итоге. Так оценивается «концентрация» команды над проектом.
• Velocity — производительность. Поможет спрогнозировать количество задач, которые команда сможет взять в следующем спринте — в зависимости от количества готовых тикетов в прошлом. Velocity = Focus Factor * Оценка новых задач.

Организуйте работу команды

В Scrum от сотрудников требуется минимальная отчетность. Каждый день человек должен ответить на три вопроса:

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

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

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

На следующей ретроспективе обсудите идеи из плана, отсортируйте их по категориям «плохо» и «хорошо». Повторите процесс — получается ретроспектива на ретроспективу.

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

Первый спринт команда всегда «факапит», потому что слишком оптимистично смотрит на дедлайны и задачи. Второй — берет очень мало задач и делает больше. Третий — снова плохая оценка, но уже чуточку лучше. Потом все выравнивается. Это рабочий процесс.

Демонстрируйте проект

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

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

Изучите инструменты для контроля

Работать по системе можно даже на бумаге. Отлично подходит и таблица в Google Docs. Создайте свою рабочую область вручную или попробуйте специальные сервисы:

• Trello — подходит для маленьких проектов, быстро и удобно.
• Scrumban — есть разные доски, вложенные задачи и подзадачи. Удобно для средних и маленьких проектов.
• Jira — есть версионность, удобно для больших и долгих задач. Поддерживает массу типов разработки. Попробуйте, она вам понравится.

Чек-лист — как начать использовать Agile и Scrum на проекте

• Научиться вести бэклог и расставлять приоритеты.
• Проводить спринты.
• Формировать стабильную и постоянную команду, решать трудности, растить внутри группы scrum-мастера.
• Контролировать работу с помощью диаграммы сгорания проекта.
• Организовать работу — каждый день интересоваться делами команды, проводить ретроспективу и закладывать время на тикет с запасом.
• После каждого спринта демонстрировать проект.
• Изучить инструменты и найти самый удобный.