Размер шрифта
Цвет фона и шрифта
Изображения
Озвучивание текста
Обычная версия сайта
Российская платформа управления
проектами по принципам Agile
+7 (800) 101-08-31
+7 (800) 101-08-31
Заказать звонок
E-mail
c@aspro.ru
Адрес
454021, г. Челябинск, ул. Молодогвардейцев, 31, 8 этаж
Режим работы
Пн. – Пт.: с 9:00 до 18:00
Регистрация
Возможности
Кейсы
Блог
Тарифы
Контакты
Возможности
Кейсы
Решения
  • Для маркетологов
  • Для команд на удаленке
  • Для IT-разработки
  • Для ВУЗов
Тарифы
Блог
    +7 (800) 101-08-31
    Войти
    Регистрация
    Возможности
    Кейсы
    Решения
    • Для маркетологов
    • Для команд на удаленке
    • Для IT-разработки
    • Для ВУЗов
    Тарифы
    Блог
      +7 (800) 101-08-31
      Войти
      Регистрация
      Телефоны
      +7 (800) 101-08-31
      Заказать звонок
      E-mail
      c@aspro.ru
      Адрес
      454021, г. Челябинск, ул. Молодогвардейцев, 31, 8 этаж
      Режим работы
      Пн. – Пт.: с 9:00 до 18:00
      • Возможности
      • Кейсы
      • Решения
        • Решения
        • Для маркетологов
        • Для команд на удаленке
        • Для IT-разработки
        • Для ВУЗов
      • Тарифы
      • Блог
      Войти
      Регистрация
      • +7 (800) 101-08-31
        • Телефоны
        • +7 (800) 101-08-31
      • 454021, г. Челябинск, ул. Молодогвардейцев, 31, 8 этаж
      • c@aspro.ru
      • Пн. – Пт.: с 9:00 до 18:00

      Agile-подход: почему он появился

      Главная
      —
      Блог
      —
      Статьи
      —Agile-подход: почему он появился
      27 сентября 2022

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

      Работа по Waterfall

      Совсем краткий экскурс в историю: до того как появилась методология Agile, разработка IT-продуктов строилась по модели «Водопада», также известной как каскадная модель. Суть в том, что проект проходит все стадии только один раз. То есть сперва формируются требования от заказчика и формируется «макет» конечного продукта. На основе этого прогнозируются сроки и объем работ. Дальше команда разрабатывает, тестирует и поддерживает продукт.

      Гибкие методологии и метод Водопада: отличия

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

      Плюсы

      Минусы

      У вас есть четкий план от начала до конца проекта.

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

      Команда готовит требования к проекту заранее, это экономит время.

      Ошибку на стадии планирования можно обнаружить на стадиях воплощения и тестирования. Это может привести к откату к самому началу «водопада». Проще говоря, есть шанс, что придется вообще все переделывать.

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

      Поскольку план проекта уже прописан от и до, отреагировать на изменения рынка становится практически невозможно. 

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

      Например, вы решили разработать приложение для вызова такси. Вы поняли, что у рынка есть запрос, это будет удобно и люди будут этим пользоваться. Классно, сформировали требования и начали разработку. Пока делали приложение, во всех машинах появился автопилот (ну представьте). А ваш продукт не умеет работать с такими авто и, получается, больше не нужен клиентам.

      Это если мы все идеально спланировали. А что, если мы допустили оплошность в своих гипотезах? 

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

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

      Что меняет Agile

      Методология Agile задумывалась, как ответ каскадной модели. Людям нужен был новый подход к разработке, который бы позволил легче реагировать на изменения в проекте. Поэтому в 2001 году 17 человек явили миру манифест Agile: 4 ценности и 12 принципов. Такой подход позволяет разбить крупный проект на этапы и превратить один марафон в несколько коротких спринтов, по итогу которых происходит оценка хода разработки. Если в каскадной модели разработка воспринимается как прямая линия, то в случае с Agile это скорее… Увлекательное приключение.

      В разработке не всегда все идет по плану

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

      SCRUM Framework этапы работы

      Плюсы

      Минусы

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

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

      Гибкий подход позволяет изменить направление проекта в любой момент и поощряет эксперименты.

      Между отделами может возникнуть рассинхронизация. 

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

      Сложно определить время на разработку. Сроки могут сдвинуться в любой момент.

      Как это все выглядит на практике. Вернемся к примеру с приложением такси, но теперь мы его разрабатываем по Agile.

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

      Также Agile поощряет в команде самостоятельность. Сотрудники больше вовлечены в работу, потому что видят, что могут повлиять на вектор развития проекта. В их глазах это не просто заказ от клиента, они все вместе работают, чтобы создать что-то классное. Но у этого есть оборотная сторона: в команде должны быть профессионалы, иначе результат экспериментов может увести проект не в ту сторону. Да и в целом руководителю будет сложно полностью доверять неопытным сотрудникам.

      Например, ваш разработчик Николай подумал, что было бы здорово сделать более подробные карточки водителей. Он посчитал, что клиенту будет комфортнее ехать с тем, о ком он что-то знает. В итоге функцией не пользуются ни пользователи, ни водители. Эксперимент есть, толку нет.

      Прямое сравнение Agile и каскадной модели


      Каскадная модель

      Agile

      Временные рамки

      Сроки обговариваются в самом начале.

      Сложно спрогнозировать и могут сдвигаться в ходе разработки.

      Бюджет

      Фиксированный изначально.

      Адаптивный. В зависимости от изменения сроков или видения конечного продукта бюджет может увеличиться или уменьшиться.

      Гибкость

      Адаптироваться по ходу не получится. Если что-то пошло не так на одной из стадий, проект откатывается на начало.

      Как и следует из названия, гибкие методологии позволяют реагировать на изменения изнутри и извне.

      Вовлеченность заказчика

      Клиент составляет требования к конечному продукту на первых стадиях разработки. После этого обратная связь от заказчика не требуется.

      Заказчик должен быть частью проекта, давать обратную связь и корректировать ход развития.

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

      Для работы по Agile вам потребуется система управления проектами. Попробуйте платформу Аспро.Agile бесплатно.


      Попробовать Аспро.Agile

      Статьи
      Статьи
      16 сентября 2022
      Зачем нужна доска с задачами?
      Почему так важно визуализировать рабочие процессы?
      Статьи
      15 июля 2022
      Полезные книги по управлению продуктом
      Подборка полезных книг, которые помогут вам прокачать скиллы менеджмента продукта.
      Назад к списку
      • Обновления 22
      • Статьи 32
      • Видео 26
      • СМИ о нас 1
      Возможности
      Кейсы
      Блог
      Контакты
      Документация
      API
      Сравнение сервисов
      Реферальная программа
      Реквизиты
      +7 (800) 101-08-31
      +7 (800) 101-08-31
      Заказать звонок
      E-mail
      c@aspro.ru
      Адрес
      454021, г. Челябинск, ул. Молодогвардейцев, 31, 8 этаж
      Режим работы
      Пн. – Пт.: с 9:00 до 18:00
      c@aspro.ru
      © 2025 Аспро.Agile
      Лицензионное соглашение Политика конфиденциальности
      Главная Кейсы Блог Тарифы