ТЗ + Система управления проектами (PM, мы используем
feng office) + система контроля версий (SVN).
На первом этапе составляется ТЗ с планом работ и детализацией.
ПП: разработка модуля обработки испытания:
1. Адаптация модели данных: 4 часа,
2. Выборка из протокола данных: 2 типа протоколов по 2 часа на каждый + 1 час на отладку = 5 часов,
3. Разработка GUI: 3 контрола с графической обработкой * 4 часа на каждый + 2 контрола для таблиц * 1 час на контрол + 1 контрол общей информации * 0.5 часа = 14.5 часов
4. Тестирование GUI: 3 графической обработки * 0.5 часа = 1.5 часа
5. Разработка отчета: дизайн 16 часов + верстка 8 часов + отладка 16 часов = 40 часов
Итого: 60 часов
Составляем ТЗ на весь проект, добавляем от 50% до 200% запаса по времени. В дальнейшем ТЗ будет пересматриваться, работы будут переставляться, сроки сдвигать в меньшую или большую сторону, но фактически разработка займет рассчитанное время с небольшим отклонением. Правда на составление такого ТЗ уходит довольно много времени.
Далее контролировать исполнение необходимо по завершенным этапам в PM и сопоставленным им коммитам в системе управления версиями. Так же необходимо жестко контролировать работоспособность релизной ветки в SVN. Для длительной задачи необходимо создавать ветки, и только для минимальных изменений, которые не затронут работоспособность или были полностью протестированы, вести коммит в основную (ПП изменение дизайна GUI без изменения функциональной части).
При разработке вдвоем показала себя хорошей практика 1-го коммита в 1-4 часа в ветку и каждые 4-7 часов слияние веток. Большие изменения не накапливаются и оба работаем над актуальной версией. Для своих личных проектов стараюсь придерживаться такого же ритма. Главным преимуществом при разработке в одиночку является возможность быстрого отката последних изменений, да и затраты времени считать удобно.
Максимально допустимым сроком комита является 8 часов (1 рабочий день). Если интервал коммитов превышает этот срок, то возможны только 3 варианта: 1. Работа стоит, 2. Возникла серьезная проблема, 3. Задача слишком большая и нужно было ее более подробно детализировать. Если возникает именно 3-й случай, то нужно проверить ТЗ на похожие задачи и детализировать их. Так же коммит должен идти на каждое исправление бага, с обязательным оповещением остальных о необходимости срочно получить свежую версию.
Минимум 1 раз в неделю детальное обсуждение состояния проекта всем отделом(компанией, группой, нужное подчеркнуть), желательно с чек-листами проверки работы программы. Так же 1 раз в месяц можно требовать отчет о проделанной работе в письменном виде, возможно с пакетом документации на программу. Главное не забудьте внести в ТЗ минимум 4 часа в месяц на него (если с документацией, то минимум 8-16).
PS. Что касается выбора разработчика, то лучше всего попросите помочь в выборе знакомого программиста. Если его нет, то попросите кандидата прислать пример кода и оцените его на качество форматирования. Правила форматирования найти очень легко. Или попросите оценить код любого программиста, например с хабра, какого нибудь форума или еще откуда нибудь.
PSS. Удачи!