Agile или Waterfall? Сравнение методологий веб-разработки
При создании нового проекта, заказчик должен определиться не только с выбором подрядчика, но и подходящей методологией разработки проекта. На современном этапе развития технологий, нет универсального подхода в создании проекта, поэтому возникает логичный вопрос: какой подход выбрать и какие «подводные камни» существуют?
Ну вот какбэ да.
Выбирайте исполнителя, а с методологией уж пусть он сам пределяется. Если вы принципиально не хотите работать по предложенной методологии, а исполнитель не хочет ее менять, возможно, это не ваш исполнитель.
Ну и вопрос о месте работы автора.
Это ж каких размеров должна быть производственная махина, чтобы изменить продукт в процессе вотерфлоу было вот прям невозможно. Не дорого, не долго, не сложно, а вот прям невозможно?
Согласен, пожалуй "невозможно" слишком эмоциональное слово, по сути нет ничего не возможного, по этому да, правильней было бы сказать, что слишком дорого и не рационально.
** Преимущества Waterfall ** полный бред. Вы работали с реальными проектами?
Стоимость и сроки выполнения понятны ещё до начала работ. Поэтому заказчик точно будет знать, когда проект завершится и какой бюджет требуется потратить.
Стоимость и сроки не понятны, они взяты из носа и размазаны по бумаге. По факту сроки и бюджеты всегда нарушаются.
Интуитивно понятная структура работы, как для опытных специалистов, так и для новичков.
Структура работ не понятно, а расписана из ПРЕДПОЛОЖЕНИЙ руководителя проекта или другого руководящего лица. Это мешает контактировать, мешает помогать, все заняты своим делом и не заботятся о благополучии команды.
Детально структурированный план работ и продуманная документация.
Документация, которую никто не читает. План работ, основанный на предположениях.
Благодаря удобной отчетности легко отследить потраченное время, возможные риски и используемые ресурсы в процессе работы над проектом.
Постфактум в любом случае можно всё это отследить, если фиксировать во время работы.
Задачи, которые ставятся перед командой ясны и не меняются на протяжении всего проекта.
Для команды ясны, но в ходе проекта задачи меняются у заказчика и на выходе получается не жизнеспособный продукт, который не нужен заказчику.
Качество проекта занимает первоочередное место, а потраченное время и бюджет отходят на второй план.
А в Scrum и вообще в Agile продукт на последнем месте да?
С ** недостатками Agile ** тоже не согласен.
Рассчитать конечные затраты практически невозможно – требования могут постоянно меняться в зависимости от особенностей проекта. Сложность заключается в том, что они могут противоречить уже существующей структуре.
Требования могут меняться, но они не должны быть диаметрально противоположными. Требования могут дополняться, да. А чтобы вместо изначально запрошенного сарая, заказчик на выходе не требовал дворец, нужен грамотный Product Owner.
Agile требует большой вовлеченности в процесс и полному погружению в него, что бывает сложно, особенно для молодых подрядчиков.
Любая задача требует полного погружения и воволеченности, иначе это будет халтура, а не работа.
Возможность частого внесения правок может обернуться риском в бесконечном совершенствовании проекта. Здесь также возможна и обратная сторона – снижение качества продукта.
Опять таки, есть конечные требования, поставленные изначально, а чтобы губу клиент не раскатывал есть договор и Product Owner.
Вообще по Agile в статье много ошибок. Либо автор не до конца разобрался в вопросе, либо просто не смог правильно преподнести информацию.
А вообще советую прочитать книгу Scrum (Джефф Сазерленд). Там всё по полочкам.
Согласен по большинству пунктов! Оговорюсь только в том, что статья написана для обывателя, поэтому многие моменты упрощения для понимания. Если же освещать действительно все нюансы, то смысл статьи получится следующий - "какая-бы методология использована не была, все равно оценить нихрена не получится".
Придраться из за одного вступления, игнорируя остальную статью - как-то не true
...