Продолжаю размышлять над текстами, которые привлекли моё внимание (ранние тексты можно прочитать в телеграм-канале). Сегодня на очередные размышления меня натолкнула статья на Хабре "Scrum приводит к потерям. Как с этим справляться".
Меня очень сложно назвать сторонником agile и scrum. Да и сам термин agile я чаще использую в ироничной коннотации. Но я абсолютно уверен, что в определенных условиях такой формат разработки может быть весьма неплох.
Но вернёмся к статье. В ней рассказывается о том, как здорово внедряли scrum для больших команд, как отбирали и удерживали программистов, какие проблемы решали.
Мои мысли по самой статье: то, что в первые два года команде разработки пришлось выбивать ПО и железо под свою работу означает только то, что до этого разработки внутри компании вообще не было. А уже через два года, когда команд разработки стало больше 5, зумерам пришлось заново изобретать водопад (каскадную модель разработки ПО), от которого они убегали в agile. Потому что для управления более-менее крупным проектом недостаточно product owner, который будет общаться с пользователями и составлять списки хотелок, обязательных к исполнению в ближайший месяц.
SAFe (Scaled Agile Framework) внезапно возвращает в agile руководителя проекта, аналитиков, архитекторов и прочие "атавизмы", с которыми боролся agile. Очень забавно читать о том, что в команде разработки "не нашим" "лишь бы по ТЗ работать и ни с кем не разговаривать, а мы, представьте, хотим, чтобы они с конечным пользователем заговорили". Для разработки большого продукта программист совершенно точно не должен общаться напрямую с пользователями, у него другая задача - программировать. С пользователями может общаться аналитик, архитектор, в крайнем случае ux-дизайнер, но работа программиста никак не должна быть связана с расшифровкой хотелок.
Главное, чего позволяет добиться agile - вести разработку продукта при недостаточных компетенциях управленцев. Agile позволяет перекинуть этапы анализа, планирования и дизайна на разработчиков, то есть на этап разработки. По данным международного совета по системной инженерии стоимость исправления ошибки, допущенной на стадии разработки концепции, увеличивается: на стадии проектирования в 3-6 раз, на стадии разработки рабочей документации – в 20-100 раз, на стадии испытаний системы (пусконаладочные работы) – в 500-1000 раз. Таким образом мы увеличиваем стоимость разработки за счёт снижения компетенций менеджмента.
Но всё же, я уверен, что agile может быть полезен в некоторых условиях.
Во-первых, внедрять его можно только при наличии внутренней группы разработчиков, тогда мы можем хотя бы примерно контролировать утилизацию рабочего времени членов команды. Почасовая оплата за неопределенный круг задач на аутсорсе всегда будет больше, чем работа по ТЗ именно за счет закладывания аутсорсерами компенсации рисков на неопределенность.
Во-вторых, работа должна идти небольшим числом разработчиков над небольшим проектом, который не требует значительных усилий на анализ и планирование. То есть для такого проекта, который действительно можно описать набором хотелок.
В-третьих (это задача со звездочкой) при хорошем менеджменте проекта можно реализовать agile на нижнем уровне разработки, проведя предварительные работы по разработке проекта, технического задания, декомпозиции задач. Тогда небольшие задачи действительно могут вписываться в agile, опять же, если разработка идёт своими силами. Фактически это и получается SAFe.
В остальных случаях я был и остаюсь сторонником старого древнего водопада, пусть зумеры и считают меня динозавром.