Вот что у меня получилось:

Процесс найма

1. Этапы найма сотрудника на работу:  количество собеседований, их последовательность и т.д.

Проект

1. Описание проекта в деталях
2. Структура команды на проекте
3. Взаимодействие команды на проекте
4. Возраст/опыт людей в команде
5. Моя роль и обязанности
6. Длительность проекта
7. Используемые методологии разработки
8. Какие типы тестирования применяются на проекте – unittesting, ручное, др.?
9. Средства разработки
10. Система контроля версий
11. Система контроля требований
12. Система трекинга багов
13. Система трекинга заданий
14. Какое количество времени будет выделено на «прокачку знаний до необходимого уровня»?

Компания, карьера и оплата

1. Оплата компанией аренды жилья (срок, место)
2. Релокейшн – оплачивается ли компанией переезд? Для всей семьи?
3. Виза – какая виза для кандидата, для членов семьи? Оплачивается ли получение виз компанией?
4. Как разруливается следующая ситуация – изначально я еду на работу как в командировку, компания пытается оформить мне визу, но визу в итоге не дают по каким-либо причинам?
5. Структрура зарплаты (налог + netto + %банку + какой курс обмена)
6. Зарплата(netto) до испытательного срока
7. Зарплата(netto) после испытательного срока
8. Длительность испытательного срока
9. Условия успешного прохождения испытательного срока
10. Выплачивается ли вовремя зарплата или бывают задержки?
11. Дата выдачи зарплаты.
12. Какие перспективы карьерного роста?
13. Через сколько времени повышается зарплата и на сколько?
14. Есть ли бонусы и от чего зависит их получение?
15. Бывают ли корпоративные вечеринки?
16. Какие отношения в коллективе?
17. Условия работы?
18. Есть ли столовая (внутри компании) или приходится ходить есть куда-то?
19. Оплачиваются ли обеды и если да, то на какую сумму?
20. Оплачивается ли проезд?
21. Предоставляется ли компанией в пользование автомобиль?
22. Есть ли командировки? Если есть, то как часто? Сколько дней в месяц/в год? Оплата командировочных?
23. Предоставляет ли фирма бесплатное посещение бассейна, спортзала?
24. Направляет ли фирма на какие-либо курсы?
25. Проводятся ли семинары, конференции?
26. Отгулы?
27. Больничные (оплачиваются или нет)?
28. Есть ли мед.страховки? Для сотрудника или для его семьи тоже? Что входит в медстраховку?
29. Что происходит с людьми по окончанию проекта? Если на других проектах нет открытых позиций?
30. В случае увольнения по инициативе компании выплачивается ли выходное пособие? Какое?
31. За какой период времени компания предупреждает об этом?
32. Дополнительные мотиваторы?

Отпуск

1. Продолжительность в год? Календарных или рабочих дней?
2. Оплачиваемый, неоплачиваемый?
3. Через какой промежуток времени его можно взять?
4. Можно ли взять его сразу или только по частям?
5. Если не берёшь отпуск, то он прогорает? Можно ли взять деньгами и не ходить в него?
6. Могу ли я взять отпуск за свой счет? Какое максимальное количество дней?

Рабочее время

1. Со скольки до скольки?
2. Сколько рабочих дней в неделю?
3. Есть ли возможность работать по гибкому графику (раньше приходить и раньше уходить и наоборот)?
4. Бывают ли случаи работы в выходные и сверхурочно, оплачивается ли такая работа и как?
5. Есть ли выходные в официальные государственные праздники?

Контракт

1. Что из вышеперечисленного будет прописано в контракте?
2. На какой период подписывается контракт

Если есть что добавить – пишите, пожалуйста, в комментарии.

Цикл разработки проекта в двух словах:

1. Клиент просит написать нечто.
2. Бизнес аналитик пишет требования к проекту.
3. Пишутся тесты и код.
4. После прогонки тестов требования корректируются, тесты обновляются, реализация обновляется.
5. И так до тех пор, пока все тесты не будут соответствовать требованиям, и пока все тесты не будут проходить успешно. Ах да, про заказчика забыли – он должен подтвердить все требования.
6. После этого проект можно считать как «соответствующий поставленным требованиям».
7. Конец.

Выделяем сущности из этого цикла:

1. Требования
2. Тесты
3. Имплементация

Заказчиков, исполнителей, финансирование и прочее в рассмотрение пока что не берём. Рассматриваем чисто техническую сторону вопроса.

Достаточно ли сущностей, описаных выше, для достижения поставленной цели? Кстати, а цель какая? А цель  (см п.6 выше) – написать проект таким образом, чтобы он соответствовал поставленным требованиям.

Итак, как мы собираемся определять, достигли ли мы цели?

А очень просто – достаточно выполнения 2х условий :

1) успешное прохождение тестов

2) полное покрытие тестами требований

С пунктом номер 1 всё понятно. А вот что с пунктом 2?

Пример : у нас есть какое-то требование и мы написали на него порцию тестов.

Тут приходит запрос на изменение этого требования. Требование меняется. После этого мы должны обновить или перепроверить и тесты.

Но как отследить зависимости между требованиями и тестами? Для этого понадобится еще одна сущность. Назовём её test validation link.

Содержимое test validation link :

1. ID требования
2. версия(hash?) требования
3. ID теста
4. версия(hash?) теста

После добавления test validation link в нашу инфраструктуру легко решаются следующие задачи:

• Обнаружение тестов, подлежащих верификации.
• Обнаружение несвязанных c требованиями тестов.
• Обнаружение не покрытых тестами требований.

Один тест может быть привязан к нескольким требованиям и каждое требование может быть связано с несколькими тестами.

Тут хочется особо подчеркнуть, что все сущности, включая требования и test validation link, должны лежать вместе в системе контроля версий:

Из этого можно будет извлечь пользу, если есть несколько веток проекта и приходится делать merge между ними. При этом можно будет «мёржить» весь проект целиком, включая требования. Естественно, что для этого формат сущностей должен обеспечивать безболезненный автоматический и ручной (в случае конфликтов) merge.

Вы наверное заметили, что test validation link содержит в себе версию теста и версию требования. Возможно, это должны быть хэш функции от контента. Т.к. номер ревизии здесь не совсем подойдёт из-за того, что ревизия может измениться после копирования требования в процессе «мёржа».

Итак, теперь у нас присутствует 4 сущности :

1. Требования
2. Test validation links
3. Тесты
4. Имплементация

Попробуем нарисовать картинку нашего мини-процесса :

Выделяем активности, которые будут присутствовать на проекте:

1. Изменение требования (включая добавление и удаление).
2. Изменение теста (включая добавление и удаление).
3. Изменение имплементации (включая добавление и удаление).
4. Изменение test validation link (включая добавление и удаление).

С моей точки зрения, подобная инфраструктура в разработке проекта – необходимый минимум, который хорошо укладывается в различные процессы (Agile, Waterfall, …). К сожалению, далеко не все его, этот минимум, используют.

На сегодня всё, продолжение следует…

PS: Подскажите, а есть какое-то системы , в которых это всё интегрировано? Может, об этом могут сказать что-нибудь .NET разработчики, использующие TFS ?

Вот, решил завести себе блог и писать сюда различные технические статейки.

Пока что в планах первая статья – об идеальном процессе разработки с точки зрения девелопера.