Давным-давно, when the hills were still young, каждая торговая компания (ТЗК) имела свой отдел

Давным-давно, when the hills were still young, каждая торговая компания (ТЗК) имела свой отдел программистов, бизнес-приложения были database driven, т.е. вся бизнес-логика жила внутри СУБД (Oracle, DB2) в виде хранимых процедур, а клиенты писались на чем попало (perl, например).
Это приводило к тому, что весь бизнес какого-нибудь Walmart держался на одном очень дорогом компьютере и на одном очень дорогом программисте СУБД (DBD) и естественно это никого не устраивало.

В какой-то момент, фронтенд компьютеры начали стремительно дешеветь, в то время как компьютеры под БД в цене не падали, и возникла идея перенести часть логики на фронтенд.

В этой парадигме Sun представил миру EJB (1998 год) а в 2001 году был опубликован Agile манифест. Параллельно, с 1986 года по миру бродил Scrum — это методологический framework для управления проектами, суть которого в разбиении большого проекта на небольшие атомарные части. И в том же 2001 году Scrum натянули на Agile - т.к. они хорошо подходили друг другу: Agile как набор процессов (process framework) и Scrum как метод реализации процессов.

Основная беда Agile - растущий технический долг, т.к. “Responding to change over following a plan” на практике означает, что на глубокое планирование или рефакторинг существующего кода не выделяется ресурсов.

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

Розничный бизнес готов платить эту цену за гибкость и уменьшение стоимости разработки. Если у вас есть “домашний” софт, который вы можете релизить когда захотите и у вас есть домашняя команда разработчиков, готовая откликаться на задачи бизнеса и переделывать все от Адама раз в две недели, то в этой среде Agile по сей день чувствует себя прекрасно.

Но как это бывает со всеми модными идеями, Agile стали пихать куда ни попадя – в автопром, разработку процессоров, софт для управления электростанциями и так далее. В 2011 году появился SAFe, который позволяет вам сделать из классического waterfall псевдо-agile, запихав Scrum внутрь каждой итерации (program increment), стоит это 20% проекта т.к. каждый 5 спринт объявляется техническим.

Ничего хорошего из этого вполне ожидаемо не выходит – сколько-нибудь сложный архитектурно софт или забывает про agile оставляя только внешнюю часть scrum ритуалов или срывает все планы по срокам и качеству

#blog