Как выглядит Agile подход в аутсорс компании при разработке проекта

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

Обязательно расскажу о том, как применяем Agile в компании, но прежде — пара слов о самом подходе.Agile — это гибкий подход, при котором команда выпускает проект частями, а не целиком после завершения всех работ. Это не единственная гибкая методология — есть еще DSDM, Scrum, FDD, BDD и другие.Agile отличает возможность вносить в проект новые идеи и изменять требования уже по ходу разработки продукта. В отличие от строгого планирования, гибкий подход предусматривает неизвестность заранее и встраивает ее в рабочий процесс. Agile на практике в YuSMP Group

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

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

Чтобы откалибровать требования, дизайнер создает кликабельные прототипы — без цвета и детализации. Клиент отсматривает экраны и дает обратную связь. Такой визуал позволяет понять, что клиент хочет от той или иной фичи. Формируется общий концепт проекта, при этом команда не тратит время и силы на прорисовку и детализацию.С помощью черно-белых прототипов и пользовательских историй, команда вместе с заказчиком проходит по большинству фичей. Дальше мы приступаем к детальной прорисовке экранов в цвете, полностью прописываем требования SRS и снова отдаем на ревью клиенту.

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

Приведу пример.

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

Чаще всего процессы стадии аналитики и дизайна идут параллельно, а разработка, напротив, стартует задержкой. Так у команды, ответственной за код, всегда будут фичи для реализации. В Agile важно не допускать простоя — когда у разработчиков нет работы.

Главные плюсы такого подхода — это высокая скорость разработки и быстрый выпуск продукта, а также гибкость требований. Agile отлично подходит, когда заказчику необходимо в сжатые сроки запустить MVP на рынок. На этом работа не останавливается: после того как продукт показал себя в деле, его детализацию меняют под потребности рынка.Однако и у Agile можно найти недостатки. При таком подходе требуется большая вовлеченность заказчика, а частые изменения фичей увеличивают бюджет и затягивают сроки.