Об "Водопад"

Наверное, не надо объяснять, что модель разработки проектов Waterfall (каскадную) не ругает только ленивый. Я пообщался с людьми, и узнал, что мало кто вообще понимает, какое отношение к ней имеет водопад и каскады. В качестве источника названия часто указывают статью, опубликованную У. У. Ройсом в 1970 году; при том, что сам Ройс в своем описании использовал итеративную (!) модель разработки. И какое отношение имеет последовательная разработка слева направо к метафоре водопада?

Ответ на самом деле несложный, и кроется в организации производства. Представьте себе организацию традиционной иерархии. Пусть для простоты это будет рекламное агенство 70х или архитектурное бюро. Во главе ее будет CEO или генеральный директор, под ним руководители секторов/директора направлений, под ними архитекторы/начальники участка и конструкторы/арт-директора, на нижнем уровне "рабочие пчелки". Такая вот пирамида, острая кверху и с широким основанием снизу, содержащая несколько уровней.

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

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

«Последовательная работа» это и есть типичный водопад, даже если существует несколько этапов (итераций).  То есть сначала одни пишут и согласовывают ТЗ, вторые пишут код строго по ТЗ, третьи тестируют в конце приемка и если повезёт развёртываете. Про обратную связь от конечных пользователей я вообще молчу. Такая модель порождает огромное количество потерь (waste), очень мало реальной пользы (value), а полученный результат уже заранее несёт в себе существенный  техдолг.
А есть ли разбиение проекта на этапы или их нет совсем, и что там имел в виду Ройс уже неважно. Суть одна и та же - эта модель крайне неэффективна и именно это называется вотерфолом.
Поэтому когда Пименов настаивает на том, что вотерфола никогда не было, мне смешно.

я правильно понимаю мысль, что разумной альтернативой "последовательной работе" будет "непоследовательная работа"?

Функциональный дивизион - это колодец. Такая оргструктура уже давно доказала свою неэффективность в продуктовой разработке. В проектном управлении, когда есть ресурсные центры и центры экспертизы, всё это оправдано. И отталкиваемся мы от загрузки людей. В продуктовом мире не так. Цели другие.

Принцип и цель проектного управления в другом. Иначе - сова на глобусе.

Да, вполне. У меня Канбан и no-estimation, но есть планирование и куча документов вроде журнала и реестра рисков.

Ну очевидно, что никто не управляет уже руководствуясь первой версией или на полной серьёзе ГОСТ 34.

Тогда посадить заказчика вместе с командой и пусть максимально прозрачно обо всем договариваются сами. А РП в стороне пусть про бюджеты думает.

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

И что в этом плохого? Зачем нам кузнец? Благословлять? Вот бизнес, вот команда, работайте, братья!

)))))
И о чем они смогут говорить? Это две разные цивилизации, у них даже языки разные.

Учиться, учиться и учиться

А разрабу надо этому учиться? Он считает, что не надо ))

Фу таким быть.

Такие в команде нинужны )

Фу таким быть.

Такие в команде нинужны )

Ну сколько уже можно обсуждать )

«Последовательная работа» это и есть типичный водопад, даже если существует несколько этапов (итераций).  То есть сначала одни пишут и согласовывают ТЗ, вторые пишут код строго по ТЗ, третьи тестируют в конце приемка и если повезёт развёртываете. Про обратную связь от конечных пользователей я вообще молчу. Такая модель порождает огромное количество потерь (waste), очень мало реальной пользы (value), а полученный результат уже заранее несёт в себе существенный  техдолг.
А есть ли разбиение проекта на этапы или их нет совсем, и что там имел в виду Ройс уже неважно. Суть одна и та же - эта модель крайне неэффективна и именно это называется вотерфолом.
Поэтому когда Пименов настаивает на том, что вотерфола никогда не было, мне смешно.