Какая методология разработки ПО подходит под ситуацию?

#веб_программирование #методология

Структура проекта и текущая ситуация с его разработкой.

Разработчики проекта: 


верстальщики; 
js frontend программисты; 
дизайнеры; 
backend C# программисты.


Сервера:


тестовый (для верстки); 
beta (идут запросы ajax);
рабочий (production).


Есть система контроля версий source safe, но можно заходить на любой сервер и править
файл вручную, чем и занимаются все, когда делают правки. Из одного файла в другой копируют
код и сохраняют. Иногда данные теряются.

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

Очень часто делаются правки в рабочий код, css, js, вёрстку на лету без svn систем.
Это, в свою очередь, портит другой код и приходится снова делать правки. Из-за этого
срываются сроки.

Изменять архитектуру нельзя, сайт очень посещаемый и работает очень давно. 

Хочется выйти из этого порочного круга. Какая методология разработки может пригодиться
в данном случае?

Я подумываю о том, чтобы вести разработку проекта циклами и раз в неделю обновляться,
а любые изменения в верстке и дизайне блокировать, до следующего цикла?
    

Ответы

Ответ 1

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

То, что вы до сих пор используете Source Safe, то что ваши разработчики правят файлы
на продакшене напрямую - это не техническая проблема (что, кстати, делает этот вопрос
оффтопиком). Это проблема самоорганизации - ваша команда или не видит проблему, или
не хочет ее решать. Такую ситуацию нельзя исправить внешним воздействием. 

Скажем, вы остановитесь на схеме деплоя "раз в неделю". После деплоя вылезет срочная
проблема. Будете ждать неделю? Или начнете чинить приложение на живом сервере?

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