Как был устроен процесс разработки в вашей прошлой компании?

«Как был устроен процесс разработки в вашей прошлой компании?» — вопрос из категории Софт-скиллы, который задают на 24% собеседований PHP Разработчик. Ниже — развёрнутый пример ответа, который можно адаптировать под свой опыт.

Ответ

В моей предыдущей компании мы использовали адаптированную версию Scrum с двухнедельными спринтами для разработки на Symfony.

Ключевые этапы спринта:

  1. Планирование спринта: Команда (3 backend-разработчика, фронтенд, QA) совместно с Product Owner разбирала приоритетные задачи из Jira-бэклога. Мы оценивали сложность в story points (по Фибоначчи) и распределяли по доступной capacity команды.
  2. Разработка: Я брал задачу (например, "Реализовать API для экспорта отчетов"), создавал feature-ветку от develop по соглашению feature/EXPORT-123. После реализации писал юнит-тесты на PHPUnit и интеграционные тесты для API. Код сопровождался статическим анализом (PHPStan, Psalm).
  3. Code Review: Каждый Merge Request (MR) в GitLab требовал два апрува от коллег. Мы проверяли не только логику, но и соответствие PSR-стандартам, качество тестов и отсутствие уязвимостей (использовали GitLab SAST).
  4. CI/CD: После апрува MR запускался пайплайн:
    • composer install
    • phpunit
    • phpstan analyse
    • Деploy на staging-окружение.
  5. Тестирование: QA-инженер тестировал функционал на staging. При обнаружении багов создавались подзадачи в текущем спринте.
  6. Демо и ретроспектива: В конце спринта мы показывали инкремент продукта стейкхолдерам. После демо проводили ретроспективу по формату "Что прошло хорошо / Что можно улучшить", чтобы постоянно улучшать процесс.

Ежедневные активности:

  • Daily Stand-up (15 минут): Каждый отвечал на три классических вопроса, фокусируясь на блокерах.
  • Неформальные пары для решения сложных задач (например, проектирование сложной доменной логики).

Такой процесс обеспечивал предсказуемую поставку, высокое качество кода за счет автоматических проверок и быструю обратную связь.