Як ефективно працювати з програмістом

ТЗ + Система управління проектами (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. Що стосується вибору розробника, то найкраще попросіть допомогти у виборі знайомого програміста. Якщо його немає, то попросіть кандидата надіслати приклад коду і поставити рейтинг на якість форматування. Правила форматування знайти дуже легко. Або попросіть оцінити код будь-якого програміста, наприклад з Хабра, якого-небудь форуму або ще звідкись небудь.