Tarefa e ticket — o que são, sistemas de rastreamento e trabalho com tarefas

O que é uma tarefa e um ticket?

Tarefa — uma unidade de trabalho registrada em um sistema de rastreamento. Contém descrição, prioridade (Critical, High, Medium, Low), responsável, prazo e status. No desenvolvimento mobile, uma tarefa pode ser “Adicionar tela de perfil com avatar”, “Implementar paginação do feed” ou “Atualizar targetSdk para 35”. Cada tarefa está vinculada a um projeto, sprint e a um desenvolvedor ou equipe específica.

Ticket — uma entidade mais ampla. Um ticket pode ser um relatório de bug (“App crasha ao girar a tela no Android 14”), uma solicitação de funcionalidade (“Adicionar suporte a tema escuro”), uma consulta de suporte técnico (“Notificação push não está chegando”) ou uma tarefa do gerente (“Preparar relatório de taxa de crash do mês”). A linha entre tarefa e ticket é difusa: no Jira, ambos os conceitos são combinados em Issue. A diferença chave: uma tarefa sempre tem um responsável, enquanto um ticket pode ser uma solicitação sem um responsável específico até a triagem.

No Scrum e Kanban, as tarefas são o elemento principal do backlog. Cada tarefa deve atender aos critérios INVEST (Independent, Negotiable, Valuable, Estimable, Small, Testable). Tarefas independentes podem ser implementadas em qualquer ordem. Estimáveis — a equipe pode estimar o esforço. Pequenas — cabem em um sprint. Testáveis — têm critérios de aceitação claros. Tarefas grandes (épicos) são divididas em tarefas menores até que todos os critérios sejam atendidos.

Tipos de tarefas no desenvolvimento mobile

Feature — nova funcionalidade do aplicativo. Exemplo: “Tela de login biométrico (Face ID / Touch ID)”. Tarefas Feature estão sempre vinculadas a uma história de usuário e têm Critérios de Aceitação. A estimativa é em story points (1, 2, 3, 5, 8, 13). Bug — um defeito encontrado durante o desenvolvimento ou teste. A prioridade do ticket de bug é determinada pela gravidade (crash → Critical, bug de UI → Medium, erro de digitação → Low). No desenvolvimento mobile, uma taxa de crash acima de 0,1% é um bug crítico que requer correção imediata.

Tech Debt / Chore — tarefas técnicas sem efeito visível para o usuário: atualização de bibliotecas (Dependency Bump), refatoração (Migração de ViewPager para ViewPager2), configuração de CI/CD, escrita de testes. Tarefas de Tech Debt são frequentemente subestimadas, embora de acordo com Stripe 2025, até 30% do tempo de uma equipe mobile é gasto em manutenção e pagamento de dívida técnica. Ignorar a dívida técnica leva ao aumento de bugs e à desaceleração do desenvolvimento de novos recursos.

Tipos adicionais: Spike (tarefa de pesquisa — explorar uma nova tecnologia, escrever um POC), Task (qualquer trabalho não relacionado a código — documentação, revisão de design), Improvement (melhoria de funcionalidade existente — otimização do tempo de carregamento da tela). No Jira, os tipos de issues são personalizáveis por projeto. O conjunto padrão para uma equipe mobile: Story, Bug, Task, Improvement, Epic. Epic — um grande tema que une várias histórias. Exemplo: “E-commerce: carrinho e finalização de compra”.

Ciclo de vida de uma tarefa: da criação ao fechamento

Open (To Do) — tarefa criada mas não iniciada. Contém descrição, Critérios de Aceitação, prioridade. Neste status, a tarefa deve passar pelo grooming (refinamento e estimativa) antes de entrar em um sprint. In Progress — o desenvolvedor começou a trabalhar. No desenvolvimento mobile, é importante vincular commits e pull requests à tarefa: no Jira via Smart Commits (APP-123 #comment fix bug), no GitHub/GitLab via palavras-chave na descrição do PR (Closes APP-123).

In Review — código enviado para revisão. Verificações automáticas: CI (Gradle build, lint, unit tests), SonarQube (qualidade do código), Danger (changelog, tests). O desenvolvedor não pode pegar a próxima tarefa enquanto a atual estiver em Review — isso evita multitarefa. QA / Testing — o testador verifica em dispositivos reais (Android — várias versões do SO e tamanhos de tela, iOS — diferentes modelos de iPhone). Se bugs forem encontrados, a tarefa volta para In Progress com um comentário.

Done (Closed) — tarefa concluída: código mesclado em main/master, testado, pronto para lançamento. Algumas equipes adicionam um status Deployed — a tarefa chega ao usuário apenas após o build ser publicado nas lojas. É importante fechar tarefas com um comentário sobre o resultado: qual versão, qual PR, quais métricas mudaram. De acordo com a Linear (2025), equipes que fecham tarefas com descrição do resultado têm 40% menos probabilidade de retornar às mesmas tarefas.

O ciclo de vida pode incluir um status Blocked — a tarefa não pode ser concluída devido a uma dependência externa (aguardando design, resposta do backend, aprovação do gerente). Tarefas bloqueadas devem ter um comentário com o motivo e a data da próxima verificação. Uma revisão semanal de tarefas bloqueadas ajuda a identificar atrasos sistêmicos no processo de desenvolvimento. Bloqueios com duração superior a 2 semanas requerem escalação ao nível do gerente de produto.

Sistemas de rastreamento de tarefas

Jira — o padrão da indústria para equipes de 10 ou mais. Suporta quadros Scrum e Kanban, personalização avançada de fluxo de trabalho, campos personalizados, automações e integração com Bitbucket/GitHub. Desvantagens: excessivo para equipes pequenas, UI lenta, configuração complexa. Para projetos mobile, o Jira é personalizado com: o plugin Mobile-specific fields (Platform, OS version, Device model), integração com TestFlight e Firebase Test Lab, e automação de builds de lançamento. Jira é a escolha para projetos empresariais com processos burocráticos.

Linear — um tracker moderno para equipes de produto. UI rápida, suporte de primeira classe para atalhos de teclado, Cycle integrado (análogo ao sprint), integração com GitHub e Slack. Vantagens: criação rápida de tarefas via CMD+K, distribuição automática em fases (Triaged → Backlog → Upcoming → Current → Completed), documentação e roadmaps integrados. Linear é escolhido por startups e equipes de produto que valorizam velocidade. Em 2025, 40% dos novos projetos mobile usam Linear.

Trello — um quadro kanban simples para equipes pequenas (2–5 pessoas). Cartões com listas de verificação, etiquetas, prazos. Desvantagem: não tem sprints, análise limitada, difícil de escalar. YouGile — um análogo russo do Trello com quadros kanban, chat e videochamadas. Asana — um tracker focado em projetos e cronogramas. A escolha do tracker depende do tamanho da equipe, orçamento e preferências: Jira para empresas, Linear para equipes de produto, Trello/YouGile para startups. Importante: a ferramenta deve ser unificada para toda a equipe — designers, desenvolvedores, QA, gerentes trabalham em um único sistema.

Melhores práticas para gerenciamento de tarefas

Escreva Critérios de Aceitação — os critérios de aceitação devem ser específicos e verificáveis. Ruim: “Tela de login funciona”. Bom: “O usuário insere email e senha, clica em Entrar. Se os dados estiverem corretos — navega para a tela principal. Se incorretos — mostra o erro “Email ou senha inválidos””. Os Critérios de Aceitação (CA) são o contrato entre o desenvolvedor, o testador e o gerente de produto. Sem CA, uma tarefa não atende à Definition of Ready (DoR) e não deve entrar em um sprint.

Vincule tudo. Commits, PRs, casos de teste, maquetes de design (Figma), discussões no Slack — tudo deve estar vinculado à tarefa. No Jira, isso é feito por meio de links nos comentários; no Linear, por meio da vinculação automática de PR. A regra de um clique: da tarefa ao design/código/testes — não mais que um clique. O desenvolvedor abre a tarefa e vê imediatamente a maquete no Figma, o link do PR e os casos de teste. Isso acelera a integração de novos membros da equipe em 30% de acordo com a Linear (2025).

Não crie tarefas fantasma. Uma tarefa sem descrição, sem CA e sem prioridade é lixo. Se na daily ninguém se lembra por que uma tarefa foi criada — ela deve ser excluída ou esclarecida. A regra das 48 horas: se uma tarefa esteve em status In Progress sem atividade por 48 horas, o desenvolvedor deve deixar um comentário sobre os motivos do atraso. De acordo com o Jira (2025), 60% das tarefas inativas por mais de 3 dias acabam sendo fechadas sem conclusão.

Decomposição de tarefas: épicos, histórias de usuário e subtarefas

Épico (Epic) — uma grande área funcional que une muitas histórias. Exemplo: “Onboarding do usuário” inclui “Tela de boas-vindas”, “Seleção de interesses”, “Upload de avatar”, “Configurações de notificação”. História de usuário (User Story) — uma tarefa da perspectiva do usuário. Formato: “Como [papel], quero [ação] para [valor]”. Exemplo: “Como usuário, quero fazer login com biometria para não ter que digitar minha senha toda vez”. As Histórias de Usuário são escritas pelo gerente de produto ou pelo product owner.

Subtarefa (Sub-task) — decomposição do trabalho técnico dentro de uma Story / Task. Exemplo para a Story “Tela de perfil”: Subtarefa 1: Construir UI (XML / SwiftUI), Subtarefa 2: Conectar ao ViewModel, Subtarefa 3: Escrever Testes Unitários, Subtarefa 4: Testes de Snapshot, Subtarefa 5: Testes de UI (Espresso / XCUITest). Regra de decomposição: cada subtarefa é concluída em 1–2 dias. Se um desenvolvedor estimar uma subtarefa mais longa — divida ainda mais. Subtarefas são uma técnica interna da equipe, não são visíveis no backlog do produto. A soma das estimativas das subtarefas não é necessariamente igual à estimativa da Story pai (parte do trabalho é comunicação, code review, testes).

Pirâmide de decomposição: Epic (Trimestre / Semestre) → Feature / Story (Sprint) → Task (1–3 dias) → Sub-task (Várias horas). A técnica INVEST ajuda a verificar a qualidade da decomposição. Se uma tarefa não é Independent (depende de outras) — isso sinaliza decomposição incorreta. Se uma tarefa não é Small (mais de 8 story points) — precisa de mais divisão. Padrão comum: Epic → 5–15 Stories → cada Story → 3–8 Sub-tasks. A estimativa final do épico = soma das estimativas das Stories, mas o primeiro sprint geralmente dá uma margem de erro de 20–30% nas estimativas.

Erros comuns ao trabalhar com tarefas

Erro 1: tarefas muito grandes. Uma tarefa de 2 semanas é um épico que precisa de decomposição. Tarefas grandes não podem ser integradas ao rastreamento diário; ficam em In Progress por semanas. Regra: tamanho máximo de tarefa — 2–3 dias de trabalho. Tudo maior deve ser decomposto. Efeito colateral: o desenvolvedor sente progresso ao fechar 2–3 tarefas por semana em vez de uma gigantesca. Isso aumenta a motivação e a previsibilidade do cronograma.

Erro 2: falta de Critérios de Aceitação. O desenvolvedor implementou a funcionalidade, o testador verificou — tudo bem. O gerente: “Onde está o botão de editar?” — “Não estava na tarefa”. Sem CA, cada parte entende a tarefa de forma diferente. Resultado: retrabalho, conflitos, prazos perdidos. CA é um contrato: se a tarefa não tem critérios, não está pronta para o sprint. No grooming, a primeira coisa verificada é a presença de CA. Se faltar CA, a tarefa é devolvida ao Gerente de Produto para refinamento.

Erro 3: esquecer a dívida técnica. A equipe só faz tarefas Feature sprint após sprint. Seis meses depois: a compilação leva 15 minutos, o Gradle está 3 versões principais atrasado, os testes falham no CI devido a deprecações. Solução: reservar 20% do tempo da equipe para Tech Debt (prática do Google SRE “Orçamento de erros baseado em SLO”). Crie pelo menos uma tarefa de Tech Debt para cada sprint de Features. Proporção: para cada 3 tarefas Feature — 1 Tech Debt ou Bug. Isso evita o acúmulo de dívida técnica e mantém a velocidade de desenvolvimento.