Скрамные водопады


Эпиграф. Почувствуй себя программистом⁠⁠

Благодаря этому уникальному упражнению, вы, совершенно не зная ни одного языка программирования, сможете сделать это.

Для упражнения потребуются:
— два участника;
— часы (желательно с секундомером);
— листок чистой бумаги;
— ручка (шариковая или гелевая, но именно ручка, — это важно).

Один из участников будет «Заказчиком» (Работодателем), другой — «Исполнителем» (Программистом).
«Заказчику» выдаются часы и право голоса, «Исполнителю» — бумага и ручка.

Начало упражнения:
«Заказчик» засекает 10 минут и дает задание «Исполнителю»:
«Нарисуйте мне, пожалуйста, красивую девушку.»

Далее, пока «Исполнитель» рисует, стоя у него над душой «Заказчик» высказывает следующие пожелания к рисунку:
0:30 — Пусть у нее в руке будет меч.
1:00 — Двуручный меч, который она держит обеими руками!
1:30 — А в другую руку ей дайте УЗИ.
2:00 — Пусть она будет уставшей путешественницей, присевшей отдохнуть.
2:30 — На меч она опирается, отдыхает, значит.
3:00 — Пусть на ней будет развевающийся по ветру плащ!
3:30 — …И купальник.
4:00 — А лучше доспехи!
4:30 — Не… униформа!
5:00 — Уберите плащ, он не идет к униформе.
5:30 — Пусть она смело стоит на мостике космического крейсера!
6:00 — Почему у нее меч? Уберите это старье. А УЗИ переделайте в бластер!
6:30 — Ее волосы развеваются по ветру… для красоты, значит.
7:00 — Бластер не смотрится… уберите его. Она вообще капитан этого корабля, ей не нужен бластер!
7:30 — Ей нужна фуражка капитана! И аккуратно собранные на голове волосы!
8:00 — И сидеть она должна в кресле капитана!
8:30 — Красивая, суровая и необычайно смелая капитанша корабля пиратов…
9:00 — Нет, эскадры боевого флота Галактической Федерации!
9:30 — …Вытягивая палец, отдающая приказ о смене курса…

По истечении 10 минут «Заказчик» берет работу «Исполнителя», критически ее осматривает и высказывает свое впечатление:
«Ну это же совсем не то, что я хотел! А где ее верный советник? А почему у нее нет табельного оружия? И вообще, почему она такая некрасивая и суровая? Я же просил КРАСИВУЮ девушку! И вообще на рисунке столько каракулей… Плохой вы программист, зря я к вам обратился… Не буду платить за такую халтуру!»

Итак, раньше трава была мокрее, вода зеленее, а идиотов называли идиотами. А не заказчиками/исполнителями.

И приблизительно тогда же царствовала методология водопад. Кому интересно — погуглите. Но если вкратце — сначала мы определяемся, чего мы хотим, потом — как именно мы этого хотим, затем разбиваем на чёткие этапы выполнения (что можно — параллелим, что нельзя — выполняем последовательно), далее работаем по плану и на выходе получаем конечный продукт с заданными на этапе проектирования характеристиками.

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

Было не очень быстро, но достаточно вменяемо по конечному результату.

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

Нет, серьёзно. Почитайте, например, про Scrum. Почитали? А теперь перечитайте эпиграф. И найдите 10 отличий.

Кстати, хороший пример результатов гибкой методологии разработки — это живая природа вокруг нас. Да и мы сами. Как физиологически, так и ментально. Но здесь хоть можно оправдать столь удручающий результат: когда вокруг меняется среда обитания — либо нужно на имеющуюся архитектуру прикрутить костыль, позволяющий хоть как-то (ключевой момент — «как-то») выжить, либо сдохнуть. К тому же, природа не занимается целеполаганием, она живёт здесь и сейчас. И не думает о том, что «лучше» сейчас приведёт к много более худшим последствиям уже через два шага.

А когда речь идёт о софте, который без проблем можно дописать, переписать, оптимизировать и, что самое главное, спланировать — все эти гибкие методологии мне лично напоминают анекдот про автолюбителей:

Лет 50 назад в инструкции к автомобилю писали, как регулировать зазор клапанов. А сейчас пишут, что нельзя пить аккумуляторную жидкость.

Всё. Аллес капут. Если в случае с машиной можно худо-бедно оправдаться тем, что на текущем уровне их устройства там вручную чинить нечего (и то, сие есть крайне спорный вопрос), то про управление проектами такое может сказать только полный дегенерат, считающий, что «я там в MS Project цифирьки вбил, а дальше оно само».

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

  • Просто процесс ради процесса, развлечение за чужой счёт.
  • Желание сдоить с клиента побольше денег.
  • Просто неумение/нежелание делать законченный продукт.

Такие дела.