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

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

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

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


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


Сервера:


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


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

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

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

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

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

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

Ответы

Ответ 1

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

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

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

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

Как эффективней писать ПО

Пишу средний проект на java. Сроки довольно сжатые. Как лучше распределить свое время: 1.Писать код по намеченной логике, и уже в конце начать его тестировать. 2.Или разбить логику на под задачи и писать/тестировать по кусочкам.
Второй способ кажется логичней, но допустим написав 1-5 пункты своей задачи и протестировав я пойму что 8 и 9 пункты вынуждают меня 1-5 пункты переписать. Так собственно и произошло, поэтому я этот вопрос и задаю. В итоге время на тесты было потрачено впустую.
И если есть хорошие статьи на эту тему буду благодарен.

Ответ

Agile (итеративное) управление проектом удлиняет сроки разработки (во втором варианте вы по сути описываете именно agile технологию), но минимизирует риски не неверного проектирования.
К сожалению в 90% проектов при написании ТЗ (или планировании проекта) невозможно на 100% сразу определить все возможные проблемы. Как правильно отметили вы же сами ответили, проект после какой-то стадии начинает жить своей собственной жизнью, а именно:
1-5 пункты своей задачи и протестировав я пойму что 8 и 9 пункты вынуждают меня 1-5 пункты переписать.
Если проект небольшой или вы уверены в том, что риски неверного проектирования минимальны, то можно сразу писать и тестировать в конце.
Можно выбрать другой способ разбить задачу не на 8-9 пунктов, а только на 2-3 пункта ибо чем больше пунктом/итераций, тем более вы даете свободу нелинейности проектирования, зато чем меньше пунктов, тем больше рисков неверного проектирования.
Соответственно, вам нужно определить этапы/итерации проекта не исходя из внутренней логики проекта, а исходя из рисков неверного проектирования, то есть если вы видите в проекте, скажем 10 логических этапов, из которых 5 вам хорошо понятны, а еще 5 "темный лес", то имеет смысл проект разделить на 6 этапов: на 1 этап в котором собрать 5 понятных вам пунктов, а 5 непонятных так и оставить как 5 этапов. Понятно, что такое не всегда возможно, но тем не менее - как общая идея.