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

1
0
-1

Так и не понял в чём преимущество Agile перед Waterfall? На мой взгляд гибкие методологии - это легализация бюрократии.

UPD

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

1418 просмотров.
Answer

Комментарии

Я думаю, что автор просто плохо знаком с Agile и никогда его не внедрял. Дело в том, что вы не ждёте пол года или год своего продукта, а получаете работоспособный продукт по окончанию спринта. В этом вся выгода.

- Grabber - 5 месяцев назад.

Почему вы так думаете? Знаком с agile, поэтому и сомнения появились)))

- expand - 5 месяцев назад.
2 answers

1
+2
-1

Про бюрократию сильно)

Советую начать знакомство с 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 проекты более успешные.

- expand - 5 месяцев назад.

Да, прекрасно вас понимаю.
Тут самое время познакомиться с фреймворком Киневин - эта штука из теории запутанности. На русском наверно Сергей Дмитриев лучше всего написал про него http://www.unusual-concepts.ru/blog/...

Становится понятно, почему Скрам работает в "запутанном" мире. Требования всегда будут неполными, но обратная связь поможет их выровнять. А чтобы максимизировать вэлью нужен Продукт оунер, чтобы приоритезировать беклог и в 1 очередь делать самое нужное и полезное. Обратная связь на обзорах спринтов поможет в приоритезации. Это как раз в тему реальной успешности. Успешен должен быть продукт, а не проект.

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

Вот вы говорите "при agile он сегодня выкатил одни требования, завтра другие и так до бесконечности", это не так, это миф и недопонимание.
Есть куча инструментов для проектирования продуктов. Это и карта историй (Story map), и user profiling, и Customer Journey Map, и релизное планирование.
Но для всего этого нужен хороший продакт менеджер =)

- Aleksey Yan - 5 месяцев назад.

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

- expand - 5 месяцев назад.

Ну очевидно, что чем меньше людей, тем проще. И да, вы правы, нельзя "делать" Agile, можно быть Agile (это все таки прилагательное).

Есть примеры, когда все норм работает и в крупных компаниях. Это Zappos, это бразильская Semco (вообще делает нефтяные насосы). Советую книгу Фредерика Лалу "Открывая организации будущего", там много конкретных кейсов.

На самом деле для крупных организаций есть фреймворки, которые работают. Это Less и SAFe, например. Посмотрите в их сторону.
Но конечно, люди важнее процессов, как и сказано в манифесте =) Он же про здравый смысл, а не про рецепт от всех болезней.

- Aleksey Yan - 5 месяцев назад.

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

- expand - 5 месяцев назад.

Но почему вы думаете, что разработка продукта по определению подразумевает лучшие практики?

Активности, связанные с разработкой программного обеспечения, в основном находятся в Сложном и Запутанном доменах. При этом активности, связанные с кодированием, чаще всего принадлежат Сложному домену. Активности, связанные с проектным менеджментом, тяготеют к Запутанному. (Joseph Perlin, Understanding Software Agility).

- Aleksey Yan - 5 месяцев назад.

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

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

- expand - 5 месяцев назад.

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

- Gonzo - 5 месяцев назад.

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

Приведу в пример недавнюю историю с Кинопоиском. Сделали что-то, качественно и даже возможно в срок. И были понятны этапы, фазы, результаты и вехи. И как вы говорите, РП компетентен, даже не сомневайтесь. Всё есть, нужно просто спланировать.
А вот то что пользователи примут смену бизнес-модели в штыки -этого никто не знал. Если бы действовали итеративно, работали с обратной связью,
делали тесты, такого факапа можно было бы избежать.

- Aleksey Yan - 5 месяцев назад.

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

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

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

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

- expand - 2 месяцев назад.

1
0
-1

Интересное заявление, обоснуй, почему так думаешь?

Комментарии

+ пару примеров в студию, а то так с ходу лупить.

- Grabber - 5 месяцев назад.

Выше, в переписке с Aleksey Yan

- expand - 5 месяцев назад.

Похожие вопросы

Agile Просмотров: 183 Голосов: 1 Ответов: 2
Agile Просмотров: 167 Голосов: 1 Ответов: 1
Agile+ 1 ещё Просмотров: 148 Голосов: 0 Ответов: 0