Управление и планирование

Еще немного этих заметок на полях.


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

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

Практика "тестирование":
- это можно взять на моем сайте из моего доклада на РИТ2007

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

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

Может быть еще что-то. Писал по памяти, мог что-нибудь и упустить.

Это написал Green вот тут.