Просто о сложном: agile-разработка

Изначально аджайл был вотчиной программистов. Так они называли методы разработки ПО, принципиально отличавшиеся от традиционного. Но оказалось, что принципы аджайла с успехом можно применять в самых разных областях. Так аджайл стал философией разработки продукта в целом.

Что было до аджайла

До гибкой разработки все диджитал и IT-компании создавали продукты целиком. Например, в студию обращался заказчик и говорил, что он хочет сайт. Студия отвечала, что не может начать работу без исчерпывающего технического задания. Заказчик вздыхал, садился за бумагу, писал ТЗ на сто страниц, пытаясь по пути не упустить ничего важного. Команда принимала техзадание, закрывалась у себя в студии, работала 2 месяца и показывала результат. После тестирования и правок сайт запускали.

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

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

Agile Manifesto

Со временем разработчики стали тестировать и изменять продукт во время работы. Так появились новые техники, которые назвали гибкими. В 2001 году 17 представителей профессии собрались в горной деревне штата Юта, покатались на лыжах и заодно обсудили свои подходы к разработке.

Итогом встречи стал «Манифест Аджайла», в котором излагались основные принципы, выводы и целая философия гибкого программирования. Сейчас эту философию широко практикуют не только в диджитал-среде, но и в любой другой. Вот 4 основных ее положения:

Люди и взаимодействие важнее процессов и инструментов.

Работающий продукт важнее исчерпывающей документации.

Сотрудничество с заказчиком важнее согласования условий контракта.

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

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

Как команды работают по аджайлу

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

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

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

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

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

Кое-что еще

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

Чтобы упростить эту задачу, существуют специальные наборы правил, фреймворки. Например, Скрам и Канбан, которые сейчас на слуху. У каждого своя система и правила, их можно видоизменять, дополнять и адаптировать под команду. Расскажем об этих подходах как-нибудь в другой раз, а пока суть:

Процесс работы по Scrum: спринты, циклы разработки, standup-митинги

Канбан-доска: карточки перемещаются по колонкам-этапам

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

Какому продукту точно нужен аджайл?

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

Большой и технологически сложный. Когда дешевле делать все постепенно и постоянно тестировать, чем переделывать уже готовый Длительный по времени. Чем дольше проект будет функционировать, тем тяжелее представить его развитие — например, интернет-магазин.

С высокой неопределенностью. Когда проект инновационный, невозможно заранее продумать все функции, проще делать его маленькими рывками и тестировать.

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

С идеальным заказчиком. Когда клиент настолько заинтересован в продукте, что хочет сам во всем участвовать. Аджайл — идеальный сценарий.

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