О разбиении задачи на самостоятельные части
Для успешной работы над большим проектом всегда должно быть четкое представление о том что нужно сделать, что именно уже сделано, и что именно осталось сделать. Понимание этого избавит от "топтания на месте", и позволит запустить прокт в срок. Ответ кроется в том, что если есть контроль над рабочим процессом, то отставание от графика будет заметно не за неделю до сдачи проекта, а на любом этапе разработки.
Но как именно можно контролировать процесс разработки? Большинство проектов пишется единой системой для которой есть только 2 состояния: "работает" и "не работает", причем к состоянию "работает" продукт приближается только на финальном этапе разработки. Не знаю существет ли для этой ситуации "закон Мерфи", но если нет, то явно стоит его создать. Любой программный продукт можно нормально оценить только на завершающем этапе разработки.
Как же быть с большими проектами, неужели на протяжении всей работы это будет "кот в мешке"? В подавляющем большинстве случаев - да. Залог успешной разработки проекта - это разделение задачи на составляющие части. Хочу отметить, я говорю не о поэтапном создании, а о полном разделении функционала, когда отдельная часть проекта становиться отдельной задачей.
Разбивать проект на задачи следует так, чтобы можно было полностью оценить выполненную задачу, независимо от состояния других задач. Такую задачу можно считать модулем (или компонентом) приложения. Это то правило, которым следует руководствоваться при разбиении системы на части. Соблюдение этого условия позволит работать приложению даже с плохой архитектурой, т.к. если в нем что-то не будет работать как нужно, то искать проблему (переделывать) нужно будет не все приложение, а только проблемную часть.
Хорошее представление об организации совместной работы над проектом дает изучение концепции компонентно-ориентированного программирования. В её основе находится модульная архитектура приложения на основе событийной модели. Из современных средств разработки на PHP, достаточно близки к реализации компонентной модели CMF Drupal и Yii Framework. Я не утверждаю что они более или менее близки, чем аналогичные системы, просто привожу примеры.
Типовое модульное приложения можно разделить на ядро и модули. Большинство функционала нужно стараться выносить в модули. Критерий попадания функционала в ядро - он используется в 90% модулях. Критерий попадания функционала в самостоятельный модуль - без него возможно функционирование системы. Оперируя этими правилами нужно производить разбиение проекта на части.