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

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

С Agile нет необходимости в техническом задании, несмотря на то, что часто ТЗ включает важнейшие блоки по пояснению назначений компонентов и описывает общий план.

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

Простота договора: договор говорит о ежемесячной приёмке объёма работ по предоставленной детализации. Проще договор — быстрее согласование и подписание, при этом документ защищает и исполнителя, и заказчика в равной мере.

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

Продукт быстрее выходит на рынок (в виде MVP), легче адаптируется под запросы потребителей.

Прибыль — всегда в фокусе. Цель — быстро получить первую прибыль от MVP и увеличивать её за счёт лучшего удовлетворения нужд клиентов.

Без Agile

Есть плановые показатели, которых нужно чётко придерживаться:

• дата начала проекта;
  
• дата окончания проекта;
  
• бюджет.
  

Сначала бизнес строит гипотезы о том, каким должен быть идеальный IT-продукт (интернет-магазин, мобильное приложение, B2B-портал…), затем нужно подготовить чёткое техническое задание — по нему будет действовать подрядчик. И уже после сдачи работ подрядчиком бизнес принимает проект в эксплуатацию.

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

Но что, если техническое задание не учитывало каких-то процессов (а это, подчеркнём, происходит практически всегда)? За время разработки на рынке появился более выгодный заменитель, активный конкурент, сменились тренды, курс валют и другие факторы.

С Agile

Здесь размер проекта уменьшается до размера спринта. В результате спринта появляется небольшой функционал, которым уже можно пользоваться. Да, на скорость работы программистов мы повлиять не можем. Но что Agile точно ускоряет, так это релиз минимально жизнеспособной версии продукта (MVP). Выпустить MVP на рынок реально за 1–3 месяца, затем начать корректировать функционал по требованиям бизнеса, на ходу уточняя приоритеты. А значит, получившийся продукт будет лучше соответствовать ожиданиям пользователей.

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

В переводе с английского Agile означает «проворный», «подвижный», и сама эта система означает гибкость, подвижность, готовность к переменам. Улучшения можно вносить регулярно, а не разово, и с меньшими затратами. Поэтому качество готового IT-решения максимально адаптировано к требованиям клиента. Это легко отследить не только по отзывам, но и по web-аналитике и анализу юзабилити.

Без Agile

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

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

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

С Agile

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

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

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

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

Без Agile

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

С Agile

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

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

Итак, главное.

Цель бизнеса — извлекать прибыль. Программное обеспечение — это часто запутанные системы (по методологии Agile это системы с большим количеством факторов, где причинно-следственные связи непонятны).

Для запутанных систем нам важнее быстрее получать обратную связь от реальных пользователей, а на сегодняшний момент можно уверенно говорить, что развитие и управление любым продуктом — запутанная система. Если же перед вами стоят чёткие и однозначные задачи, вполне возможна работа по классической методологии: ТЗ, сроки, бюджет.

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

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

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