Давай прикинем, какие бывают роли в проектах и какого вклада ждать от каждого представителя команды.
– Разработчик – «производитель» программного кода и, собственно, создатель программного продукта. Именно он создает осязаемый результат. Главный его вклад – регулярное производство новых функций и возможностей в финальном продукте.
– Ведущий разработчик / техлид – тот же разработчик, но способный принимать архитектурные и сложные технические решения относительно разработки. Как правило, это самый опытный из разработчиков, хлебнувший горя (зачеркнуто) и сделавший несколько реальных проектов. Его вклад в результат – организация разработки от локального кода до выкладки в промышленную эксплуатацию, качество кода, его документирования, технические метрики продукта, показывающие, что система «жива». Этот специалист отвечает за непрерывность, скорость и качество написания кода всеми разработчиками.
– Аналитик, дизайнер, архитектор, проектировщик – довольно близкие по смыслу роли. Это специалисты, способные представить будущий продукт в виде модели: процессов, сценариев, дизайнов интерфейса, модулей, сервисов, объектов и компонент. Зачем? Да чтобы уменьшить вероятность ошибки в разработке. Чем шире и качественнее проведено предварительное моделирование, тем меньше вероятность, что разработчики «выбросят» уже написанный код из-за появившихся уточнений/требований.
Их результат – архитектурная схема, концепция, описание сценариев и состав пользовательских экранов, постановка задачи в разработку.
– Тестировщики, они же QA/QC-специалисты, они же специалисты по контролю качества. Их ключевая цель – дать вселенной увидеть ровно тот результат, который нужен на самом деле. Их результат – отсутствие замечаний и ошибок в будущей системе и факт того, что система работает «как надо», т. е. поддерживает целевые процессы.
– DevOps-инженер организует и настраивает инфраструктуру как для самой команды, так и для будущей реальной системы. На старте, как правило, тесно работает с техлидом, чтобы организовать рабочее пространство команды так, как тот задумал. Его результат – правила сборки кода каждого разработчика в общий репозиторий и настроенные окружения:
– DEV, т. е. для разработки;
– QA для тестирования;
– UAT (user acceptance testing), предназначенный для приемки продукта.