Agile vs Waterfall, что более эффективнее?

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

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

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

Т.е. для того, чтобы всё это заработало, необходимо, чтобы у людей был менталитет (мышление) особый. Если все будут на одной волне, то ок, если нет, то ничего не заработает. Гибкие методологии работают в стартапах, когда есть команда из 6 человек, каждый член которой идейно подходит к своей работе т.е. проникся работой (таким людям даже фреймворки не нужны, они и так работают эффективно). А в крупных компаниях, где от 200 человек, до 7-8 тысяч, нельзя поручиться за каждого, что он будет идейный.

Ознакомился с публикацией по поводу Киневин. Да, уже не первый раз вижу такое толкование, только вот не понятно данное деление. Гибкая методология возникла в ИТ, а внедрение любого продукта или его разработка, это по определению лучшие практики т.к. мы знаем, что делать и как это делать. Если речь идёт про систему, которая под собой подразумевает создание новой технологии (например обработки видео), то тут гибкая методология применима, но такие проекты являются либо стартапами, где команда на интуитивном уровне действует по принципам agile т.е. они сами для себя являются заказчиком и они идейные ребята. Либо это происходит внутри крупной компании, но тогда у гибкой методологии появляется весомый конкурент - ниокр проекты, которые всегда были и использовали именно водопад т.к. впринципе тоже понятно, что и как делать. Получается, что гибкие методологии либо не нужны вообще, либо применимы тогда, когда и без них обходятся команды.

Т.к. понятны этапы, фазы, результаты и вехи. Всё есть, нужно просто спланировать. Я больше скажу, когда задают вопрос - а как это сделать, тут нужно задуматься о компетентности РП.

Последняя фраза, вообще не понятна, что значит "активности, связанные с проектным менеджментом, тяготеют к запутанному"? Это всё и есть проектный менеджмент, подходы разные - waterfall, agile и т.д.

Алексей, спасибо, многое для себя узнал)))

На самом деле, есть типовой набор работ по проектам исследования (это и есть ниокр), т.е. даже здесь понятно, что делать.

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

При "внедрении" agile, мы переходим от человека к команде, сразу возникают проблемы глобального характера, которые разрешить нельзя, вот для примера две:

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