🍠 👩🏼‍🎤 👨🏾‍🚀 Como trabalhar efetivamente com questões sobre questões no GitHub 🏂🏽 🥌 💦

Os tickets no GitHub são diferentes: solicitações para a implementação de alguns recursos, relatórios de erros, reclamações de clientes, alertas de sistemas de segurança, retrospectivas para a equipe, etc. Aqui, veremos como a equipe pode usá-las e discuti-las.

Conteúdo:

O que é um ingresso?

Para muitas equipes, "ticket" é um termo genérico que pode significar:

Pedido de implementação de funcionalidades.
Relatório de erro.
Reclamação do cliente.
Alerta de segurança.
Retrospectiva para a equipe.

Público ou privado?

Para projetos, você pode criar tickets públicos e privados. Público, como regra, é destinado a usuários, clientes, agentes, etc. Privado - para desenvolvedores, contratados, parceiros, etc.

Para ingressos públicos

Concentre-se na linha de fundo.
Enfatize o que pode ser feito.
Não publique informações confidenciais.

Para bilhetes privados

Concentre-se nos detalhes.
Destaque as informações da pesquisa, pois ajuda a identificar possíveis padrões entre diferentes tickets.
Adicione informações confidenciais conforme necessário.

Avaliação

Todos os tickets devem ser avaliados de forma a poder compará-los entre si e entender o que exatamente precisa ser trabalhado. Existem diferentes maneiras de avaliar e, na prática, o seguinte trabalho bem.

Classificação de prioridade

Exemplo : Prioridade 1 (faça primeiro), Prioridade 2 (faça segundo), Prioridade 3 (faça terceira), etc.
Analogia : uma lista de tarefas em que a Prioridade 1 é a principal prioridade.
: , . , .
: 0 (P0), , .

: 1 ( ) 5 ( ).
: - 1 (), 2 (), 3 (), 4 (), 5 ().
: . . , .
: 0 () 5 (). , .

: 1 ( ) 10 ( ).
: 1 ( ) 10 ( ).
: . . . , .

: — «», «», «».
: .
: , .

MoSCoW

: MoSCoW — «must», «should», «could», «won't». « », «», « », « ».
: , , - : « » « ».
: . .

: «would» «won't», , , «would» , , - : « , ...».

: « 1 %» , 1 % , « 100 %» — .
Analogia : a frequência de ocorrência de algo ou repetição durante um determinado período ou na amostra em questão.
Vantagens : permite avaliar com que frequência o problema ocorre. Pode ser convertido em notas como "20 vezes por dia". Você pode resumir na forma de "sempre", "frequentemente", "às vezes", "raramente", "nunca". Pode ser expresso em porcentagem: "80% dos casos são afetados".

Classificação cumulativa

Exemplo : avaliação de ticket por uma combinação de prioridade, influência, dano, tamanho, MoSCoW e frequência.

Suponha que um cliente importante veio ao escritório assinar um contrato dentro de uma hora e a equipe de vendas encontrou um erro de digitação no nome da empresa do cliente no site.

Os vendedores primeiro definem o ticket Prioridade 1.
1 ( ), .
3 (), .
«» , .
MoSCoW « », .
2 %, 2 % .

Aqui estão exemplos de discussão sobre classificações de ingressos.

- Geralmente, além do perigo, a frequência também é avaliada independentemente. Se é improvável que o bug ocorra durante o uso normal, mesmo com alto risco, a prioridade pode ser reduzida. Geralmente é assim que os riscos são gerenciados.

- Um desenvolvedor ou testador pode avaliar bem o perigo de um bug, mas ele não sabe se todos os usuários ou apenas alguns deles enfrentarão esse problema. Frequência é outra dimensão. A prioridade pode ser calculada multiplicando o risco pela frequência.

- O formulário deve ser o seguinte: perigo * frequência - facilidade de solução alternativa = prioridade. Se algum membro da equação for alterado (por exemplo, uma nova solução alternativa for encontrada ou se verificar que quase ninguém vai para a página da web em queda), a prioridade será ajustada. Existe apenas um perigo sem "estimar o número de pessoas que isso afetará" e "quanto isso afetará a eles?" Parece apenas parte da imagem.

- O engenheiro de controle de qualidade durante a pesquisa inicial identificou o perigo com base em critérios técnicos. Esse é apenas um dos fatores que o especialista do produto usa para determinar a prioridade, que a partir de agora se torna um parâmetro-chave.

- Para alguns usuários, o programa às vezes falha, eles perdem todo o trabalho realizado e ficam com muita raiva. Eles atribuem o maior perigo ao bilhete. Porém, se apenas uma pessoa encontrar um problema, e isso acontecer periodicamente, e o usuário já tiver se adaptado para economizar com mais frequência, o técnico de produto deverá dar ao ticket uma prioridade mais baixa.

- O perigo caracteriza a percepção de um problema por uma pessoa: se ele o encontrar em um determinado caso, ele avaliará o perigo como máximo. Prioridade descreve como a equipe de gerenciamento de projetos percebe um erro: erros relatados pelos reclamantes mais valiosos - clientes que trazem muito dinheiro, um diretor com dificuldades etc. recebem um valor mais alto.Não use o perigo de erros para avaliar a prioridade porque eles são interconectados indiretamente .

- A experiência de usar prioridade e perigo sugere que, em teoria, pode haver uma diferença entre eles, mas, na realidade, a maioria não o vê. Esses termos são tão frequentemente confusos que se tornam inseparáveis.

- O sistema interno de rastreamento de bugs do Google lida com prioridade e perigo. P0 S0 é a tarefa mais urgente, P2 S2 é o padrão, P4 S4 é o menos urgente. É uma piada de serviço que o perigo não faz sentido (porque, na verdade, não difere da prioridade).

- Nós usamos apenas prioridade. O testador atribui um valor inicial com base nas heurísticas (por exemplo, quedas - P1, melhorias cosméticas - P5). O desenvolvedor se concentra nesse valor para selecionar os erros com os quais você precisa começar a trabalhar primeiro. E então a prioridade é ajustada de acordo com a experiência do usuário e o comportamento do aplicativo. Se realmente precisarmos ver quais valores o testador definiu, usamos a função "history" ou "revision" em nosso aplicativo para rastrear erros.

Modelo de bilhete

O modelo ajudará sua equipe de forma eficaz e abrangente a cobrir tópicos importantes.

Pode usar:

O queixoso principal: uma descrição geral do problema dada pela pessoa que o encontrou.
Participantes: quem está envolvido na situação - usuários, funcionários, parceiros, pessoas específicas, etc.
Sintomas: sinais óbvios de um problema - opiniões de usuários, gatilhos, alertas etc.
Histórico: informações secundárias relevantes para a situação - casos semelhantes, relatórios, links etc.
Diagnóstico: o que acontece sob o capô - as causas subjacentes ou cadeia de causas, etc.
Previsão: avaliação de possíveis consequências, mudanças, etc.
Fraturas: perda de informações, falha no aplicativo, processo bloqueado etc.
Tratamento: o que fazemos para melhorar a situação - procedimentos, listas de tarefas, restrições, etc.

Arquivo de modelo do autor: TEMPLATE.md

Lançamento post-mortem

O lançamento de mensagens post mortem dirá à equipe quando lidar com a situação.

Você pode executar a análise:

Com qualquer problema perceptível ao usuário, como falhas ou erros inesperados.
No caso de qualquer intervenção, mediante solicitação, por exemplo, por engenheiros ou gerência.
Em qualquer investigação de incidente, isso reflete a necessidade de monitoramento.
No caso de solicitações das partes interessadas para realizar revisões, auditorias ou reduzir as consequências de incidentes.

Post-mortem inocente

Com inocentes post-mortem, vale a pena focar nos sintomas, causas e tratamento, em vez de culpar alguém. Tais revisões começam com a confirmação de que todos têm boas intenções, de que tudo foi possível usando as informações disponíveis naquele momento.

Como trabalhar efetivamente com questões sobre questões no GitHub