Гибкие методы разработки

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

В основе всего Agile — манифест, который чётко формулирует основные ценности процессов:

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

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

Один из инструментов для эджайл (Agile) — это скрам (Scrum). Это фреймворк (framework) для реализации основных принципов гибкой разработки. 

Посмотрим, из чего он состоит, чтобы понять, как его применять. 

Как устроен скрам 

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

Доска — это список задач, распределённых по этапам. Она может быть виртуальной, как в нашем примере, или реальной: нарисованной на флипчарте и со стикерами.

У доски есть несколько колонок:

• бэклог (в нашем случае — need to rate, подробнее мы разберём его ниже);
• бэклог спринта (в нашем случае — to do, здесь уже оценённые задачи, которые можно брать в работу);
• in work (задачи, которые были взяты участниками команды);
• check (задачи, которые поехали на тест);
• done (сделанные задачи, которые уже доехали до продакшена).

У задач всегда есть исполнитель, который за них отвечает. Например, в Trello в карточке можно указать участника команды и уточнить, к какому направлению относится задача (например, фронтенд, бэкенд, дизайн и т. д.).

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

Бэклог (backlog) — список задач проекта. Они попадают туда от продакт-оунера (product owner), который приоритизирует их исходя из бизнес-целей, технического долга или пожеланий пользователей. Главное правило — один продакт-оунер на один бэклог.

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

Спринт (sprint) — это промежуток времени (месяц или меньше, например 2 недели), за который создаётся инкремент продукта.

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

Бэклог спринта — задачи, которые нужно выполнить в текущем спринте для достижения инкремента. Как задачки попадают сюда из бэклога, мы разберём чуть позже.

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

Помимо инструментов скрам чётко регламентирует роли в команде.

Участники команды — это исполнители: например, разработчики, дизайнеры, копирайтеры.

Скрам-мастер (Scrum master) — сердце и душа скрам-команды. Он помогает организовать основные процессы: планирование, ежедневные митинги, ретроспективы, следит за скрам-доской (но не за бэклогом, за который отвечает продакт-оунер). Также скрам-мастер, как правило, фасилитирует встречи, то есть следит за тем, чтобы участники не отходили от темы и чувствовали себя комфортно. В идеале задача скрам-мастера — организовать процесс таким образом, чтобы команда могла работать без него. Но на практике, к сожалению, это редко реализуется.

Продакт-оунер (product owner) — это владелец продукта. Он видит полную картину и отвечает за приоритизацию задач и ведение бэклога, иногда формулировку и детализацию, а также решает, какой инкремент будет у спринта в соответствии с планированием и ресурсами команды.

Церемонии, они же встречи

Перед каждой встречей заранее определяется её цель и участники.

Планирование — перед стартом спринта продакт-оунер обозначает цели (инкремент), и встреча проходит с фокусом на этом инкременте спринта. Команда оценивает задачи, например в сторипойнтах (Story Points). Сама оценка может происходить на этапе планирования или заранее, в рамках груминга (см. ниже). После оценки команде нужно понять, какие она берёт задачи для выполнения инкремента. Если это невозможно в рамках спринта, то продакт-оунер меняет инкремент или принимает решение об увеличении длительности спринта.

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

Митинги (стендапы) — ежедневная встреча, на которой команда разбирает текущие задачи, чтобы выявить проблемы в процессе. Длятся такие церемонии, как правило, 10–15 минут. Каждый участник рассказывает, что делал вчера и что планирует сегодня. Чаще митинги проводятся утром, но иногда команды их смещают на день или вечер. Такие встречи также фасилитирует скрам-мастер, чтобы участники чувствовали себя комфортно и встреча не затягивалась. Если, например, специалисты по бэкенду и фронтенду начинают детально обсуждать методы, то им предлагают назначить для этого разговора отдельную встречу.

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

Демо — показ инкремента за один спринт или несколько. Демо может быть внутренним, с участниками близких команд (чтобы все понимали, что делают коллеги), или внешним — перед заказчиком.

Когда полезен скрам

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

Скрам не подойдёт, когда не нужно ничего нового в процессах, а всё идёт по алгоритму. Например, мы делаем лендинги и процесс у нас выглядит так:

• брифинг,
• дизайн,
• контент,
• разработка.

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

Если вы решитесь внедрить скрам, то стоит знать о возможных сложностях:

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

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