4 min leitura • Guide 496 of 877
Lidando com Times Cross-Funcionais
Times cross-funcionais requerem coordenação entre diferentes disciplinas com workflows e ferramentas variadas. As configurações flexíveis de board do GitScrum, views baseadas em papel e espaços unificados de projeto ajudam designers, desenvolvedores, QA e product managers a colaborar seamlessly enquanto mantêm seus workflows especializados.
Estrutura de Time Cross-Funcional
| Papel | Contribuição | Envolvimento no Sprint |
|---|---|---|
| Product Owner | Requisitos, prioridades | Planning, review |
| Designer | Designs UX/UI | Design adiantado, review |
| Desenvolvedor | Implementação | Sprint inteiro |
| QA | Testing, qualidade | Review, fase de teste |
| DevOps | Deploy, infraestrutura | Conforme necessário |
Coordenação de Workflow
ABORDAGEM DE WORKFLOW ESCALONADO
Sprint N-1 │ Sprint N │ Sprint N+1
│ │
Design: [Feature C] │ [Feature D] │ [Feature E]
Projetando │ Projetando │ Projetando
↓ │ ↓ │
Dev: │ [Feature C] │ [Feature D]
│ Construindo │ Construindo
│ ↓ │
QA: │ │ [Feature C]
│ │ Testando
BENEFÍCIO: Cada papel tem trabalho em seu sprint
Sem esperar por handoffs dentro do sprint
Visualizando Trabalho Cross-Funcional
VIEW DE SWIMLANE POR PAPEL
┌─────────────────────────────────────────────────────────┐
│ Board Sprint 12 │
├─────────────────────────────────────────────────────────┤
│ A Fazer Em Progresso Review Done │
├─────────────────────────────────────────────────────────┤
│ Design │ [F5 UI] │ [F4 Review] │ │ [F3 Done]│
│ │ │ │ │ │
├─────────────────────────────────────────────────────────┤
│ Dev │ [F4 API] │ [F3 Build] │ [F3 PR] │ [F2 Done]│
│ │ │ [F3 Front] │ │ │
├─────────────────────────────────────────────────────────┤
│ QA │ [F2 Test]│ [F2 Auto] │ │ [F1 Done]│
│ │ │ │ │ │
└─────────────────────────────────────────────────────────┘
Cada papel pode ver seu pipeline
Gargalos visíveis pela fullness da swimlane
Planejamento de Capacidade por Papel
PLANEJAMENTO DE CAPACIDADE CROSS-FUNCIONAL
Capacidade Sprint 12 (em story points ou dias):
┌─────────────────────────────────────────────────┐
│ Papel Capacidade Planejado Disponível │
│ ───────────────────────────────────────────── │
│ Design 20 pts 18 pts 2 pts │
│ Frontend 40 pts 38 pts 2 pts │
│ Backend 40 pts 35 pts 5 pts │
│ QA 25 pts 25 pts 0 pts ⚠️ │
│ DevOps 10 pts 8 pts 2 pts │
│ ───────────────────────────────────────────── │
│ Total 135 pts 124 pts │
└─────────────────────────────────────────────────┘
ISSUE IDENTIFICADO: QA na capacidade total
AÇÃO: Desenvolvedores ajudam com automação de teste
Processo de Handoff
DEFINITION OF DONE PARA HANDOFFS
HANDOFF DESIGN → DESENVOLVIMENTO:
┌─────────────────────────────────────────────────┐
│ ☑ Designs finais no Figma (linkados à tarefa) │
│ ☑ Todos estados desenhados (vazio, erro, load) │
│ ☑ Specs de mobile responsivo incluídas │
│ ☑ Componentes do design system identificados │
│ ☑ Designer disponível para perguntas │
│ ☑ Critérios de aceitação atualizados │
└─────────────────────────────────────────────────┘
HANDOFF DESENVOLVIMENTO → QA:
┌─────────────────────────────────────────────────┐
│ ☑ Código completo e review de código feito │
│ ☑ Testes unitários passando │
│ ☑ Deployed em ambiente de staging │
│ ☑ Cenários de teste documentados │
│ ☑ Issues conhecidos documentados │
│ ☑ Dev disponível para correção de bugs │
└─────────────────────────────────────────────────┘
HANDOFF QA → RELEASE:
┌─────────────────────────────────────────────────┐
│ ☑ Todos casos de teste executados │
│ ☑ Nenhum bug P1/P2 pendente │
│ ☑ Teste de regressão completo │
│ ☑ Performance verificada │
│ ☑ Sign-off documentado │
└─────────────────────────────────────────────────┘