Возможно ли, чтобы проект Rails/Django стал Маршем смерти?
Я работал над проектами Death March в мире Java - проектам, которые с самого начала обречены на провал из-за некоторого сочетания плохого управления и громоздкой, сложной технологии, обычно охватывающей несколько систем и часто привязанной к водопадному подходу.
Rails и Django рекламируются как технологии гибкой разработки, что означает, что они ориентированы на способность быстро реагировать на изменения.
Означает ли это, что они невосприимчивы к сценариям "Марша смерти" для крупных корпоративных систем? Или в проекте Rails/Django все еще есть место для достаточной сложности, чтобы он мог выйти из-под контроля так же, как и проект Java?
7 ответов
Конечно, это. У меня есть личный опыт работы над несколькими проектами Django, которые стали маршами смерти.
Вы можете использовать все технологии гибкой разработки в мире, но если ваша компания не в полной мере использует гибкие концепции, то это не поможет вам избежать марша смерти. Если руководство требует, чтобы продукт был доставлен в определенную дату и включал в себя определенный набор функций, использование фреймворка не поможет: вы все равно застряли, работая так быстро, как можете, пока не будете удовлетворены. Если это означает марш смерти, то это марш смерти.
Марш смерти - это функция плохого управления и планирования, которая возможна независимо от того, какой язык вы используете.
Кажется, что вопрос, который задают, состоит в том, могут ли технологии решить человеческую глупость...
Ну, насколько я знаю, до сих пор нет лекарства.
Со страницы, на которую вы ссылаетесь:
"... результат нереалистичных или чрезмерно оптимистичных ожиданий при планировании, объеме функций или обоих, и часто включает в себя отсутствие соответствующей документации или какое-либо соответствующее обучение... Часто марш смерти включает отчаянные попытки исправить курс проекта, попросив членов команды работать, особенно изнурительные часы, выходные или пытаясь "бросить (достаточно) тела в проблему"..."
Мне кажется, что некоторые методологии более восприимчивы к тому, чтобы быть маршем смерти (водопад, как вы упомянули, приходит на ум), похоже, что любая методология с достаточно плохим управлением могла бы стать таковой.
Честно говоря, все, что плохо управляется, может потерпеть неудачу, даже с удобством сред, которые должны облегчить процесс разработки. Они, конечно, не застрахованы от сценариев марша смерти, потому что это вопрос правильного использования фреймворков. Я видел, как многие проекты провалились, потому что используемые технологии использовались не по назначению.
Почему используемая технология имеет какое-либо отношение к плохому управлению? Мне кажется, это серьезно глупый вопрос. Если вы думаете, что технология вылечит плохое управление, вам нужно поработать над другими проблемами, прежде чем вы начнете выбирать технологию для использования.
Приятно говорить о том, что некоторые технологии Agile, но я думаю, что это на самом деле вводит в заблуждение. Я бы предпочел работать с командой (включая руководство и пользователей), которая действительно понимала Agile-образ мышления, но запрограммирована на Фортране, а не командой, которая выбрала Rails или Django, потому что они звучали круто, но не могли отличить скрам от спама. (Не в обиду любителям Фортрана намерены)