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

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

Чтобы построить взаимодействие правильно, избежать недопонимания, лишней траты времени и бюджета, существуют гибкие методологии — скрам (Scrum), канбан (Kanban) и принцип работы, который их объединяет — эджайл (Agile). О них наша статья.

Классическое управление проектами, которое ещё называют «водопадным» или «каскадным», выглядит логично: сначала собираем все требования, потом проектируем, разрабатываем, тестируем, сдаём.

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

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

Скрам (Scrum)

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

В ПРАЙ мы чаще всего работаем по Scrum, так как это удобно, эффективно, позволяет быстро менять стратегию, пересматривая задачи на грядущий спринт. 

Также Scrum идеально подходит, когда:

• требования к продукту будут уточняться по ходу работы;

• заказчик готов активно участвовать в процессе;

• проект новый и нестандартный;

• важно получать результат в процессе разработки, а не только в финале.

Канбан (Kanban) 

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

Kanban выручает, когда:

• нужна поддержка уже существующего продукта;

• задачи поступают непрерывно;

• нет смысла разбивать работу на спринты — нужна лишь прозрачность и управление очередью.

А как же классика?

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

Главный вопрос перед выбором подхода — насколько вы знаете, что хотите получить в конце? Если ответ «знаем точно», можно использовать классическую схему. Если «примерно понимаем, но будем уточнять», нужен Scrum или Kanban.

Много проблем возникает при разном понимании одних и тех же слов. «Удобный интерфейс», «быстрая загрузка», «современный дизайн» разработчик и клиент будут видеть по-своему.

Чтобы прийти к «общему знаменателю», важно использовать следующие практики. 

• Делаем короткие описания от лица пользователя вместо сухих технических требований. Формат простой: «Как [кто], я хочу [что], чтобы [зачем]». Например: «Как покупатель, я хочу видеть статус моего заказа в личном кабинете, чтобы не звонить в поддержку». 

• Заранее договариваемся, как понять, что задача сделана.

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

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

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

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

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

По итогам проекта заказчик остался доволен: 

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

• чётким пониманием его требований — так как клиент видел продукт на каждом шаге.

Scrum, Kanban — лишь инструменты, и они классно работают тогда, когда заказчик и команда честно друг с другом разговаривают. Когда можно открыто сказать, например: «Это не то, что я ожидал» или «Мы не уложимся в спринт». В такой атмосфере ошибки не превращаются в поиски виноватого, они помогают скорректировать курс.