Только прежде чем читать, учтите тот факт, что я работаю в области разработки приложений на Java, потому буду рекомендовать средства учитывающие данную специфику. Также учтите, что это пока черновик, и ваши замечания (в том числе по орфографии и пунктуации) будут полезны :)
- В конце рабочего дня подведение краткого итога, и письменный ответ на три вопроса: что было сделано, какие проблемы возникли, что планируется сделать. Также неплохо предоставить данную информацию всей команде (электронная почта, внутренний блог), и если у них будет интерес, то они могут прочитать данный отчет. Полезность данной практики неоценима, каждый кто составляет отчет задумывается в конце дня над вопросом: а что он сегодня полезного сделал. И ради ответа на данный вопрос уже стоит использовать данную практику. Кстати, некоторые заметят что данная практика писутствует в Scrum методологии. Но я первый раз увидел ее на Иркутском Авиационном заводе, мне о ней рассказал один очень интересный человек.
- Все материалы по проекту должны быть сосредоточенны в одном месте. Например, ссылки на логи общения с заказчиком или URL, для репозиториев исходного кода. Порядок никогда не бывает лишним, а порой очень сильно способствует повышению производительности.
- Надо управлять требованиями заказчика. Что понимается под таким общим утверждением? Все просто, все запросы на изменея вносимые в проект от заказчика должны быть зафиксированны в электронном виде. В тяжелых случаях заказчик должен ставить подпись под каждым своим требованием. Да это бюрократия, да интереснее писать код, но без этого ваш проект имеет очень высокую вероятность провала. Хотя тут многое зависит от.
- После получения задания от заказчика надо объяснить своими словами что он хочет. Данная вещь очень важна, без нее очень часто реализовываются вещи которые хочет разработчик, а не заказчик. Хоть это и звучит дико, но тут надо искать компромис, ведь разработчик тоже не дурак и понимает к чему приведет реализация странных требований.
- Повесить на общее обозрение диаграмму описывающую архитектурные особеннности проекта. В идеале рядом с ней повесить диаграмму с ходом движения работ по проекту. Это позволит поднять уровень коммуникации между членами команды на принципиально иной уровень. Главное не забывать тыкать пальцем в элементы диаграмм при обсуждении проекта.
- Исходный код проекта должен хранится в системе контроля версий. Особенно это важно когда код пишет более одного человека, хотя я уже не представляю себе как можно писать код без системы контроля версий. Наверное у меня комплекс, но мне нужен хотя бы SVN для комфортной работы.
- Должна быть инструкция для настройки рабочего окружения по работе над проектом. Если данного документа нет, то получается истинный хаос при подключении нового человека в проект. Да и передача дел значительно затрудняется. Вики по проекту это идеальный вариант.
- Использование системы управления задачами. Наличие данной системы позволит более продуктивно исправлять различные проблеммы и не забывать про них. Не забывать это хорошо. Кстати, я рекомендую обратить внимание на Redmine.
- Наличие описания сборки проекта. Если каждый раз сборка проекта это череда магических пасов, и собрать проект может только единственный гуру в команде, то это бардак. Если будет описание процеса сборки приложения хотя бы в текстовом виде это значительно упростит работу работу всех членов команды, и избавит от ряда глупых вопросов. Идеальный вариант когда процесс сборки приложения автоматизирован (например при помощи Ant или Maven), тогда счастье разработчиков поистине безгранично.
- Разработка unit-тестов. Это очень противоречивая практика, иногда unit-тесты разрабатывать нецелесообразно, да и не все можно протестировать в рамках отведенного бюджета. Но когда unit-тесты есть и написанны правильно это очень сильно повышает уверенность разработчиков в устойчивости исходного кода. Тесты можно писать на JUnit.
- Использование системы непрерывной интеграции. Возможно вам это и не надо, но меня очень уж радует факт того, что каждый день происходит сборка системы, и возможно проходят все тесты. Это значительно повышает уверенность в разрабатываемой вами системе. Я рекомендую обратить внимание на системе непрерывной интеграции Hudson.
- С опаской относится к независящим от вас системам. Например ставить mvn-proxy репозиторий (я рекомендую Nexus), и пользовать его, а то вдруг глобальные репозитории упадут. Интернет ненадежная штука.
- Быть готовым к изменениям. Не все изменения одинаково полезны, но надо быть готовым принять разумные вещи и использовать их в своих целях. Я рекомендую использовать мозг.
И напоследок: не забывайте думать, прежде чем делать!
UPDATE 2010-06-09: причесанная версия данного текста на хабре.
