Use o TFS para rastrear erros do Suporte à produção

18

Acabei de me mudar para uma nova empresa e eles estão usando o TFS 2010 (2012 em alguns meses) como seu sistema de controle de versão e recentemente começaram a usá-lo como um sistema de rastreamento de trabalho para os desenvolvedores.

No entanto, não parece haver um sistema de rastreamento de bugs para uso por pessoas fora do desenvolvimento e teste. O suporte à produção está recebendo relatórios de problemas, corrigindo-os rapidamente e relatando aos usuários no momento. Isso precisa ser alterado, mas eu realmente não quero ter um sistema separado para rastrear bugs e rastrear o trabalho do desenvolvedor.

Existe uma maneira de criar uma maneira muito leve de inserir bugs no TFS semelhante à maneira que o FogBugz faz? Fazer login no TFS para preencher um relatório de erro parece muito mais pesado e você deve associá-lo a um aplicativo específico. O suporte pode ser capaz de fazer isso, mas eu quero poder triar o item e potencialmente alterar a associação para algo diferente de um aplicativo.

Eu usei o FogBugz no passado e, ao adicionar um bug, você pode adicionar um pouco mais ou menos ao item para que ele seja pelo menos gravado e depois você pode devolvê-lo para obter mais informações ao fazer a triagem do ticket .

issue-tracking team-foundation-server

— Richard Hooper
fonte

Vale ressaltar que, se você estiver usando o TFS e todos os usuários tiverem uma conta de domínio do Windows, eles nunca precisarão "efetuar login no TFS". Acessar o portal da Web TFS da sua equipe fará o login automaticamente usando as credenciais do domínio para o usuário atual do Windows.

— 17 de 26

Como você acabou resolvendo isso? Tenha o mesmo problema hoje, precise de um sistema de emissão de bilhetes, tenha o TFS2013 no local. O que eu quero é o UserVoice, mas teria que deixar o TFS no local no VSO para obter essa integração.

— EJA 14/09

1

@EJA - No final, decidimos que precisávamos usar um processo para que o problema fosse levantado por meio de uma caixa de entrada de e-mail que é escolhida pelos testadores para que eles possam documentar completamente o problema, etapas para re-produzir, ambiente, etc. e o testador pode adicionar o bug ao TFS no formato correto. Embora fosse bom que os usuários pudessem adicioná-los diretamente, percebemos que é improvável que os usuários forneçam aos desenvolvedores todos os detalhes de que precisariam e não procurariam duplicação do problema.

— Richard Hooper

6

Depende em grande parte de quais campos você deseja, como 17 de 26 indicaram: O TFS é altamente personalizável. A razão pela qual eu gostaria de fazer isso em vez de usar algo como o JIRA é que você obtém uma única visão do que seus desenvolvedores estão trabalhando, em vez de ter que agregar dois sistemas.

O TFS também possui um planejamento de capacidade de recursos e, se você não estiver apresentando defeitos de produção em seu planejamento (e eles ocupam uma fração significativa do seu tempo), não está realmente planejando sua capacidade. Na verdade, eu diria que esta é uma solução ideal para equipes nas quais os desenvolvedores usam o TFS e dão suporte à produção (por exemplo, DevOps).

Isso não significa que você não pode usar outras ferramentas para o trabalho principal de Suporte à produção / ITIL; você só precisa garantir que elas se integrem, manualmente ou de preferência automaticamente. A maioria dessas ferramentas permite que você coloque ganchos personalizados, e o TFS certamente o faz.

Enfim, para a questão principal. Eu uso os modelos CMMI TFS (que realmente funcionam bem com o Agile BTW) e acabei de adicionar um único campo a um dos menus suspensos.

Aqui estão os passos:

Instalar as ferramentas elétricas do TFS

Abra o modelo de item de trabalho do servidor

Abrir modelo de item de trabalho do servidor

Modelo de bug aberto

Edite o campo Disciplina

O campo da disciplina é o "tipo" de trabalho relacionado ao defeito. Os valores padrão são:

Análise
Experiência de usuário
Educação do Usuário
Desenvolvimento
Teste

O que vamos fazer é adicionar "Produção" a essa lista. Primeiro, edite o campo Disciplina:

Editar Disciplina

Em seguida, clique na guia Regras e edite a regra ALLOWEDVALUES:

insira a descrição da imagem aqui

Em seguida, clique em "Novo" e adicione "Produção" como um dos valores.

insira a descrição da imagem aqui

Clique em "OK" repetidamente até voltar à lista de campos.

Salvar o modelo de item de trabalho

OK, agora você terminou. Você pode criar novos bugs e indicar o tipo deles como produção. Eu também criaria algumas Consultas de Item de Trabalho observando defeitos de produção e as adicionaria aos itens fixados. Por fim, observe as consultas de bugs existentes e talvez mude sua ordem para que os bugs de "Produção" surjam primeiro (se isso for possível).

— Sean Hederman
fonte

Ótimo, você personalizou o TFS para permitir que os desenvolvedores vejam "erros de produção" ... como a equipe de produção (que não faz parte da equipe de desenvolvedores e não tem VS) consegue entrar e gerenciá-los?

— Gbjbaanb 14/05

4

Bem, para iniciantes, eles podem acessar o TFS pela interface da Web, usando a licença das partes interessadas, que é gratuita. Em nossa organização, rastreamos os incidentes de produção por meio de um sistema baseado em ITIL, mas estamos integrando-o automaticamente ao TFS, conforme minha resposta indicada no terceiro parágrafo.

— Sean Hederman

4

Não, isso mesmo - o ALM principal da Microsoft não é realmente útil fora do Visual Studio e das equipes de desenvolvimento.

Você pode acessar os itens de trabalho usando o Team Explorer (que é uma versão muito reduzida do VS) ou acessá-lo pelo site do TFS. Tampouco são opções particularmente boas, pois os campos de erros lembram antigos rastreadores de empresas que eu tive a infelicidade de usar no passado.

Não há distinção real entre bugs no TFS - há apenas o rastreador que você filtra usando um campo no próprio item; portanto, use um campo de categoria e crie um relatório que mostre apenas um tipo específico de categoria. Eu acho que essa é sua única opção realista com o TFS.

Se você deseja rastrear problemas externos, acho que o TFS é uma má escolha; é melhor usar algo como Jira ou Redmine e usá-lo para gerenciar bugs - suas interfaces são muito, muito melhores e mais fáceis de usar que o TFS. Gostei especialmente da maneira como você pode enviar um email para o Redmine e isso cria um novo problema para você, que era um recurso de usabilidade ideal para funcionários externos.

— gbjbaanb
fonte

2

Os campos no TFS são totalmente personalizáveis e os padrões dependem dos modelos de processo que você escolhe ao configurar o TFS. O modelo de scrum tem como padrão Itens, Tarefas e Erros do Backlog do Produto. Cada tipo de item de trabalho possui campos diferentes apropriados ao trabalho.

— 17 de 26

Eu sei - os campos que você usa são totalmente personalizáveis, mas o Excel também se você o usou como rastreador de erros. O problema dos OPs era que o modelo apenas fornece esses tipos de itens de trabalho - e você não pode ter tipos diferentes (por exemplo, uma solicitação de recurso ou bug externo), é necessário personalizar (ou copiar) um dos existentes e usá-lo - o que por sua vez, gera uma grande quantidade de configuração que você precisa fazer para ajustá-la aos seus fluxos de trabalho. Então, como você tem vários rastreadores de bugs?

— Gbjbaanb

Eu pensei que o OP não queria vários rastreadores de bugs e estava apenas tentando descobrir como os não-desenvolvedores poderiam interagir com o rastreamento de itens de trabalho do TFS que os desenvolvedores já estavam usando (o que para mim é como você gostaria de fazer as coisas) .

— 17 de 26

é isso - você não pode realmente, ou pelo menos não tão facilmente quanto pode usar outras ferramentas como Redmine ou Fogbugz que possuem melhores recursos de rastreador. O TFS inclui itens como rastreamento de erros, mas ainda é principalmente uma ferramenta somente para desenvolvedores. O Redmine, por exemplo, possui vários rastreadores apenas no sentido de que há várias visualizações de um único banco de dados do rastreador. Eu acho que é mais o que ele deseja do que usar ferramentas diferentes (por exemplo, usando o TFS para desenvolvedores e o Fogbugz para a equipe de suporte, por exemplo).

— Gbjbaanb

1

Você pode adicionar quantos tipos de itens de trabalho personalizados desejar.

— MrHinsh - Martin Hinshelwood

3

Usuários não desenvolvedores podem acessar o sistema de rastreamento de itens de trabalho do TFS usando um navegador da web para acessar o Team Project Portal. Para encontrar o URL, vá para Equipe-> Mostrar Portal do Projeto no Visual Studio. A partir daí, qualquer pessoa com permissão pode procurar, criar ou modificar itens de trabalho. Eles também podem gerar todos os tipos de relatórios para analisar o status das coisas.

Os tipos de itens de trabalho disponíveis e os campos nos itens de trabalho variam dependendo de como o TFS está configurado (principalmente pelos modelos de processo escolhidos).

As informações necessárias para inserir um bug também dependem de como você configurou o TFS. No nosso caso, exigimos um título, etapas para reproduzir e a construção em que ele foi encontrado. O sistema de rastreamento de itens de trabalho do TFS é muito poderoso e flexível. Pode ser tão complicado ou simples quanto você deseja - tudo se resume ao modo como você o configurou.

— 17 de 26
fonte

3

Esta postagem no blog da Microsoft descreve as melhorias planejadas no TFS que devem ajudar a oferecer suporte a custos indiretos mais baixos:

Novo formulário de item de trabalho que é mais fácil aos olhos e inclui opções de discussão e menção, semelhantes ao facebook e twitter.
Os campos personalizados
Suporte Kanban aprimorado, por exemplo, tarefas de adição rápida em um item de trabalho.
Também menciona painéis e métricas.

— Bernard Vander Beken
fonte