Desenvolvimento ágil fluxo do processo

  • Versão de lançamento: Yokohama
  • Atualizado 30 de jan. de 2025
  • 4 min. de leitura
  • Aprenda o processo usado para gerenciar esforços de desenvolvimento de produtos em Desenvolvimento ágil 2.0, como criar um produto ou acompanhar um sprint ou versão.

    Nota:
    O fluxo explicado aqui representa a prática comum para gerenciar esforços de desenvolvimento ágil usando a funcionalidade disponível na aplicação Desenvolvimento ágil 2.0. Este fluxo não representa o único processo possível.
    Definir produtos

    Um produto pode ser um conjunto de recursos ou funcionalidades oferecidos aos usuários. Cada produto pode ter um proprietário que mantém o pipeline de trabalho, como épicos e histórias, para o produto. Esses itens de trabalho podem ser associados a um tema, que está relacionado a um objetivo de negócio.

    Consulte Criar um produto no Desenvolvimento ágil 2.0.

    Criar épicos e histórias

    Os épicos contêm requisitos de alto nível para seus produtos, que você pode usar para dividir em histórias gerenciáveis. Ao criar épicos e histórias em Desenvolvimento ágil 2.0, você pode associá-los a um produto.

    Consulte Criar um épico no Desenvolvimento ágil 2.0 e Criar uma história no Desenvolvimento ágil 2.0.

    Criar versões

    Algumas organizações têm um intervalo de tempo fixo para disponibilizar seus produtos ao mercado, o que é conhecido como versão. Uma versão tem uma data de início e uma data de término, durante as quais várias iterações de desenvolvimento são concluídas. Por exemplo, você pode ter cronogramas trimestrais ou semestrais para liberar novas aplicações ou melhorias em aplicações existentes.

    Depois de criar uma versão em Desenvolvimento ágil 2.0, você pode associar produtos, épicos e histórias a ela. Consulte Criar uma versão no Desenvolvimento ágil 2.0.

    Criar backlogs personalizados

    Um backlog personalizado pode ser criado definindo critérios de filtro. Por exemplo, um backlog personalizado pode ser uma combinação de histórias, defeitos e incidentes, enquanto o outro backlog personalizado pode ser uma combinação de histórias e incidentes. Dessa forma, você pode criar quantos backlogs personalizados forem necessários.

    Veja Criar um backlog personalizado no Desenvolvimento ágil 2.0

    Criar grupos de atribuição

    Crie um grupo de atribuição e adicione membros a ele. Para cada membro do grupo, defina o número de pontos da história que eles podem concluir em um sprint. No nível do grupo, a soma dos pontos da história de todos os membros do grupo determina a capacidade do grupo.

    Veja Criar um grupo de atribuição no Desenvolvimento ágil 2.0

    Criar sprints

    Um sprint é o intervalo de tempo no qual a equipe de desenvolvimento entrega uma ou mais histórias. Um sprint pode ter qualquer tamanho, mas normalmente leva entre uma e quatro semanas para ser concluído. O mestre de scrum cria o número de sprints necessários para o grupo e esses sprints são usados pelos membros do grupo para concluir o trabalho necessário para uma versão futura. No entanto, todos os sprints em uma versão devem estar dentro das datas de início e término da versão.

    Planejar atividades de sprint

    Antes do início de um sprint, o grupo e o scrum master decidem em quais histórias do backlog eles podem se comprometer a concluir em um sprint. As histórias de um sprint podem ser selecionadas com base na prioridade. O mestre de scrum deve garantir que o esforço (total de pontos de história) necessário para concluir as histórias corresponda à capacidade do grupo.

    Ao planejar seus sprints, você pode usar os relatórios de velocidade como orientação para estimar quanto trabalho o grupo pode concluir no próximo sprint. O painel Agile 2.0 Team fornece o relatório de histórico de velocidade e o relatório de velocidade por tipo.
    • Histórico de velocidade: obtenha informações sobre a velocidade geral da equipe nos últimos 10 sprints. Analise se a equipe está alcançando uma velocidade estável e previsível e está cumprindo os compromissos.
    • Velocidade por tipo: analise como a velocidade da sua equipe muda ao longo do tempo e compare a carga de trabalho estratégica da equipe com a operacional ou outros tipos de carga de trabalho.

    Para obter mais informações sobre como planejar seus sprints, consulte Planejar suas atividades de sprint no Desenvolvimento ágil 2.0.

    Acompanhar andamento do sprint

    O scrum master gerencia os esforços da equipe de sprint, fornece relatórios de andamento e remove todos os bloqueadores que a equipe encontra. Os membros da equipe atualizam os registros de histórias e realizam reuniões diárias para discutir o andamento e comunicar as preocupações ao scrum master e aos responsáveis pelo produto.

    Espera-se que a equipe conclua todas as histórias confirmadas para um sprint. O scrum master espera que as histórias sejam totalmente testadas e estejam prontas para liberação, de acordo com os critérios de aceitação.

    O ideal é que as histórias confirmadas e o escopo de um sprint específico não sejam alterados enquanto o sprint estiver em andamento. Desenvolvimento ágil 2.0 fornece a flexibilidade para atualizar conforme necessário e se adaptar às mudanças de prioridades. No entanto, as histórias devem ser adicionadas ou removidas de um sprint somente após uma discussão entre o grupo, o scrum master e o responsável pelo produto.

    Você pode usar o painel de Sprint do Agile 2.0 com relatórios como gráficos de burnup e burndown para rastrear o andamento da equipe em um sprint.

    Acompanhar andamento da versão

    O responsável pelo produto rastreia o andamento da versão e verifica se a equipe está concluindo histórias no ritmo necessário para atingir o objetivo da versão.

    Você pode usar o painel da versão Agile 2.0 com relatórios como burnup, burndown e gráficos de tempo de ciclo para rastrear o andamento da equipe de uma versão.

    Nota:
    Todos os painéis do Agile 2.0 estão disponíveis com Performance Analytics Pacote de conteúdo para Agile 2.0.