Agile и Scrum для начинающих: как устроено гибкое управление проектами в ИТ

В менеджменте проектов исторически существовало два основных подхода: методология управления проектами Waterfall (каскад) и подход к управлению разработкой V-Model.

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

Описание такой последовательной модели в 1970 году опубликовал инженер Уинстон Ройс, а название Waterfall, в переводе «водопад», за ней закрепилось позже. V-Model сформировалась в 1980-е годы как развитие Waterfall. Позже её закрепили и на уровне стандартов: например, в Германии в 1992 году на её основе приняли стандарт V-Modell для государственных проектов.

Сегодня классические подходы всё ещё хорошо работают там, где требования известны заранее и не меняются. Посмотрим, как устроены эти подходы.

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

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

Это не значит, что в ИТ Waterfall не используют. Он остаётся рабочим выбором, когда заказчик точно знает, что ему нужно, а требования не будут меняться в ходе проекта. Типичный случай — импортозамещение: есть зарубежная программа, которую нужно переписать и перенести на другую платформу. Функциональность остаётся прежней, меняется только платформа. Подробное техническое задание (ТЗ) и последовательные этапы позволяют заранее прописать все нюансы, оценить срок и бюджет, и для заказчика такой путь оказывается выгоднее, чем гибкая разработка.

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

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

Agile и Scrum часто путают и называют одинаково: методологией, фреймворком, подходом. Но это понятия разного уровня: одно задаёт общие ориентиры, другое — конкретные правила работы.

→ Agile — философия и семейство подходов. Это набор ценностей и принципов, которые задают ориентир. Следовать им буквально не нужно: команда сама решает, как их применять.

→ Scrum — фреймворк, метод работы внутри Agile, который описывает роли, события и правила. Ядро Scrum важно соблюдать: если убрать часть правил, получится уже не Scrum.

Весь Agile строится на коротких циклах и постоянной обратной связи. Его гибкость в том, что план можно менять после каждого цикла, не пересобирая весь проект. Предпосылки к появлению Agile были уже в 1990-х годах: тогда возникли Scrum, Extreme Programming и другие «лёгкие» методы, а в 2001 году их объединил Agile-манифест: документ, в котором 17 разработчиков сформулировали общие ценности и принципы гибкой разработки. Авторы предложили отказаться от одного большого релиза через год и разбить проект на короткие итерации, например, длительностью от одной до четырёх недель. Такая длительность принята для спринтов: так в Scrum называют итерации.

Команда берёт небольшую часть задач, объединенную общей целью, и к концу каждой итерации доводит её до полной готовности: разработка, тестирование, проверка и релиз для пользователей. Так получается инкремент — отдельно работающий кусочек продукта. Его показывают заказчикам или пользователям и, получив обратную связь, корректируют планы на следующий спринт. Например, в приложении системы лояльности инкрементом за один спринт может стать начисление баллов за покупку или шкала прогрессивной скидки в зависимости от суммы предыдущих покупок.

Ниже — сравнение классических подходов и Agile по пяти критериям:

Agile опирается на Agile-манифест, из которого вытекают 12 практических принципов (о них можно прочесть на странице манифеста), и на четыре ключевые ценности.

На ценности посмотрим подробнее: 

Если Agile — семейство подходов и философия («как мы мыслим»), то Scrum — фреймворк, который переводит Agile в практику: описывает роли, события и артефакты («что конкретно мы делаем по дням»). Scrum — самый популярный способ применения Agile в ИТ-командах.

Scrum строится на спринтах. Спринт — это фиксированный отрезок времени (обычно две недели), в течение которого команда берёт набор задач из общего списка, бэклога, и доводит их до готового состояния.

Scrum отказывается от традиционной иерархии «начальник — подчинённый». В scrum-команде нет должности «менеджер проекта» в привычном понимании. Вместо этого есть три роли: владелец продукта (Product Owner, PO), scrum-мастер (Scrum Master) и команда разработки (Developers).

Scrum отказывается от традиционной иерархии «начальник — подчинённый». В scrum-команде нет должности «менеджер проекта» в привычном понимании. Вместо этого есть три роли: владелец продукта (Product Owner, PO), scrum-мастер (Scrum Master) и команда разработки (Developers).

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

Главные задачи: общается с пользователями и стейкхолдерами, формирует видение продукта, ведёт и приоритезирует задачи. Только владелец продукта имеет право определять приоритет задач.

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

Главные задачи: убирает препятствия с пути разработчиков, защищает команду от несанкционированных задач посреди спринта.

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

Характеристики команды разработчиков:

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

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

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

Артефакты в Scrum — это конкретные элементы работы, которые обеспечивают прозрачность информации и единое понимание задач:

Вся работа scrum-команды циклична и вращается вокруг событий спринта:

Дальше — подробнее о каждом из пяти обязательных событий.

Контейнер для всех остальных событий. Длится от одной до четырёх недель. Частая практика в ИТ — две недели. Длительность спринтов фиксируется и не меняется от раза к разу. Длину выбирает scrum-команда вместе с владельцем продукта. Опираются на два фактора: как быстро бизнесу нужны новые инкременты и сколько времени команде реально требуется, чтобы довести задачи до готовности. Чем быстрее меняются требования и чем быстрее нужен работающий инкремент, тем короче спринт.

Планирование начинается заранее, с груминга (Backlog Refinement). Это нерегламентированная часть планирования: Scrum не задаёт для неё ни времени, ни формата. Часто груминг проводят в середине спринта, чтобы подготовить задачи к следующему. Команда совместно с владельцем продукта уточняет требования, добавляет или удаляет задачи в бэклоге, разбивает крупные задачи на мелкие, оценивает их сложность и упорядочивает бэклог.

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

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

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

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

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

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

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

Как избежать: определить, какую проблему команда вообще пытается решить — долгий вывод продукта на рынок (высокий time-to-market), хаотичную смену приоритетов, отсутствие прозрачности, плохую обратную связь от пользователей и так далее. Затем договориться, какие решения команда может принимать самостоятельно и что действительно можно менять по итогам спринта.

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

Как избежать: защищать не неизменность списка задач, а цель спринта (Sprint Goal). Если появляется новая работа, нужно понять, мешает ли она цели спринта, можно ли заменить менее важную задачу, действительно ли ситуация критичная. Для срочных задач лучше заранее договориться об отдельном процессе. Самый частый пример — инциденты на проде, то есть в версии продукта, которой уже пользуются клиенты. На такие случаи можно оставлять в спринте запас рабочего времени или назначать дежурного инженера.

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

Как избежать: использовать баллы и скорость только для планирования спринтов. Эффективность оценивать по другим показателям:

• lead time: сколько времени проходит от появления задачи до её готовности;
• cycle time: сколько времени проходит от начала работы над задачей до её готовности;
• predictability, или предсказуемость: насколько команда выполняет то, что запланировала;
• качество;
• количество инцидентов на проде;
• достижение продуктовых результатов.

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

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

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

Как избежать: заканчивать каждую ретроспективу договорённостью об одном-трёх конкретных действиях на следующий спринт. Не «улучшить коммуникацию», а «с понедельника все задачи крупнее пяти дней декомпозируем во время груминга». У каждого действия должен быть ответственный, а на следующей ретроспективе команда проверяет, что получилось.

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