Tipos de item de trabalho e fluxo de trabalho do modelo de processo do Agile
As equipes usam os WITs (tipos de item de trabalho) fornecidos com o modelo de processo MSF para Agile Software Development 2013 (Agile) para planejar e acompanhar o andamento dos projetos de software. As equipes definem as histórias do usuário para gerenciar a lista de pendências do trabalho e, usando o bloco Kanban, acompanham o andamento atualizando o status dessas histórias.
Para obter insight de um portfólio de recursos, cenários ou experiências do usuário, os proprietários de produto e gerentes de programas podem mapear histórias do usuário para recursos. Quando as equipes trabalham em sprints, elas definem tarefas com vínculo automático a histórias do usuário.
Com o Microsoft Test Manager e o TWA (Team Web Access), os testadores criam e executam casos de teste. Bugs e problemas são usados para acompanhar defeitos de código e problemas de bloqueio.
Definir histórias do usuário e estimar o esforço usando pontos de história
As histórias do usuário definem os aplicativos, os requisitos e os elementos que as equipes precisam criar. Os proprietários de produto geralmente definem e fazem a classificação da pilha das histórias do usuário. Em seguida, a equipe estima o esforço e o trabalho para entregar os itens de maior prioridade.
Crie histórias do usuário no painel de adição rápida da página da lista de pendências do produto.
Mais tarde, é possível abrir cada história do usuário para fornecer mais detalhes e estimar os pontos da história.
Ao definir os Pontos da História, as equipes podem usar o recurso de previsão e os gráficos de velocidade para estimar sprints futuros ou esforços de trabalho. Priorizando as histórias do usuário na página de lista de pendências (que é capturada no campo Classificação da Pilha), os proprietários de produto podem indicar quais itens devem receber maior prioridade.
Use a seguinte orientação ao preencher o formulário. Dessa forma, os campos obrigatórios são indicados.
Campo/guia |
Uso |
---|---|
Estime a quantidade de trabalho necessária para concluir uma história do usuário usando qualquer unidade de medida que sua equipe preferir, como o tamanho da camiseta, os pontos da história ou o tempo. Os gráficos de velocidade e as ferramentas de previsão do Agile referenciam os valores nesse campo. Esse campo é obrigatório para a geração do relatório de velocidade. Para ter mais orientação, consulte o white paper Estimando. |
|
Uma classificação subjetiva da incerteza relativa sobre a conclusão de sucesso de uma história do usuário. Os valores permitidos são:
Para alterar a seleção do menu, consulte Personalizar uma lista de opções. |
|
Detalhes (histórias do usuário) |
No caso de histórias do usuário, forneça detalhes suficientes para fazer a estimativa do trabalho necessário para implementar a história. Foque no objetivo do recurso, no que os usuários desejam fazer e por quê. Não descreva como o recurso deve ser desenvolvido. Forneça detalhes suficientes para que sua equipe possa escrever tarefas e casos de teste para implementar o item. Passos para reproduzir (bugs) No caso de bugs, capture informações suficientes para que outros membros da equipe possam entender o impacto completo do problema e saber se o bug foi corrigido. Isso inclui as ações executadas para localizar ou reproduzir o bug e o comportamento esperado. Pense em incluir o que significa "Concluído", descrevendo os critérios que a equipe deve usar para verificar se a história do usuário ou a correção de bug foi totalmente implementada. Antes de começar a trabalhar em um bug ou história do usuário, descreva os critérios de aceitação do cliente da forma mais clara possível. Conversas entre a equipe e os clientes para determinar os critérios de aceitação ajudam a garantir um entendimento comum dentro da equipe para atender às expectativas do cliente. Os critérios de aceitação podem ser usados como base para os testes de aceitação para que a equipe avalie de maneira mais eficiente se um item foi concluído de maneira satisfatória. |
Acompanhar o andamento
As equipes podem usar o bloco Kanban para acompanhar o andamento das histórias do usuário e o painel de tarefas sprint para acompanhar o andamento das tarefas. Arrastar itens para uma nova coluna de estado atualiza os campos Estado e Motivo do fluxo de trabalho.
Você pode personalizar o bloco Kanban para oferecer suporte a pistas ou colunas adicionais. Ou você pode personalizar o fluxo de trabalho para os WITs de tarefa e história do usuário que alterarão os títulos padrão das colunas.
Esta é uma progressão típica de fluxo de trabalho no caso de uma história do usuário:
O proprietário do produto cria uma história do usuário no estado Novo com o motivo padrão, Nova história do usuário.
A equipe atualiza o status para Ativo quando decide concluir o trabalho durante o sprint.
Uma história do usuário é movida para Resolvido quando a equipe tiver concluído todas as suas tarefas associadas e os testes da unidade para a história forem aprovados.
Uma história do usuário é movida para o estado Fechado quando o proprietário do produto concorda que a história foi implementada de acordo com os critérios de aceitação e o teste de aceitação for aprovado.
Atualizando o fluxo de trabalho, as equipes sabem que itens são novos, estão em andamento ou foram concluídos. A maioria dos WITs oferece suporte à transição progressiva e regressiva de cada estado do fluxo de trabalho.
Mapear histórias do usuário para recursos
Ao gerenciar um pacote de produtos ou de experiências do usuário, você talvez queira exibir o escopo e o andamento do trabalho no portfólio do produto. Você pode fazer isso definindo recursos e mapeando histórias do usuário para recursos.
Na página Lista de pendências de recursos, você pode adicionar recursos rapidamente, da mesma maneira que adicionou histórias do usuário.
O item de trabalho de recurso contém campos semelhantes fornecidos para histórias do usuário e inclui campos adicionais, como descreve a tabela a seguir.
A guia Implementação captura os vínculos para as histórias mapeadas do usuário.
Field |
Uso |
---|---|
Uma classificação subjetiva da história do usuário no que se refere ao negócio. Os valores permitidos são:
Para alterar a seleção do menu, consulte Personalizar uma lista de opções (menu suspenso) [redirecionado]. |
|
Especifique um número que capture o valor relativo de um recurso comparado a outros recursos. Quanto maior for o número, maior será o valor comercial. |
|
Especifique a data até a qual o recurso deverá ser implementado. |
Na página da lista de pendências com o Mapeamento ativado, você pode arrastar as histórias do usuário para o recurso que elas implementam.
Esse mapeamento cria os vínculos pai-filho de recurso para histórias do usuário, que é capturado na guia Implementação.
Usando as listas de pendências do portfólio, você pode fazer uma pesquisa detalhada de uma lista de pendências para outra para exibir o nível de detalhes que desejar. Além disso, você pode usar as listas de pendências do portfólio para exibir um rollup do trabalho em andamento de várias equipes ao configurar uma hierarquia de equipes.
Definir as tarefas necessárias para implementar histórias do usuário e controlar a capacidade e o burndown da equipe
Quando sua equipe gerencia seu trabalho em sprints, ela pode usar a página da lista de pendências de sprint para dividir o trabalho a ser feito em tarefas diferentes.
Nomeie a tarefa e faça uma estimativa do trabalho que será necessário.
Usando processos Agile, as equipes preveem o trabalho e definem as tarefas no início de cada sprint, e cada membro da equipe realiza um subconjunto dessas tarefas. As tarefas podem incluir desenvolvimento, testes e outros tipos de trabalho. Por exemplo, um desenvolvedor pode definir tarefas para implementar histórias do usuário, e um testador pode definir tarefas para gravar e executar casos de teste.
Quando as equipes estimam o trabalho usando horas ou dias, elas definem as tarefas e os campos Trabalho Restante e Atividade (opcional).
Campo/guia |
Uso |
---|---|
Estimativa original (veja a observação 1) |
A quantidade estimada de trabalho para concluir uma tarefa. Normalmente, esse campo não muda depois de atribuído. |
A quantidade de trabalho restante para concluir uma tarefa. Conforme o trabalho progride, atualize esse campo. É usada para calcular gráficos de capacidade, o gráfico de burndown do sprint e os seguintes relatórios: Burndown e taxa de gravação, Trabalho restante e Status em todas as iterações. Se você dividir uma tarefa em subtarefas, especifique horas somente para as subtarefas. Você pode especificar o trabalho em qualquer unidade de medida que sua equipe escolher. |
|
A quantidade de trabalho gasto na implementação de uma tarefa. |
|
Selecione o tipo de atividade que essa tarefa representa quando sua equipe fizer a estimativa da capacidade do sprint por atividade. Para alterar a seleção de menu, consulte personalizar uma lista de opções. |
|
Implementação |
Essa guia captura os vínculos de pai-filho criados entre histórias do usuário e tarefas. Ao adicionar tarefas a uma história do usuário utilizando o painel de tarefas de sprint, você cria automaticamente vínculos à história. Usando tarefas, é possível controlar o progresso do trabalho que ocorreu para concluir a história. Essa atividade também oferece suporte a vários relatórios, como Relatório Visão Geral das Histórias (Agile) e Relatório Andamento de Requisitos (CMMI). |
Observações:
É possível especificar o trabalho em horas ou dias. Não há unidades de tempo inerentes associadas a esse campo.
Se você usar o Microsoft Project para atribuir recursos e controlar uma agenda, poderá atualizar esses campos usando o Project.
Acompanhar o andamento do teste nas histórias de usuário e capturar defeitos de código
Histórias do usuário de teste
No Test Manager ou no TWA, você pode criar casos de teste que vinculem automaticamente uma história do usuário ou bug.
O caso de teste contém vários campos, muitos dos quais são automatizados e integrados com o Test Manager e o processo de compilação. Para obter uma descrição de cada campo, consulte Referência de campos de integração de compilação e teste.
A guia Histórias Testadas do Usuário lista todas as histórias do usuário e bugs em um caso de teste. Vinculando histórias do usuário e bugs a casos de teste, a equipe pode controlar o progresso feito no teste de cada item. Definindo esses links, você oferece suporte a informações que aparecem no relatório Relatório Visão Geral das Histórias (Agile).
Rastrear defeitos de código
Você pode criar bugs no TWA, Visual Studio ou quando testar com o Test Manager.
Campo/guia |
Uso |
---|---|
Capture informações suficientes para que os outros membros da equipe possam entender o impacto completo do problema, bem como saber se o bug foi corrigido. Isso inclui as ações executadas para localizar ou reproduzir o bug e o comportamento esperado. Descreva os critérios que a equipe deve usar para verificar se o defeito de código foi corrigido. |
|
Classificação subjetiva do impacto de um bug no projeto. Os valores permitidos são:
Para alterar a seleção de menu, consulte definir uma lista de opções. |
|
Quando o Test Manager cria bugs, ele preenche automaticamente Informações do Sistema e Encontrado na Compilação com informações sobre o ambiente e a compilação de software onde o bug ocorreu. Para saber mais sobre como definir os ambientes de software, consulte Configurando máquinas de teste para executar testes ou coletar dados. Ao resolver o bug, use Integrado na Compilação para indicar o nome da compilação que incorpora o código que corrige o bug. Para acessar um menu suspenso de todas as compilações que foram executadas, você pode atualizar as definições de FIELD para Encontrado na Compilação e Integrado na Compilação para fazer referência a uma lista global. A lista global é automaticamente atualizada com cada compilação executada. Para saber mais, consulte Campos que dão suporte à integração com teste, compilação e controle de versão. Para obter informações sobre como definir nomes de compilação, consulte Usar números de compilação para dar nomes significativos a compilações concluídas. |
Definir campos e guias de itens de trabalho comuns
Os campos e guias a seguir aparecem na maioria dos formulários de item de trabalho. Cada guia é usada para acompanhar informações específicas, como Histórico, Links ou Anexos. Essas três guias fornecem um histórico de alterações, exibição de itens de trabalho vinculados e a capacidade de exibir e anexar arquivos, respectivamente.
O único campo obrigatório para todos os WITs é Título. Quando o item de trabalho é salvo, o sistema atribui uma ID exclusiva a ele. Outros campos obrigatórios estão destacados em amarelo.
Campo/guia |
Uso |
---|---|
Título [Obrigatório] |
Digite uma descrição de 255 caracteres ou menos. Você pode alterar o título quando quiser. |
Atribua o item de trabalho ao membro da equipe responsável pela execução do trabalho. Dependendo do contexto em que você está trabalhando, o menu suspenso listará somente os membros da equipe ou os colaboradores para o projeto de equipe. |
|
Quando o item de trabalho é criado, o Estado assume como padrão o primeiro estado no fluxo de trabalho. Conforme o trabalho progride, atualize-o para refletir o estado atual. Para alterar a lista suspensa de estados, consulte Alterar o fluxo de trabalho de um tipo de item de trabalho. |
|
Use primeiro o padrão. Atualize-o quando você alterar o estado. Cada estado é associado a um motivo padrão. Para alterar a lista suspensa de motivos, consulte Alterar o fluxo de trabalho de um tipo de item de trabalho. |
|
Escolha o caminho de área associado ao produto ou à equipe, ou deixe em branco até ser atribuído durante uma reunião de planejamento. Para alterar a lista suspensa de áreas, consulte Adicionar e modificar área e caminhos de iteração. |
|
Escolha o sprint ou a iteração em que o trabalho deve ser concluído, ou deixe em branco e atribua posteriormente, durante uma reunião de planejamento. Para alterar a lista suspensa de iterações, consulte Adicionar e modificar área e caminhos de iteração. |
|
Adicione todos os tipos de links, como hiperlinks, conjuntos de alterações, arquivos de origem e assim por diante. Essa guia também lista todos os links definidos para o item de trabalho, mesmo aqueles definidos em outras guias de controle de links. |
|
Compartilhe informações mais detalhadas adicionando arquivos ao item de trabalho, como threads de email, documentos, imagens, arquivos de log ou outros tipos de arquivo. |
|
Examine a trilha de auditoria que o sistema captura e as informações adicionais da captura. Cada vez que o item de trabalho é atualizado, as informações são acrescentadas ao histórico. O histórico inclui a data da alteração, quem fez a alteração e os campos que foram modificados. Você também pode adicionar texto formatado ao campo do histórico. |
Para pesquisar informações sobre outros campos, consulte Índice de campos de item de trabalho.
Começar a acompanhar o trabalho
Antes de começar a acompanhar o trabalho, você deve ter um projeto de equipe. Acesse aqui para criar um.
Se você tiver um projeto de equipe, comece a acompanhar o trabalho:
Para se familiarizar com as tarefas comuns do item de trabalho, consulte Começar usando itens de trabalho.
Para criar uma lista de pendências, use o TWA. Consulte Criar sua lista de pendências.
Para criar uma estrutura de detalhamento de trabalho, use Projeto ou Excel.
Para saber mais, consulte Escolher o cliente do Team Foundation para oferecer suporte às suas tarefas.
Perguntas e respostas
P: como controlar o valor comercial?
R: você pode usar o campo de prioridade para diferenciar o valor de várias matérias. Ou, você pode adicionar um campo personalizado para o WIT história de usuário que controla o valor relativo de histórias. Para saber como, consulte modificar ou adicionar um campo personalizado.
P: Estados de fluxo de trabalho quais oferece suporte Agile?
R: esses diagramas mostram os estados de regressão e de progressão principais de recurso, história de usuário, bugs e tarefas. Para personalizar o fluxo de trabalho, vá aqui.
Recurso |
História do usuário |
Bug |
Tarefa |
P: Como resolvo um bug como duplicata?
R: Defina o Estado como Removido e especifique o Motivo como Duplicata.
P: Como vinculo um bug existente do Test Runner?
R: Consulte Atualizar um bug existente com o Test Runner.