Ответ
Состав зависит от методологии и масштаба проекта. В типичной кросс-функциональной Agile-команде можно выделить следующие ключевые роли:
| Роль | Основные обязанности |
|---|---|
| Product Owner (PO) | Формирует видение продукта, управляет бэклогом, определяет приоритеты задач. Связующее звено между бизнесом и командой. |
| Business Analyst (BA) | Детализирует требования, пишет пользовательские истории, прорабатывает acceptance criteria. |
| Team Lead / Tech Lead | Обеспечивает техническое руководство, архитектурные решения, менторинг разработчиков, устраняет блокеры. |
| Backend-разработчик | Разрабатывает серверную логику, API, работу с БД, интеграции. (Например, на Java/Spring). |
| Frontend-разработчик | Создаёт пользовательский интерфейс, реализует клиентскую логику. (Например, на React/Angular). |
| QA-инженер (тестировщик) | Планирует тестирование, пишет и выполняет тест-кейсы, автоматизирует тесты (UI, API), обеспечивает качество. |
| DevOps-инженер | Настраивает CI/CD пайплайны, инфраструктуру (контейнеризация, оркестрация), мониторинг, обеспечивает deploy. |
| UX/UI-дизайнер | Проектирует пользовательский опыт, создаёт макеты и прототипы интерфейса. |
Пример взаимодействия для реализации фичи:
- PO/BA описывает историю: "Как пользователь, я хочу видеть список своих заказов".
- Backend создаёт REST API эндпоинт:
@RestController @RequestMapping("/api/orders") public class OrderController { @GetMapping public List<OrderDto> getUserOrders(@AuthenticationPrincipal User user) { return orderService.findByUser(user); } } - Frontend разрабатывает компонент, который вызывает этот API и отображает данные.
- QA автоматизирует тесты для API и UI этого функционала.
- DevOps обеспечивает деплой новой версии приложения на staging/production.
Ответ 18+ 🔞
А, состав команды, да? Ну это ж классика, как "Муму" Тургенева, только без утоплений, блядь. Сейчас разложу по полочкам, но сразу предупреждаю — если у вас в команде один человек на три роли, это уже не Agile, а ёбаный цирк с конями, где все жонглируют горящими факелами над пропастью.
Смотри, в нормальной, не обосранной Agile-команде, роли обычно такие:
| Роль | И чем они, блядь, страдают |
|---|---|
| Product Owner (PO) | Этот чувак — царь и бог видения. Он решает, что строим: хрустальный дворец или сортир. Весь бэклог у него в голове и в Jira. Если он мудак — проект летит в пизду. |
| Business Analyst (BA) | А это переводчик с языка бизнес-идиотов на человеческий. Бизнес говорит: "Хочу волшебную кнопку!" BA пишет историю: "Как пользователь, я хочу нажать кнопку 'Сделать всё хорошо', чтобы система всё сделала хорошо, но без конкретики, что такое 'хорошо'". |
| Team Lead / Tech Lead | Главный по техническому шаманству. Он должен знать, почему сервер упал, пока ещё все только подозревают, что он упадёт. Ещё он разгребает технический долг, который накопили, как говна за сараем. |
| Backend-разработчик | Тот, кто делает всю чёрную магию, чтобы кнопка, на которую нажал пользователь, хоть что-то делала. Пишет код, от которого потом фронтендеры дергаются. |
| Frontend-разработчик | Художник, который делает так, чтобы кнопка блестела, плавно анимировалась и чтобы пользователь не захотел выбить себе глаз, глядя на интерфейс. |
| QA-инженер | Профессиональный пессимист и скептик. Его работа — пытаться сломать то, что с любовью собрали разработчики. И он всегда найдёт, как это сделать. Без него — доверия ебать ноль. |
| DevOps-инженер | Колдун, который заставляет код не просто работать на компе у Вани, а летать где-то в облаках. Если он ушёл в отпуск — все замирают в ужасе, потому что деплоить становится некому. |
| UX/UI-дизайнер | Человек, который рисует красивые картинки, а потом все дружно спорят, почему кнопка должна быть именно оранжевой, а не зелёной. |
Ну и как эта братва, блядь, обычно работает на примере? Допустим, надо сделать список заказов.
- PO/BA выдают: "Слушайте, пользователь хочет видеть, куда он бабки дел. Сделайте ему список заказов, чтобы не нервничал". Пишут историю, где куча воды и ни одного конкретного условия.
- Backend чешет репу, открывает IDE и пишет что-то вроде:
@RestController @RequestMapping("/api/orders") public class OrderController { @GetMapping public List<OrderDto> getUserOrders(@AuthenticationPrincipal User user) { return orderService.findByUser(user); } }Говорит: "Всё, блядь, API готово. Данные отдаю. Ваша проблема теперь их показывать".
- Frontend получает этот API и начинает колдовать: "Окей, данные приходят. А как их сортировать? А пагинацию кто делать будет? А если список пустой — показывать грустного смайлика?" Делает красивую табличку, которая на мобилке разъезжается к хуям.
- QA смотрит на это и думает: "А что, если у пользователя 10 000 заказов? Сервер не сдохнет? А если передать ему левый user_id? А если нажать F5 100 раз подряд?" Пишет кучу тестов, половину из которых падает.
- DevOps в это время пьёт кофе, но потом заходит в CI/CD пайплайн, видит, что тесты прошли, и одним щелчком отправляет эту фичу на прод. И молится, чтобы ничего не отвалилось.
Вот так, примерно. Главное — не забывать, что если все эти люди не будут разговаривать друг с другом, то получится не фича, а пиздец полный. Каждый будет в своей песочнице ковыряться, а в итоге пользователь получит оранжевую кнопку, которая красиво анимируется, но при нажатии отправляет его заказы в никуда.