Agile vs Waterfall, что более эффективнее?
Так и не понял в чём преимущество Agile перед Waterfall? На мой взгляд гибкие методологии - это легализация бюрократии.
UPD
Заказчик в большинстве случаев не понимает, что хочет. Waterfall заставляет его проработать требования к структуре, архитектуре и функционалу продукта и заказчик вынужден это сделать. При этом гибкость никуда не пропадает, всегда можно провести изменения или при детализации внести уточнения. В части Agile, мы говорим заказчику - не парься, не прорабатывай продукт, просто накидай требований на неделю - две (спринт) и т.д. В итоге это всё превращается в бесконечный поток требований от заказчика, который сначала добавляет функционал, потом убирает, это так выгодно бюрократам, которые в гос. органах просто мечтают о возможности что-то бесконечно менять, привлекая для этого новые средства, расширяется штат, эффективность стремиться к нулю.
Про бюрократию сильно)
Советую начать знакомство с Agile с манифеста и принципов Agile-разработки:
http://www.agilemanifesto.org/iso/ru/
http://www.agilemanifesto.org/iso/ru...
По поводу того что эффективней:
Есть исследования Standish Group, называется CHAOS Report 2015, Статистика по 10000 IT проектам за 2011-2015 годы, http://blog.standishgroup.com/post/50
Если вкратце, то Waterfall успешен в 11% случаев, а Agile - в 39%. (Проект считается успешным, если были соблюдены сроки и бюджет, а также реализован необходимый функционал).
Понятно, что есть зависимость от размера проекта, а чем он больше, тем больше шанс фейла =)
Комментарии
Манифест я читал, с исследованием обязательно ознакомлюсь, но при реализации проекта всегда задаются критерии успешности и они упираются не только в качество, время, ресурсы и сроки.
Речь о другом, заказчик выкатывает требования , которые в большинстве случаев могут быть заведомо кривые, ему их реализовывают в срок, не отклоняясь от бюджета и именно тот функционал, который он просил. Типа проект успешный, но реально ценность никакую не несёт т.к. внедрённое тупо не работает.
Когда есть водопад, то ты заставляешь проработать архитектуру и структуры продукта, т.е. заказчик должен будет это сделать хоть в каком-то виде, а при agile он сегодня выкатил одни требования, завтра другие и так до бесконечности - не видя целевого продукта, он будет всегда пытаться идти к нему. Именно поэтому нет ничего удивительного в том, что agile проекты более успешные.
Т.е. для того, чтобы всё это заработало, необходимо, чтобы у людей был менталитет (мышление) особый. Если все будут на одной волне, то ок, если нет, то ничего не заработает. Гибкие методологии работают в стартапах, когда есть команда из 6 человек, каждый член которой идейно подходит к своей работе т.е. проникся работой (таким людям даже фреймворки не нужны, они и так работают эффективно). А в крупных компаниях, где от 200 человек, до 7-8 тысяч, нельзя поручиться за каждого, что он будет идейный.
Ознакомился с публикацией по поводу Киневин. Да, уже не первый раз вижу такое толкование, только вот не понятно данное деление. Гибкая методология возникла в ИТ, а внедрение любого продукта или его разработка, это по определению лучшие практики т.к. мы знаем, что делать и как это делать. Если речь идёт про систему, которая под собой подразумевает создание новой технологии (например обработки видео), то тут гибкая методология применима, но такие проекты являются либо стартапами, где команда на интуитивном уровне действует по принципам agile т.е. они сами для себя являются заказчиком и они идейные ребята. Либо это происходит внутри крупной компании, но тогда у гибкой методологии появляется весомый конкурент - ниокр проекты, которые всегда были и использовали именно водопад т.к. впринципе тоже понятно, что и как делать. Получается, что гибкие методологии либо не нужны вообще, либо применимы тогда, когда и без них обходятся команды.
Т.к. понятны этапы, фазы, результаты и вехи. Всё есть, нужно просто спланировать. Я больше скажу, когда задают вопрос - а как это сделать, тут нужно задуматься о компетентности РП.
Последняя фраза, вообще не понятна, что значит "активности, связанные с проектным менеджментом, тяготеют к запутанному"? Это всё и есть проектный менеджмент, подходы разные - waterfall, agile и т.д.
Алексей, спасибо, многое для себя узнал)))
На самом деле, есть типовой набор работ по проектам исследования (это и есть ниокр), т.е. даже здесь понятно, что делать.
Пример с кинопоиском, не очень подходящий, им нужно было запускать параллельно новую версию, чтобы приучить пользователей, это ошибка РП или заказчика, они просто рубанули топором.
При "внедрении" agile, мы переходим от человека к команде, сразу возникают проблемы глобального характера, которые разрешить нельзя, вот для примера две:
1. Невозможно оценить работу ресурсов подрядчика в смешенных командах (т.е. состоящих из внутренних и внешних ресурсов), мы же не можем оценивать конкретного человека. Радикально, формировать команды только из внешних и только из внутренних ресурсов тоже не правильно, пропадает гибкость и возможность экономить. Получается бесконтрольная работа поставщиков на проектах, это фатальный минус, который порождает коррупцию.
2. Пропадает возможность массовой закупки на проекты и программы (а это существенная экономия), также появляются риски отклонения поставок от сроков (железо).
Комментарии
Я думаю, что автор просто плохо знаком с Agile и никогда его не внедрял. Дело в том, что вы не ждёте пол года или год своего продукта, а получаете работоспособный продукт по окончанию спринта. В этом вся выгода.
Почему вы так думаете? Знаком с agile, поэтому и сомнения появились)))