Simulic
Português

Sprint ágil de software – planejar, construir, testar, lançar

ComputaçãoCarreiras em computaçãoIdades 17–18

Carregando…

Compartilhar Relatar um problema

Uma pequena equipe de software faz um sprint ágil para criar um app de clubes escolares: escolha no backlog as histórias de usuário que cabem na capacidade da equipe e simule o sprint dia a dia. Os cartões passam pelas colunas A fazer, Em andamento, Testes e Pronto, um gráfico burndown acompanha os pontos restantes e os bugs criados ao programar são pegos pelos testes ou chegam aos usuários. O sprint termina com uma revisão que mede a satisfação do cliente.

Aula: Carreiras em desenvolvimento de software: o processo ágil e os papéis na equipe

O que mostra

Esta simulação mostra como uma equipe de software real trabalha durante um sprint ágil. O dono do produto ordenou por valor as histórias de usuário de um app de clubes escolares; a equipe assume as que cabem na sua capacidade, estimada como desenvolvedores × dias × 0,8 ponto. A cada dia, histórias são construídas, surgem bugs no código novo e os testes ou a revisão de código pegam parte deles. Pular os testes acelera a construção, mas mais bugs chegam aos usuários. Um gráfico burndown acompanha o progresso e a revisão do sprint mede a satisfação do cliente. Os coeficientes são suposições ilustrativas.

Como usar

Escolha uma opção de Planejamento ou marque você mesmo as histórias, ajuste Desenvolvedores, Testadores, Dias e Tempo em testes, e ligue ou desligue a revisão de código. Clique em Avançar 1 dia para percorrer o sprint ou em Rodar o sprint para animá-lo, e observe o quadro, a linha burndown e o contador de bugs. Compare a revisão do sprint após mudar um ajuste e use Outro cenário para ver a variação aleatória.

Parâmetros que você pode mudar

  • Planejamento do sprint Dentro da capacidade, Backlog inteiro, Escolher à mão
  • Número de desenvolvedores 2–6 pessoas
  • Número de testadores 0–2 pessoas
  • Duração do sprint 5–15 dias
  • Tempo dos desenvolvedores escrevendo testes 0–40 %
  • Revisão de código entre pares

Perguntas para explorar

  1. Quanto mais rápido a equipe constrói sem tempo em testes, e quantos bugs a mais chegam aos usuários?
  2. Por que assumir o backlog inteiro costuma reduzir a satisfação do cliente?
  3. O que cada papel (dono do produto, desenvolvedor, testador) contribui para um bom sprint?

Simulações relacionadas