Agile в разработке. IT-подрядчик работает по гибкой методологии: чем это выгодно для заказчика?

Эффективно ли использовать Agile в разработке программного обеспечения?

Разбираемся в нюансах, плюсах для заказчика и разработчика, ценностях подхода Agile. Представьте, вы хотите заказать разработку интернет-магазина, сервиса или B2B-портала и выбираете подрядчика. У вас два претендента: IT-компании с похожим опытом.

Каждая со своими плюсами: технологии, команда...

Но одна из компаний заявляет преимущество: «Мы работаем по Agile!»

Что значит Agile для заказчика: больше прибыль?

Или больше проблем? Agile — это гибкий подход к разработке программного обеспечения.

Здесь работа разбивается на большое количество мелких этапов — спринтов.

Спринт может длиться от недели до месяца, и итогом каждого спринта является то, с чем клиент уже может работать — инкремент продукта (product increment). С таким подходом заказчику легко контролировать каждый этап работ, а результат получается максимально адаптированным к требованиям рынка.

Без Agile: заказчик не видит, что конкретно делают разработчики; готовый продукт, который так долго ждали, может разочаровать.

Если же прервать проект раньше, можно остаться ни с чем, ведь результат планировали получить в самом конце.

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

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

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

Это серьёзная проблема проектного подхода.

: в Agile нет проектов с конечными сроками; здесь во главе угла — продукт, и его можно улучшать «маленькими шагами» столько, сколько потребуется.

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

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

Это мотивирует делать код изначально красивым и в целом повышает мотивацию подрядчика.

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

Ежедневно проходят совещания — daily meeting.

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

Главный проектный риск — это невозврат инвестиций.

Главный способ этого не допустить — попасть в потребность конечного покупателя.

Без Agile: вы готовы несколько месяцев или даже лет тратить деньги на создание продукта, рентабельность которого под вопросом? Помним, что результат при классическом подходе будет виден только в конце. С Agile: фокус команды сразу направлен на цели бизнеса.

Чем чаще выходят новые версии, тем чаще мы получаем ответную реакцию пользователей и/или рынка и делаем всё, чтобы рентабельность росла.

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

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

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

Её создание встраивается в спринты как процесс разработки (должна быть документация по задаче — пишем) или как фиксированный пакет часов.

Принципы Agile в IT-разработке помогают нашим клиентам опережать конкурентов и снимать сливки с любого рынка.

Примеры проектов, работа над которыми велась именно по этому методу, вы можете посмотреть в нашем портфолио.