Здравствуйте, Аноним, Вы писали:

А>0) выработать общий стиль кодирования
Это обязательно, если хотите обеспечить более легкую поддержку проекта. Каждый день проводить проверки и совместно разбирать отклонения от стандарта.

А>1) обязательное документирование нового кода, и постепенное документирование старого
Создание документации по проекту зависит от выбранной методологии разработки проекта.

А>2) ознакомить людей с design pattern-ами, и потребовать чтобы постепенно сотрудники осваивали их
А>3) периодически проверять как сотрудники применяют pattern-ы
Учить, конечно, надо, но архитектуру приложения должен создавать профессиональный архитектор. Если каждый "начинающий" программист будет вносить в общую систему свое видение архитектуры, то проект скорее всего скоро превратится в помойку.

А>4) важные модули разрабатывать самому
Утопия. Невозможно все делать самому. Необходимо чаще контролировать результат работы сотрудников.

Я бы посоветовал следущее (переработанный и дополненный вариант):
1. выбрать методологию разработки: Agile (типа XP) или nonAgile (типа RUP или MSF). Я больше склоняюсь к RUP, если система пишется под заказ, или в некоторых случаях к MSF, если делается коробочный продукт.
2. создать документ, регламентирующий процесс написания кода.
3. при использовании nonAgile методологии создать необходимую предварительную документацию, постоянно ее развивать и дополнять.
4. создать скелет архитектуры системы, постоянно развивать и дополнять архитектуру.
5. при написании кода использовать автоматизированное тестирование, контроль версионности, автоматизированная сборка версий.
6. хотя бы на начальных этапах производить каждый вечер Code Review (просмотр написанного кода всеми сотрудниками для поиска логических ошибок).
7. стараться совместно обсуждать все аспекты построения системы.
8. постоянно проводить обучение сотрудников.