Как создать команду и организовать современный процесс разработки на C#/.NET?
Как на сегодняшний день устроена работа команды разработчиков при создании внутреннего продукта (финансы, собственные платёжные карты, API, коммуникация с банками)? Интересует минимальное и/или среднее количество специалистов с их позициями (например, несколько разработчиков, тестировщик, тим лид, менеджер проекта), а также то, как должен быть организовать процесс работы и взаимодействия между ними + стек ПО (C# + Windows преимущественно), который необходимо использовать.
На входе имеется: команда из четырёх C# разработчиков, одного разработчика баз данных (T-SQL), двух лидов (один отвечает за поддержку продуктов, другой - за разработку, но оба -- C# разработчики), пары менеджеров проектов, троих специалистов тех. суппорта, одного системного администратора. Количество лидов для такой команды, возможно, высоко потому, что из команды ушли 3 разработчика в отдельный проект и ещё 1 уйдёт через 2 месяца. На данный момент планируется нанять 1-2 новых разработчиков и 1 тестировщика, как минимум. При разработке используется методология agile/scrum со спринтами, но без ежедневных стенд-апов. Также в команде как вид отсутствует тестирование и CI/CD. Используется SVN (не git), культуры разработки нет. Также имеется ещё одна команда разработчиков на аутсорсе.
На выходе хочется: полноценную команду, которая будет заниматься поддержкой старых проектов и разработкой новых по современным стандартам. Однако, понимая, что команда застряла где-то в каменном веке, хочется хотя бы с чего-то начать.
В данном случае они лишь формируют бэклог и транслируют желания бизнеса, не более. Ответить на вопросы о стеке технологий и ПО они не могут. Я думаю, с точки зрения методологии SCRUM они выполняют роль product owner у нас.
Однако, понимая, что команда застряла где-то в каменном веке, хочется хотя бы с чего-то начать.
Ну вот с гита и начните - он вам даст нормальные возможности и для тестирования и для CI.
Вы можете сказать - гит штука гибкая, нужно иметь какие-то требования к организации процесса чтобы подстроить под себя. Это верно, поэтому пока будете объяснять людям чем гит может быть полезен, сами поймёте что вам нужно.
Современный процесс разработки диктуется не языком и даже не платформой, а требованиями бизнеса к гибкости, коротким релизам и быстрому MVP, а также пониманием того, что "если они могут выкатываться 2 раза в день - то и нам бы надо почаще, чем раз в 3 месяца".
Как таковой задачи в частом выкатывании релизов нет. Задачи есть сервисные (багфиксинг, например) и девелоперские. Более того, как правило, на одном разработчике висит один проект. Кооперация максимум с БД-разработчиком и менеджером проектов. Тим лид сейчас осуществляет больше функцию скрам-мастера, наверное. В планах git и gitlab, а также ввод в команду тестировщика, но вот как качественно организовать работу и с каким стеком технологий -- пока всё туманно. За ответ спасибо.
Очень сильно не хватает структуризации.
Вам нужно поднять систему управления проектами, в которой вы сможете описать ваши проекты. Например, Redmine.(так как у него есть интеграция в svn, в комментариях к задачам будут отображаться коммиты)
Это поможет вам структурировать ваши проекты, будет некое физическое представление о проекте: список задач/идеи/багов. Будет очень сложно, так как людей нужно будет приучить все свои действия отражать в системе, указывать свои трудозатраты. Лидам и менеджерам проектов постоянно создавать и распределять задачи.
Очень важную роль правильно использование таких систем, что вам очень поможет в scrum.
Выбираете проект -> Создаете версию на будущий релиз -> Накидываете туда задач(очень важную роль играет правильно выставленная оценка трудозатрат, что позволит не перегружать программистов и оценивать фронт работ)
Здравствуйте, Дмитрий! Спасибо большое за ответ. Redmine мы используем уже примерно год. На данный момент работаем по двухнедельным спринтам. В понедельник распределяются задачи, в пятницу проводится промежуточный итог. 80% времени отделяется под основные таски, 20% под потенциальные сервисные, появляющиеся в течение спринта и только после того, как разработчик сообщит, что имеет время и возможность за него взяться. Интеграции с SVN у нас, увы, нет, но мы это решаем комментариями о статусе работ. Поскольку, как я уже сказал, у нас обычно один проект -- один разработчик (что не очень-то и хорошо), у нас до выката в SVN может пройти 90% времени разработки локально.
