Как продать Agile заказчику и избежать очевидных проблем

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

Большая ценность Agile и для заказчика, и для разработчика – это возможность ускорить time-to-market — скорость вывода продукта или отдельной его функциональности на рынок. Команда внедряет систему с более высокой частотой выпуска релизов, периодами от одной до нескольких недель в зависимости от сложившейся в команде практики. В противовес практике Waterfall, , не нужно ждать завершения проекта или длительного этапа, можно запускать продукт итерационно или даже по мере готовности фичи.

Другое преимущество Agile – быстрая реакция на отраслевые изменения, инновации и лучшие практики. Иногда появление каких-то новых технологических возможностей, которые нельзя было спроектировать сразу, может поменять целевую архитектуру будущей системы. Особенно часто такие изменения происходят при внедрении e-commerce продуктов, чьи пользователи – бизнес или конечные потребители – очень требовательны, а новые технологии появляются каждый месяц. В случае Waterfall такая гибкость и скорость отклика на потребности пользователя и клиента невозможна.

Более того, подобная методика позволяет экспериментировать прямо в продуктиве: проводить A/B-тестирование, проверять гипотезы и выбирать из нескольких альтернативных вариантов тот сценарий, который получит положительную реакцию пользователей. Если компания привлекает для разработки стороннюю команду, то большую роль в этом процессе играет, насколько оперативно бизнес даёт обратную связь на каждом этапе внедрения.

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

Может ли Agile стать проблемой для разработчика и почему?

Сам по себе Agile не может стать проблемой. Трудности могут появиться, если участники проекта не договорятся о качестве: насколько детально прорабатывать требования, каковы будут критерии приемки результата, какими средствами будет обеспечиваться качество (автотесты, нагрузочное тестирование и пр.), какие метрики использовать для отслеживания качества продукта уже во время его эксплуатации и так далее. В перспективе из-за таких недочётов будет накапливаться технический долг, релиз тех или иных функций будет задерживаться, качество продукта и удовлетворённость пользователей будут падать.

Также есть устойчивый миф о том, что Agile-команды очень эффективны и их продуктивность со временем только растет. Однако вера в этот миф также может стать источником сложностей. Действительно, какое-то время в течение нескольких спринтов, пока команда срабатывается, эффективность повышается – за штормом следует период нормализации и продуктивного функционирования, это характерно не только для Agile. В проекте состав специалистов чаще всего стабилен от начала и до конца, при разработке продукта все немного не так. Жизнь продукта существенно длиннее проекта, и в реальной практике сработавшиеся Agile-команды в течение 1-2 лет распадаются, переформируются, люди растут, хотят новых задач, смены обстановки, происходит ротация. И тогда процесс командообразования начинается заново. Как следствие – снижение эффективности и скорости разработки. Это абсолютно нормальная ситуация, главное – учитывать это при планировании развития продукта.

Есть ли особенности в использовании подхода Agile с заказчиками из США и России?

Главная особенность – это различие договорных отношений между заказчиком и подрядчиком. В США компании разрабатывают программное обеспечение по договору Time&Material. То есть заказчик берёт на аутстафф команду подрядчика и оплачивает её часы, контролируя результат в коротких итерациях. А в России большинство компаний все еще работает по фиксированной цене, то есть платят за конечный результат. Это может провоцировать сложности на отечественных Agile-проектах с субподрядом. Однако это не проблема самой методологии, а лишь следствие противоречия подходов. Поэтому для минимизации рисков, при составлении договора надо детализировать план разработки ПО и обсуждать сроки выполнения этапов и всего цикла разработки.

Источник: Digital Report