Trabalhar com artefatos de projeto de equipe, escolher um modelo de processo

Sempre que você cria um projeto de equipe, deve escolher o modelo de processo. O modelo de processo define os WITs (Tipos de item de trabalho), as consultas e os relatórios que serão usados para planejar e acompanhar o projeto. Escolha o modelo que oferece as ferramentas de que a equipe precisa e reduza a sobrecarga para que a equipe possa focar na qualidade.

Para criar um projeto de equipe, clique aqui.

Para acessar as versões mais recentes dos modelos de processo do TFS (Team Foundation Server), instale o Visual Studio Team Foundation Server 2013 (TFS). Em seguida, baixe-os usando o Gerenciador de Modelos de Processo.

As principais distinções entre os três modelos de processo estão nos tipos de item de trabalho que eles fornecem para planejar e acompanhar o trabalho. O Scrum do Visual Studio é o mais leve e o MSF para CMMI (Integração do modelo de maturidade da capacidade) fornece o maior suporte a processos formais e gerenciamento de alterações.

Microsoft Visual Studio Scrum 2013

Escolha Scrum do Visual Studio se a sua equipe gerenciar bugs junto com itens da lista de pendências de produto durante o planejamento de sprint.

O modelo de Scrum é projetado para dar suporte à metodologia de Scrum como definido pela Organização de Scrum. Esse modelo de processo acompanha Bugs no mesmo nível que os itens de Lista de Pendências de Produto e acompanha estimativas usando o campo Esforço.

O sistema zera automaticamente o campo Trabalho Restante quando a tarefa Estado é configurada como Concluída.

Tipos de item de trabalho Scrum 3.0

MSF para Agile Software Development 2013

Escolha Agile se sua organização fizer a triagem de bugs separadamente da lista de pendências de produto e resolver itens de trabalho antes de fechá-los. Além disso, escolha Agile se sua equipe alocar tempo para bugs com cada sprint.

O modelo Agile é projetado para dar suporte ao desenvolvimento Agile para equipes que não desejam ficar restritas por Scrum. Oferece suporte estimando Histórias do Usuário ao usar Pontos de História. As tarefas contêm campos para rastrear os campos Estimativa Original, Restante e Trabalho concluído. Os bugs não são rastreados em nenhuma página de lista de pendências. Para obter mais informações sobre metodologias Agile, consulte http://www.agilealliance.org/.

Tipos de item de trabalho 7.0 Agile

MSF para CMMI Process Improvement 2013

Escolha CMMI se sua organização fizer a triagem de bugs separadamente da lista de pendências de produto, resolver itens de trabalho antes de fechá-los e acompanhar alterações aos requisitos de modo formal.

O modelo de CMMI é projetado para oferecer suporte a processos formais de gerenciamento de alterações. Esse modelo oferece suporte estimando os Requisitos usando um campo de Tamanho. As tarefas contêm campos para rastrear os campos Estimativa Original, Restante e Trabalho concluído. Os bugs não são rastreados em nenhuma página de lista de pendências.

Clique aqui para saber mais sobre processos de CMMI.

Tipos de item de trabalho CMMI 7.0

Principais distinções entre os modelos de processo padrão

Os modelos padrão são projetados para atender às necessidades da maioria das equipes. Todos eles oferecem suporte ao uso de ferramentas de planejamento Agile para criar a lista de pendências de produto e trabalhar em sprints com o painel de tarefas. Se sua equipe tiver necessidades incomuns, é possível personalizar um modelo e criar o projeto da equipe, ou é possível criar um projeto de equipe de um modelo e personalizá-lo.

A tabela a seguir resume as principais distinções entre os tipos de item de trabalho e os estados usados pelos três modelos de processo padrão.

Área de processo

Visual Studio Scrum

Agile

CMMI

Estados de fluxo de trabalho

  • Novo

  • Aprovado

  • Confirmado

  • Concluído

  • Removido

  • Novo

  • Ativo

  • Resolvido

  • Fechado

  • Removido

  • Proposto

  • Ativo

  • Resolvido

  • Fechado

Planejamento de produto (consulte a observação 1)

  • Bug

  • Item da lista de pendências do produto

  • História do usuário

  • Requisito

Lista de pendências do portfólio (2)

  • Recurso

  • Recurso

  • Recurso

Planejamento de tarefas e iteração (3)

  • Tarefa

  • Tarefa

  • Tarefa

Gerenciamento da lista de pendências de bug (4)

  • Bug

  • Bug

  • Pasta de trabalho de triagem

  • Bug

  • Pasta de trabalho de triagem

Gerenciamento de projeto (4)

  • Impedimento

  • Problema

  • Pasta de trabalho de problemas

  • Problema

  • Risco

  • Revisão

  • Pasta de trabalho de problemas

Observações:

  1. É possível definir esses WITs usando a Lista de pendências de produto. A página de lista de pendências de produto mostra uma visualização única da lista de pendências do trabalho atual que pode ser reordenada e agrupada de maneira dinâmica. Proprietários de produto podem priorizar o trabalho e traçar rapidamente dependências e relacionamentos.

  2. É possível criar Recursos e vinculá-los a itens da lista de pendências para gerenciar a lista de pendências do portfólio. Com listas de pendências do portfólio, é possível definir uma hierarquia de listas de pendências para entender o escopo do trabalho através de várias equipes e ver como é feito o rollup desse trabalho em iniciativas mais amplas.

  3. É possível definir tarefas usando Painel de lista de pendências e tarefas do sprint. A página de lista de pendências do sprint reflete os dados inseridos em tempo real. Os dados incluem itens de trabalho atribuídos ao caminho de iteração, trabalho restante, capacidade de trabalho individual e interrupções de trabalho para a equipe e indivíduos. As equipes podem obter feedback instantâneo sobre a taxa de burndown e onde estão acima da capacidade.

  4. As pastas de trabalho só ficam disponíveis quando um projeto de equipe é configurado com um portal do projeto do SharePoint. Porém, é possível criar sua própria pasta de trabalho abrindo uma consulta correspondente no Excel.

Estados de fluxo de trabalho

Fluxo de trabalho informa suporte rastrear o status de trabalho conforme ele se move de um novo estado para um fechado ou um estado concluído. Os diagramas a seguir mostram a progressão de encaminhamento típica dos WITs usado para acompanhar defeitos de código e de trabalho para os modelos de processo do TFS padrão de três. Elas também mostram algumas das regressões antigos estados e transições para removido estados. Cada imagem mostra apenas o motivo padrão associado com a transição.

Scrum

Agile

CMMI

Recurso

Estados de fluxo de trabalho de recursos, o modelo de processo do Scrum

Recurso

Estados de fluxo de trabalho de recursos, o modelo de processo do Agile

Recurso

Estados de fluxo de trabalho de recursos, modelo de processo CMMI

Item da lista de pendências do produto

Product backlog item fluxo de trabalho, processo do Scrum

História do usuário

Estados de fluxo de trabalho de história do usuário, o modelo de processo do Agile

Requisito

Estados de fluxo de trabalho de requisito, modelo de processo CMMI

Bug

Estados de fluxo de trabalho de bug, modelo de processo do Scrum

Bug

Estados de fluxo de trabalho de bug, o modelo de processo do Agile

Bug

Estados de fluxo de trabalho de bug, modelo de processo CMMI

Tarefa

Estados de fluxo de trabalho de tarefa, modelo de processo do Scrum

Tarefa

Estados de fluxo de trabalho de tarefa, o modelo de processo do Agile

Tarefa

Estados de fluxo de trabalho de tarefa, o modelo de processo CMMI

Os WITs Agile usado pelo faz a transição para qualquer suporte a ferramentas de planejamento Agile e Scrum. Você pode atualizar o status de um item de trabalho usando o quadro Kanban ou no painel de tarefas, arrastando-o para sua coluna estado correspondente.

Estados de fluxo de trabalho, motivos e transições

O fluxo de trabalho define a seqüência de tarefas a serem executadas e por quem. Cada fluxo de trabalho consiste em um conjunto de estados, as transições válidas entre os estados e as razões para fazer a transição do item de trabalho para o estado selecionado. Você pode alterar o fluxo de trabalho para dar suporte a estados adicionais, transições e motivos.

Removido, fechado e feito Estados

Quando você altera o estado de um item de trabalho como removido, fechado ou feito, o sistema responde como este:

  • Fechado ou feito: itens de trabalho nesse estado não aparecem na lista de pendências de portfólio e páginas de lista de pendências. No entanto, eles aparecem no painel de tarefas, páginas de lista de pendências de sprint e quadro Kanban. Além disso, quando você altera o modo de exibição de lista de pendências de portfólio para mostrar itens de lista de pendências, por exemplo, para exibir os recursos para itens de lista de pendências de produto, itens no estado fechado e concluído serão exibidos.

  • Removido: itens de trabalho nesse estado não aparecem em qualquer lista de pendências ou quadro.

Itens de trabalho são mantidos em um projeto de equipe, desde o projeto de equipe está ativo. Mesmo se você defini-las fechado, concluído ou removido, um registro é mantido no armazenamento de dados. Você pode usar um registro para criar consultas ou relatórios. Se você precisar excluir permanentemente os itens de trabalho, você pode usar o ferramenta de linha de comando de destroywi witadmin.

Tipos de item de trabalho adicionados a todos os modelos de processo

Os seguintes WITs são iguais em todos os modelos de processo.

Tipos usados por MTM, meu trabalho e comentários do item de trabalho

As equipes criam e trabalham com esses tipos usando a ferramenta correspondente:

  • Plano de teste, Conjunto de testes, Etapas compartilhadas do caso de teste e Parâmetros compartilhados: Microsoft Test Manager.

    Os Parâmetros compartilhados tornam-se disponíveis quando você atualizou sua implantação local para TFS 2013.2.

    O Plano de teste e os WITs do conjunto de testes ficam disponíveis quando você atualiza sua implantação local para TFS 2013.3.

  • Solicitação de Feedback e Resposta de Feedback: Solicitar feedback.

  • Solicitação de Revisão do Código e Resposta de Revisão do Código: Meu Trabalho (do Team Explorer) e Solicitação de Revisão de Código.

Os itens de trabalho dessas definições de tipo não devem ser criados manualmente e, portanto, são adicionados à categoria Tipos Ocultos. Tipos de item de trabalho adicionados à categoria de Tipos Ocultos não aparecem nos menus usados para criar novos itens de trabalho.

Dica

Se você tiver feito atualização do projeto de equipe do TFS 2012 ou uma versão anterior para a versão atual do TFS, pode ser preciso adicionar WITs que não existiam em versões anteriores.Para obter mais informações, consulte Atualizar um projeto de equipe atualizado para acessar novos recursos.

WITs que dão suporte a experiência de teste

WITs que oferecem suporte a experiência de teste e funcionam com o Gerenciador de teste e Acesso Web da Equipe são vinculados usando os tipos de link mostrados na figura a seguir.

Tipos de item de trabalho de gerenciamento de teste

Usando o Team Web Access ou o Test Manager, é possível exibir quais casos de teste estão definidos para um conjunto de testes e quais conjuntos de testes estão definidos para um plano de teste. Porém, esses objetos não estão conectados uns aos outros por meio de tipos de link.

Conforme mencionado acima, o plano de teste e os WITs de conjunto de testes aparecem depois que você atualizar seu servidor de camada de aplicativo para TFS 2013.3. Você pode personalizar essas WITs como faria com qualquer outro WIT. Consulte Personalizar objetos de acompanhamento de trabalho para dar suporte aos processos da sua equipe.

Se você alterar o fluxo de trabalho para o plano de teste e um conjunto de testes, talvez seja necessário atualizar a configuração do processo conforme descrito aqui.

Para obter as definições de cada campo de teste, consulte Referência de campos de integração de compilação e teste.

Para saber mais sobre as alterações feitas ao Test Manager e Acesso Web da Equipe com a atualização para o TFS 2013.3, consulte Opening test plan and test suite work item types.

Perguntas a fazer à sua equipe

Para acompanhar o trabalho com eficiência, os membros da equipe precisam concordar sobre como usarão os tipos e ferramentas do item de trabalho. Seguem algumas perguntas para sua equipe responder.

Pergunta

Escolhas da equipe

Como sua equipe acompanha o trabalho?

Se sua equipe acompanha o progresso principalmente atualizando o status dos itens da lista de pendências, ela pode usar o Painel Kanban. A equipe também pode personalizar o painel Kanban para acompanhar o progresso em várias raias de natação.

Se a equipe dividir itens da lista de pendências em tarefas para cada sprint e estimar o trabalho restante, ela pode usar o painel de tarefa de sprint. Embora o trabalho restante geralmente seja estimado em horas, é possível usar qualquer unidade de tempo desejada, desde que a equipe concorde com a unidade. Estimando e atualizando o trabalho restante, sua equipe pode acompanhar o progresso pelo gráfico de burndown fornecido com cada sprint.

Sua equipe acompanha a capacidade por indivíduo ou por atividade?

Se sua equipe acompanhar o trabalho restante por tarefas, ela pode avaliar a capacidade para um sprint para membros da equipe individuais ou para diferentes atividades da equipe, como desenvolvimento, teste e design.

Como sua equipe agrupa o trabalho?

É possível agrupar o trabalho de várias maneiras. Os itens criados da página de lista de pendências são automaticamente atribuídos ao caminho da área da equipe. Os itens atribuídos a um sprint são atribuídos ao caminho de iteração do sprint. Além disso, é possível atribuir marcas a itens de trabalho para filtrar uma lista de pendências ou consultar uma lista de resultados.

Sua equipe usa velocidade e previsão?

Para oferecer suporte a previsão, sua equipe pode usar os campos de Esforço (Scrum), Pontos de História (Agile) ou Tamanho (CMMI) para determinar quantos itens podem ser concluídos para um sprint. Além disso, o gráfico de velocidade mostrará o progresso da equipe a cada sprint.

Como sua equipe compartilha informações?

Os membros da equipe podem anexar arquivos a itens de trabalho, fazer check-in de arquivos no código-fonte ou compartilhar trabalho usando o portal do projeto da equipe. Quando um portal do projeto é configurado, sua equipe tem acesso a todos os recursos que um site do SharePoint tem a oferecer, incluindo bibliotecas de documentos, páginas de wiki, blog e calendários de eventos.

Sua equipe oferece suporte ao rollup de progresso em várias equipes?

Lista de pendências do portfólio permitem que você visualize um rollup do trabalho em andamento em várias equipes de forma rápida. Se um membro da equipe trabalhar em mais de uma equipe, ele pode alocar sua capacidade de acordo para cada equipe.

Perguntas e respostas

P: E se eu estiver atualizando um projeto de equipe?

R: Para usar os novos recursos adicionados ao instalar a última versão do TFS, consulte Atualizar um projeto de equipe atualizado para acessar novos recursos.

Para personalizar projetos de equipe existentes, consulte Personalizar objetos de acompanhamento de trabalho para dar suporte aos processos da sua equipe.

P: Que modelo de processo devo usar com o painel Kanban?

R: Você pode usar o painel Kanban com qualquer modelo de processo, padrão ou personalizado.

P: Como posso obter os últimos modelos de processo?

R: As últimas versões dos modelos de processo padrão são automaticamente carregadas quando você instala ou atualiza a última versão do TFS. Use o Carregar, baixar e excluir modelos de processo para uma coleção de projeto de equipe para baixá-las.

Além disso, você pode baixar Team Foundation Server 2013 processo modelo amostras - suporte para o Framework Agile dimensionado (seguro). Esses modelos contêm as personalizações descritas neste white paper: Scaled Agile Framework: Using TFS to support epics, release trains, and multiple backlogs.

P: Há uma ferramenta que oferece suporte à visualização do diagrama de estado de fluxo de trabalho?

R: Sim. É possível usar o Editor de Processo fornecido com as Team Foundation Server Power Tools.

P: O que mais é definido em um modelo de processo?

R: além de definir os artefatos de projetos de equipe, o modelo de processo define a configuração inicial de muitos elementos usados para acompanhar o trabalho e dar suporte a atividades de teste. Esses elementos incluem:

  • Caminhos de área e iteração

  • Consultas de itens de trabalho

  • Testar variáveis, configurações, estados de resolução e configurações de teste padrão

  • Definições de membro e grupo e as atribuições de permissão

  • Como os campos do Microsoft Project são mapeados para campos do Team Foundation

Todos os elementos podem ser configurado ou personalizado depois de um projeto de equipe é criado a partir do modelo de processo.

P: Posso personalizar um modelo de processo?

R: Sim. Os modelos padrão são projetados para atender às necessidades da maioria das equipes. Se sua equipe tiver necessidades incomuns, é possível personalizar um modelo e criar o projeto da equipe, ou é possível criar um projeto de equipe de um modelo e personalizá-lo.

P: Como os modelos de processo mudaram desde a versão anterior?

R: Consulte Alterações feitas nos projetos de equipe e nos modelos de processo padrão durante a atualização do Team Foundation Server.

P: E se eu precisar de mais de uma lista de pendências de portfólio?

R: Você pode definir listas de pendências de portfólio adicionais para um total de listas de pendências de portfólio.

P: Onde posso saber mais sobre storyboarding?

R: A guia Storyboards no formulário PBI permite vincular aos storyboards que você carregou em um local de rede compartilhado. Você pode vincular a qualquer URL que sua equipe possa acessar. Além disso, você pode vincular aos storyboards criados usando o PowerPoint Storyboarding.

P: Para onde posso ir se tiver mais dúvidas?

R: É possível publicar uma pergunta ou pesquisar respostas no fórum Team Foundation Server – Projeto de Equipe e Item de Trabalho.