- Dev & Production сервера понятно. Нужно ли делать локал-сервер у разработчика? Стоит ли физически разделять дев и продакшен или достаточно разных виртуал-хостов и баз данных?
Зависит от масштаба проекта. На начальном этапе у разработчика всегда должна быть возможность проверить написанное локально -- это быстро и удобно. Как, например, в моем случае встроенный сервер Django. В будущем, когда проект становится большим -- можно прибегнуть к автоматизации этого процесса через среды сборки на тестовые стенды.
Физически (как я понял по разным железкам) разделять dev и prod имеет смысл только тогда, когда это требуется для правильного функционирования системы (т.е. prod занимает ресурсы физического сервера на 70-80%).
Когда дойдете до таких масштабов -- решение само придет. Сейчас идите по пути максимального сокращения расходов (VPS или один выделенный сервер в ДЦ).
Кстати, советую сразу откинуть идеи (если такие появляются в команде) "да у меня дома комп мощный, на первое время потянет", т.к. переносить все равно придется в скором времени из-за ряда неудобств.
А в качестве выделенного сервера хорошо подойдет
https://www.soyoustart.com/ie/essential-servers/ с установленным VMware ESXi. Дальше уже крутите виртуалки какие хотите.
- Где и какие делать репозитории кода? Никаких серверов у нас в офисе не будет и собственно самого офиса тоже ;)
Путь 1: Github/Bitbucket в облаке
Путь 2: GitLab/Bitbucket Server у себя на сервере.
- Нужна ли специализированная task management (типа, Jira)? Сейчас используем для управления задачами WorkSection. Стоит ли для разработки использовать что-то отдельное специализированное? Я так понимаю, что та же Jira может отслеживать коммиты в git как процесс выполнения задач - это было бы круто!
Нужна! И это должно быть с нулевого дня начала вашей работы. Иначе, когда зашьетесь в тоннах переписок в месенджерах и Google Docs'ах, будете вспоминать тот день, когда было лень потратить время на организацию работы.
- нужен ли отдельный баг-трекер? Выделенных тестировщиков пока не предвидится.
Для кого? Для пользователей вашим софтом? См. ответ выше.
- Стоит ли использовать Scrum? Или просто тупо идти по задачам?
Тупо идти по задачам никогда не получится. Нет такой самоорганизации у людей. Получите гораздо больше головной боли в решении косяков других людей в своей роли ПМ. Изучите методологии. Мы используем Scrum + TDD.
- Нужна ли какая то вики для отдела разработки? Что туда записывать, чтобы это не было большим оверхедом для разрабов и имело реальную пользу.
Нужна! Вот прям как трекер задач. И привычка туда записывать все по проекту тоже нужна. Разрабатываете API -- супер! Сначала опишите его в Вики, потом начинайте кодить. И все в таком духе. Все полезные ссылки по проекту, доступы к стендам и пр. -- все надо хранить не в переписке или облаках, а и именно в единой отправной точке.
Еще удобно использовать тот же Confluence для проведения встреч. Там есть готовые шаблоны для этого. Позволяет легко фиксировать все вопросы и принятые решения.
- Что еще забыл?
Способы ведения проекта в Git забыли, такие как GitFlow.
Контейнеризация от Docker для упрощения/ускорения работы разработчиков/тестеров/админов.
PS. Еще один вопрос не могу понять: должны ли запросы на доработки софта идущие от других отделов проходить через меня как управляющего разработкой (я оцениваю целесообразность и ставлю задачу разрабам)
Должны.
или лучше чтобы они напрямую контачили с разработчиками?
Напрямую с разрабом -- только для обсуждения уже поставленной в план задачи, а для постановки задачи -- с ПМ и всей командой (если Scrum)
Не будет ли это с моей стороны лишней тратой времени?
Это -- ваша непосредственная работа.
Средний
