Является ли гибкий подход слишком удобным оправданием для ковбоев?

Является ли гибкий подход слишком удобным оправданием для ковбоев?
Является ли гибкий подход слишком удобным оправданием для ковбоев? - brookecagle @ Unsplash

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

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

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

Действительно ли преимуществ agile-методологий достаточно, чтобы перевесить оправдание неуклюжести, которое они дают ковбойским техническим лидам?

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

Я считаю, что если вы используете Agile development как оправдание для программирования в ковбойском стиле, то вы на самом деле не следуете Agile development. Ковбои всегда будут ковбоями, независимо от того, какой процесс вы им предоставите.


LetsCodeIt, 22 мая 2023 г., 11:34