Как построить процесс работы единственного работника?

Question

[Владимир Грабко]

Я понял что проект сам не вытяну и разместил вакансию. Так как я впервые работаю как в команде так и руководителем я пишу сюда. (работник удалённый)

Я думаю как то так:

1. Работник для каждой фичи делает Git ветку и работает в ней
   
2. Как только фича запилена от присылает в виде пул реквеста мне код.
   
3. Я тестирую (так как нет тестировщиков) и смотрю на "качество кода" если ок то принимаю если нет то отклоняю с детальным описанием что и почему.
   

Что можно почитать по этому и как вообще правильно это делать с условием что у вас 1 работник? (для сотен я за 3 минуты нагуглю).

Answer 1

[Алексей Уколов]

А чем управление одним работником отличается от управления сотней, в разрезе фич и тестирования? Правильно, абсолютно ничем.

Comments

[xabesawiv]

Отличается.
И именно что принципиально.

С одним ты можешь и на словах его контролировать.
И вручную тесты его работ делать.

С сотней - все только зафиксировано в электронном виде и тесты автоматические.

[Алексей Уколов]

С одним ты можешь и на словах его контролировать.
И вручную тесты его работ делать.

Только если я сам себе враг и мне некуда девать нервы и время.

Answer 2

[Максим Кудрявцев]

Тебе нужен любой task-tracker. Мне сразу на ум приходят Jira, Asana, Redmine. Это место где ты будешь ставить задачи человеку.

Далее нужен git. Купи подписку с приватными репозитариями на github или поставь на свою VPS, например, OpenStack. Про модель ветвления gitflow слышал? Ознакомься, если нет, пригодится.

Если кода не много, то перед слиянием ветки своего сотрудника проверяй все руками. Если много - TDD в купе с любым CI-сервисом(travis-ci.org как пример) тебе в помощь.

В целом про управление почитай Тома де Марко "Deadline - роман об управлении проектами". Отличная книга на мой взгляд.

Comments

[kliss]

На битбакете есть бесплатные приватные репы.

Answer 3

[sim3x]

tdd добавь - так будет проще
будешь смотреть на качество тестов, а не компилировать глазами код

0. создал функциональный тест
1. создал ветку в репе + закоммитил проваленный тест
2. создал юнит тесты + закоммитил проваленные юнит тесты
3. создал код для прохождения тестов + закоммитил
4. пуш

Comments

[Владимир Грабко]

Спасибо.

[sim3x]

Владимир Грабко: на всякий случай
В первое время такой подход приведет к драматическому падению скорости написания кода
Но на длинной дистанции позволит избежать страха изменения кода

[Владимир Грабко]

sim3x: ну сейчас у меня сделано примерно тоже только на оборот. ) код потом тесты и потом слияние с мастером)

[sim3x]

Владимир Грабко: в таком подходе можно написать тест на то, что уже работает в другом месте

Answer 4

[xabesawiv]

Я бы ковырнул в сторону CI (drone.io, gitlab, ).
На первый взгляд избыточно.
Но зато потом позволяет существенно время сэкономить.

И slack

И никаких таск-мендеждеров не нужно. Все прекрасно видно в git issue.