Agile умер, Водопад возвращается

Кен Швабер — соучредитель Scrum и основатель Scrum.org — говорит, что Водопад (Waterfall) «буквально разрушил нашу профессию». «Он сделал так, что люди стали рассматриваться как ресурсы, а не как ценные участники». С таким большим планированием сотрудники стали просто винтиками в машине.

Модель разработки “водопад” зародилась в обрабатывающих и строительных отраслях, где структурированные физические среды означали, что изменения в конструкции или дизайне становились непомерно дорогими уже на ранних стадиях разработки. При первом применении для разработки программного обеспечения не существовало признанных альтернатив для творческой работы, основанной на знаниях.

Проблема

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

Конечно, оглядываясь назад, это звучит больно, и это было так! Для выполнения простой компиляции требовалось несколько профессионалов. Были люди, которые отвечали только за организацию карточек в коробках. Не очень специализированная работа, но кто-то должен был это делать. Чтобы уменьшить стоимость этой громоздкой операции, в дело вступил Водопад. Не было необходимости иметь много узкоспециализированных профессионалов, сидящих и перебирающих перфокарты в течение всего дня, если планирование было сделано заранее. Это сработало отлично. Многих ошибок можно было избежать, и на разработку программ уходило меньше времени.

Идем вперед

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

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

Старый против нового

В последние годы многие говорили об Agile как об основной и обязательной методологии для процессов разработки программного (и даже непрограммного) обеспечения внутри организации. Принято считать, что это решение любой проблемы. Независимо от того, в каком секторе, что/кто задействован и какова природа, для вас найдется Agile-фреймворк.

Каждая организация уникальна и сталкивается с различными внутренними элементами (например, размер и текущая структура) и внешними элементами (например, клиенты и бизнес-модель). Была проделана большая работа по созданию новых фреймворков в соответствии с манифестом Agile для удовлетворения потребностей и решения различных возникающих проблем. Простота заключается в том, что это набор принципов, которым нужно следовать и настраивать в соответствии с вашими потребностями. Не существует универсального решения. В каждом секторе есть свои роли, проблемы, процессы, люди и набор навыков. Какое сочетание подойдет команде, зависит от внутренних и внешних факторов, желаний и целей.

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

(Старая) новая проблема

В то время (90-е и 00-е) практически не было разделения между теми, кто отвечает за создание хорошего программного продукта. Большая часть работы в руках разработчиков. Пользовательский опыт сам по себе не был чем-то особенным. Очевидно, он присутствовал всегда, но если продукт был хорошо принят, это было своего рода загадкой. Дизайн пользовательского интерфейса рассматривался как неважный и приводил к ужасным результатам.

Однако сегодня вам может понадобиться несколько человек с разными наборами навыков, чтобы создать и сохранить конкурентоспособный продукт на рынке. UX/UI-дизайнеры, продакт-менеджеры (и их разновидности), бэкенд-разработчики, фронтенд-разработчики, мобильные разработчики, специалисты по инфраструктуре и т. д. (видите здесь закономерность?). Понятно, что потребность в большем количестве персонала, различных должностях увеличивается с каждым днем.

Кроме того, крупные технологические компании начинают впадать в отчаяние. Не хватает специалистов, чтобы удовлетворить их потребности. За первое десятилетие (2001–2011 гг.) заработная плата увеличилась до 35%, а за второе еще до 47% в зависимости от региона. Может ли снова наступить эпоха программного кризиса?

Основная цель Водопада — сократить затраты на этапе разработки (фактического написания кода). Столь высокие зарплаты и нехватка профессионалов сигнализируют о возвращении к такому перспективному планированию. Маленькие компании не могут просто конкурировать с крупными зарплатами и держать профессионалов рядом, чтобы они «быстрее совершали ошибки».

Как вы думаете? Стоит ли планировать до фактической реализации? Или все должны использовать метод проб и ошибок? Может смесь того и другого? Оставьте свои комментарии.

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

Спасибо за прочтение!

Источник