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