Наш эксперт Анастасия Гусакова рассказала, можно ли продать Agile как дополнительную опцию при разработке и способен ли этот подход стать проблемой.
Содержание
Преимущеcтва 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-проектах с субподрядом. Однако это не проблема самой методологии, а лишь следствие противоречия подходов. Поэтому для минимизации рисков, при составлении договора надо детализировать план разработки ПО и обсуждать сроки выполнения этапов и всего цикла разработки.
