Вот мы все говорим, что работать по Agile классно, модно и молодежно. Но вот по факту, что дает методология? В чем выгода для команды, для бизнеса? В этой статье попробуем наглядно ответить на эти вопросы, расскажем о своем опыте и сравним два популярных подхода к организации работы.
Работа по Waterfall
Совсем краткий экскурс в историю: до того как появилась методология Agile, разработка IT-продуктов строилась по модели «Водопада», также известной как каскадная модель. Суть в том, что проект проходит все стадии только один раз. То есть сперва формируются требования от заказчика и формируется «макет» конечного продукта. На основе этого прогнозируются сроки и объем работ. Дальше команда разрабатывает, тестирует и поддерживает продукт.
То есть в самом начале своего пути вы придумываете какую-то тактику и придерживаетесь ее. На первый взгляд звучит неплохо, но есть нюансы.
|
Плюсы |
Минусы |
|
У вас есть четкий план от начала до конца проекта. |
Из-за строгой очередности стадий, процесс может занимать больше времени. Отдельные члены команды могут «простаивать». |
|
Команда готовит требования к проекту заранее, это экономит время.
|
Ошибку на стадии планирования можно обнаружить на стадиях воплощения и тестирования. Это может привести к откату к самому началу «водопада». Проще говоря, есть шанс, что придется вообще все переделывать. |
|
Каждая стадия требует результата, чтобы перейти на следующую. Из-за этого рабочий процесс более структурирован. |
Поскольку план проекта уже прописан от и до, отреагировать на изменения рынка становится практически невозможно. |
То есть успех напрямую зависит от стадии планирования. Не угадаешь с объемом работ, сроками или вообще концепцией проекта, шанс на провал возрастает. Недостаточно проанализируешь рынок — вся работа насмарку. А узнаешь ты об этом лишь на стадии реализации или вообще на релизе. И это при условии, что не будет внешних факторов.
Например, вы решили разработать приложение для вызова такси. Вы поняли, что у рынка есть запрос, это будет удобно и люди будут этим пользоваться. Классно, сформировали требования и начали разработку. Пока делали приложение, во всех машинах появился автопилот (ну представьте). А ваш продукт не умеет работать с такими авто и, получается, больше не нужен клиентам.
Это если мы все идеально спланировали. А что, если мы допустили оплошность в своих гипотезах?
Например, мы придумали фишку для нашего приложения: поиск машины за минуту. Действительно здорово, ведь клиентам нужно меньше ждать. Можно и маркетинг на этом построить. Когда приложение уже готово, оказывается, что время поиска действительно меньше минуты. Но достигается это за счет того, что система выбирает ближайшего свободного водителя, и зачастую он оказывается в нескольких километрах от клиента. Так что общее время ожидания машины не сократилось, а даже увеличилось. Незадача. Хуже всего, что это мы обнаружили только на релизе.
Отсутствие гибкости и невозможность что-то изменить в процессе разработки — главная проблема каскадной модели. Она работала на заре сферы IT, когда рынок не менялся так стремительно. Вероятно, до сих пор есть ситуации, когда модель «водопада» придется к месту. Например, при разработке по государственным грантам, когда сперва четко прописывается проектная заявка, а заказчик хочет быть вовлечен в процесс разработки.
Что меняет Agile
Методология Agile задумывалась, как ответ каскадной модели. Людям нужен был новый подход к разработке, который бы позволил легче реагировать на изменения в проекте. Поэтому в 2001 году 17 человек явили миру манифест Agile: 4 ценности и 12 принципов. Такой подход позволяет разбить крупный проект на этапы и превратить один марафон в несколько коротких спринтов, по итогу которых происходит оценка хода разработки. Если в каскадной модели разработка воспринимается как прямая линия, то в случае с Agile это скорее… Увлекательное приключение.
Цель каждого этапа — в итоге получить рабочий продукт или его часть. Это позволяет сфокусироваться на задачах, которые важны здесь и сейчас, а также координировать курс разработки по ходу. Общий бэклог продукта есть, но его разбивают на спринты.
|
Плюсы |
Минусы |
|
Короткий горизонт планирования помогает быть эффективным и продуктивным. Ведь результат работы не где-то далеко, а гораздо ближе: в конце спринта. |
В Agile в проект вовлечен также заказчик, и без его обратной связи разработка будет менее продуктивна. Клиент должен быть частью рабочего процесса. Если он этого не хочет, на выходе может получиться не тот продукт, который он ожидал. |
|
Гибкий подход позволяет изменить направление проекта в любой момент и поощряет эксперименты.
|
Между отделами может возникнуть рассинхронизация. |
|
Подход ориентирован на клиента. Это значит, что обратная связь от заказчика — это часть рабочего процесса. При должной вовлеченности клиента он получит в точности тот проект, что хочет. Даже если в начале разработки он виделся ему другим. |
Сложно определить время на разработку. Сроки могут сдвинуться в любой момент. |
Как это все выглядит на практике. Вернемся к примеру с приложением такси, но теперь мы его разрабатываем по Agile.
Вы выпустили первую версию, работа еще ведется, но пользоваться продуктом уже можно. Обратная связь от пользователей не слишком хорошая: им не нравится, что нельзя заказать такси ко времени. Команда собирается и решает добавить такую функцию, поэтому появляются дополнительные задачи и новый спринт. Это увеличит срок разработки, но итоговый продукт больше понравится пользователям и заказчику.
Также Agile поощряет в команде самостоятельность. Сотрудники больше вовлечены в работу, потому что видят, что могут повлиять на вектор развития проекта. В их глазах это не просто заказ от клиента, они все вместе работают, чтобы создать что-то классное. Но у этого есть оборотная сторона: в команде должны быть профессионалы, иначе результат экспериментов может увести проект не в ту сторону. Да и в целом руководителю будет сложно полностью доверять неопытным сотрудникам.
Например, ваш разработчик Николай подумал, что было бы здорово сделать более подробные карточки водителей. Он посчитал, что клиенту будет комфортнее ехать с тем, о ком он что-то знает. В итоге функцией не пользуются ни пользователи, ни водители. Эксперимент есть, толку нет.
Прямое сравнение Agile и каскадной модели
|
|
Каскадная модель |
Agile |
|
Временные рамки |
Сроки обговариваются в самом начале. |
Сложно спрогнозировать и могут сдвигаться в ходе разработки. |
|
Бюджет
|
Фиксированный изначально. |
Адаптивный. В зависимости от изменения сроков или видения конечного продукта бюджет может увеличиться или уменьшиться. |
|
Гибкость |
Адаптироваться по ходу не получится. Если что-то пошло не так на одной из стадий, проект откатывается на начало. |
Как и следует из названия, гибкие методологии позволяют реагировать на изменения изнутри и извне. |
|
Вовлеченность заказчика |
Клиент составляет требования к конечному продукту на первых стадиях разработки. После этого обратная связь от заказчика не требуется. |
Заказчик должен быть частью проекта, давать обратную связь и корректировать ход развития. |
Таким образом, ситуации, когда Agile не подойдет проекту, есть. Например, когда есть строгий дедлайн или заказчик не готов вовлекаться в разработку. Однако в большинстве случаев используют гибкие методологии, так как они позволяют лучше реагировать на изменения и выпустить востребованный продукт.
Для работы по Agile вам потребуется система управления проектами. Попробуйте платформу Аспро.Agile бесплатно.
