В процессе своего путешествия по разным компаниям насобиралась у меня целая пачка вопросов, которые обязательно следует спрашивать работодателя во избежание последующих недоразумений. Мой список был смёржен со списком, обнаруженным на хабре.
Вот что у меня получилось:
Процесс найма
- Этапы найма сотрудника на работу: количество собеседований, их последовательность и т.д.
Проект
- Описание проекта в деталях
- Структура команды на проекте
- Взаимодействие команды на проекте
- Возраст/опыт людей в команде
- Моя роль и обязанности
- Длительность проекта
- Используемые методологии разработки
- Какие типы тестирования применяются на проекте – unittesting, ручное, др.?
- Средства разработки
- Система контроля версий
- Система контроля требований
- Система трекинга багов
- Система трекинга заданий
- Какое количество времени будет выделено на “прокачку знаний до необходимого уровня”?
Компания, карьера и оплата
- Оплата компанией аренды жилья (срок, место)
- Релокейшн – оплачивается ли компанией переезд? Для всей семьи?
- Виза – какая виза для кандидата, для членов семьи? Оплачивается ли получение виз компанией?
- Как разруливается следующая ситуация – изначально я еду на работу как в командировку, компания пытается оформить мне визу, но визу в итоге не дают по каким-либо причинам?
- Структрура зарплаты (налог + netto + %банку + какой курс обмена)
- Зарплата(netto) до испытательного срока
- Зарплата(netto) после испытательного срока
- Длительность испытательного срока
- Условия успешного прохождения испытательного срока
- Выплачивается ли вовремя зарплата или бывают задержки?
- Дата выдачи зарплаты.
- Какие перспективы карьерного роста?
- Через сколько времени повышается зарплата и на сколько?
- Есть ли бонусы и от чего зависит их получение?
- Бывают ли корпоративные вечеринки?
- Какие отношения в коллективе?
- Условия работы?
- Есть ли столовая (внутри компании) или приходится ходить есть куда-то?
- Оплачиваются ли обеды и если да, то на какую сумму?
- Оплачивается ли проезд?
- Предоставляется ли компанией в пользование автомобиль?
- Есть ли командировки? Если есть, то как часто? Сколько дней в месяц/в год? Оплата командировочных?
- Предоставляет ли фирма бесплатное посещение бассейна, спортзала?
- Направляет ли фирма на какие-либо курсы?
- Проводятся ли семинары, конференции?
- Отгулы?
- Больничные (оплачиваются или нет)?
- Есть ли мед.страховки? Для сотрудника или для его семьи тоже? Что входит в медстраховку?
- Что происходит с людьми по окончанию проекта? Если на других проектах нет открытых позиций?
- В случае увольнения по инициативе компании выплачивается ли выходное пособие? Какое?
- За какой период времени компания предупреждает об этом?
- Дополнительные мотиваторы?
Отпуск
- Продолжительность в год? Календарных или рабочих дней?
- Оплачиваемый, неоплачиваемый?
- Через какой промежуток времени его можно взять?
- Можно ли взять его сразу или только по частям?
- Если не берёшь отпуск, то он прогорает? Можно ли взять деньгами и не ходить в него?
- Могу ли я взять отпуск за свой счет? Какое максимальное количество дней?
Рабочее время
- Со скольки до скольки?
- Сколько рабочих дней в неделю?
- Есть ли возможность работать по гибкому графику (раньше приходить и раньше уходить и наоборот)?
- Бывают ли случаи работы в выходные и сверхурочно, оплачивается ли такая работа и как?
- Есть ли выходные в официальные государственные праздники?
Контракт
- Что из вышеперечисленного будет прописано в контракте?
- На какой период подписывается контракт
Если есть что добавить – пишите, пожалуйста, в комментарии.
Янв 10
10
Процесс. Track them all.
Наконец-то созрел описать своё видение идеального процесса разработки.
Цикл разработки проекта в двух словах:
- Клиент просит написать нечто.
- Бизнес аналитик пишет требования к проекту.
- Пишутся тесты и код.
- После прогонки тестов требования корректируются, тесты обновляются, реализация обновляется.
- И так до тех пор, пока все тесты не будут соответствовать требованиям, и пока все тесты не будут проходить успешно. Ах да, про заказчика забыли – он должен подтвердить все требования.
- После этого проект можно считать как “соответствующий поставленным требованиям”.
- Конец.
Выделяем сущности из этого цикла:
- Требования
- Тесты
- Имплементация
Заказчиков, исполнителей, финансирование и прочее в рассмотрение пока что не берём. Рассматриваем чисто техническую сторону вопроса.
Достаточно ли сущностей, описаных выше, для достижения поставленной цели? Кстати, а цель какая? А цель (см п.6 выше) – написать проект таким образом, чтобы он соответствовал поставленным требованиям.
Итак, как мы собираемся определять, достигли ли мы цели?
А очень просто – достаточно выполнения 2х условий :
1) успешное прохождение тестов
2) полное покрытие тестами требований
С пунктом номер 1 всё понятно. А вот что с пунктом 2?
Пример : у нас есть какое-то требование и мы написали на него порцию тестов.
Тут приходит запрос на изменение этого требования. Требование меняется. После этого мы должны обновить или перепроверить и тесты.
Но как отследить зависимости между требованиями и тестами? Для этого понадобится еще одна сущность. Назовём её test validation link.
Содержимое test validation link :
- ID требования
- версия(hash?) требования
- ID теста
- версия(hash?) теста
После добавления test validation link в нашу инфраструктуру легко решаются следующие задачи:
- Обнаружение тестов, подлежащих верификации.
- Обнаружение несвязанных c требованиями тестов.
- Обнаружение не покрытых тестами требований.
Один тест может быть привязан к нескольким требованиям и каждое требование может быть связано с несколькими тестами.
Тут хочется особо подчеркнуть, что все сущности, включая требования и test validation link, должны лежать вместе в системе контроля версий:
Из этого можно будет извлечь пользу, если есть несколько веток проекта и приходится делать merge между ними. При этом можно будет “мёржить” весь проект целиком, включая требования. Естественно, что для этого формат сущностей должен обеспечивать безболезненный автоматический и ручной (в случае конфликтов) merge.
Вы наверное заметили, что test validation link содержит в себе версию теста и версию требования. Возможно, это должны быть хэш функции от контента. Т.к. номер ревизии здесь не совсем подойдёт из-за того, что ревизия может измениться после копирования требования в процессе “мёржа”.
Итак, теперь у нас присутствует 4 сущности :
- Требования
- Test validation links
- Тесты
- Имплементация
Попробуем нарисовать картинку нашего мини-процесса :
Выделяем активности, которые будут присутствовать на проекте:
- Изменение требования (включая добавление и удаление).
- Изменение теста (включая добавление и удаление).
- Изменение имплементации (включая добавление и удаление).
- Изменение test validation link (включая добавление и удаление).
С моей точки зрения, подобная инфраструктура в разработке проекта – необходимый минимум, который хорошо укладывается в различные процессы (Agile, Waterfall, …). К сожалению, далеко не все его, этот минимум, используют.
На сегодня всё, продолжение следует…
PS: Подскажите, а есть какое-то системы , в которых это всё интегрировано? Может, об этом могут сказать что-нибудь .NET разработчики, использующие TFS ?
Posted in Разработка by .
Окт 09
15
Привет, мир!
Всем здрасте!
Вот, решил завести себе блог и писать сюда различные технические статейки.
Пока что в планах первая статья – об идеальном процессе разработки с точки зрения девелопера.