Get best of the week

Comment travailler efficacement avec des problèmes sur des problèmes sur GitHub

Les tickets sur GitHub sont différents: demandes de mise en œuvre de certaines fonctionnalités, rapports d'erreurs, plaintes des clients, alertes des systèmes de sécurité, rétrospectives pour l'équipe, etc. Ici, nous regardons comment l'équipe peut les utiliser et en discuter.

Contenu:



Qu'est-ce qu'un ticket?


Pour de nombreuses équipes, «ticket» est un terme générique qui peut signifier:

  • Demande d'implémentation de fonctionnalités.
  • Rapport d'erreur.
  • Plainte d'un client.
  • Alerte de sécurité.
  • Rétrospective pour l'équipe.

Public ou privé?


Pour les projets, vous pouvez créer des tickets publics et privés. Public, en règle générale, est destiné aux utilisateurs, clients, agents, etc. Privé - pour les développeurs, les entrepreneurs, les partenaires, etc.

Pour les billets publics


  • Concentrez-vous sur la ligne du bas.
  • Soulignez ce qui peut être fait.
  • Ne publiez pas d'informations confidentielles.

Pour les billets privés


  • Concentrez-vous sur les détails.
  • Mettez en surbrillance les informations de recherche, car cela permet d'identifier les modèles possibles entre les différents tickets.
  • Ajoutez des informations confidentielles si nécessaire.

Évaluation


Tous les billets doivent être évalués de manière à pouvoir les comparer les uns aux autres et à comprendre ce qui doit être travaillé exactement. Il existe différentes façons d'évaluer et, dans la pratique, les travaux suivants fonctionnent bien.

Classement prioritaire


  • Exemple : Priorité 1 (faire en premier), Priorité 2 (faire en deuxième), Priorité 3 (faire en troisième), etc.
  • Analogie : une liste de tâches dans laquelle la priorité 1 est la priorité absolue.
  • : , . , .
  • : 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 %» — .
  • Analogie : fréquence d'apparition de quelque chose ou répétition pendant une période donnée ou dans l'échantillon en question.
  • Avantages : vous permet d'évaluer la fréquence du problème. Peut être converti en notes comme «20 fois par jour». Vous pouvez résumer sous la forme de «toujours», «souvent», «parfois», «rarement», «jamais». Il peut être exprimé en pourcentage: «80% des cas sont concernés».

Note cumulative


Exemple : évaluation du ticket par une combinaison de priorité, d'influence, de dommage, de taille, de MoSCoW et de fréquence.

Supposons qu'un client important soit venu au bureau pour signer un accord dans l'heure, et que l'équipe commerciale ait trouvé une faute de frappe au nom de l'entreprise du client sur le site.

  1. Les vendeurs ont d'abord défini la priorité 1 du ticket.
  2. 1 ( ), .
  3. 3 (), .
  4. «» , .
  5. MoSCoW « », .
  6. 2 %, 2 % .


Voici des exemples de discussion sur les cotes des billets.

- Habituellement, en dehors du danger, la fréquence est également évaluée indépendamment. S'il est peu probable que le bogue se produise lors d'une utilisation normale, même avec un risque élevé, la priorité peut être réduite. C'est généralement de cette façon que les risques sont gérés.

- Un développeur ou un testeur peut bien évaluer le danger d'un bug, mais il ne sait pas si tous les utilisateurs ou seulement certains d'entre eux seront confrontés à ce problème. La fréquence est une autre dimension. La priorité peut être calculée en multipliant le danger par la fréquence.

- Le formulaire doit être le suivant: danger * fréquence - facilité de contournement = priorité. Si l'un des membres de l'équation change (par exemple, une nouvelle solution de contournement est trouvée ou s'il s'avère que presque personne ne se rend sur la page Web qui tombe), la priorité sera ajustée. Il n'y a qu'un seul danger sans «estimer le nombre de personnes qu'il affectera» et «combien cela les affectera-t-il?» Il ne regarde qu'une partie de l'image.

- L'ingénieur QA lors de la recherche initiale a identifié le danger sur la base de critères techniques. Ce n'est qu'un des facteurs que le spécialiste des produits utilise pour déterminer la priorité, qui devient à partir de ce moment un paramètre clé.

- Pour certains utilisateurs, le programme plante parfois, ils perdent tout le travail effectué et sont très en colère. Ils attribuent le plus grand danger au ticket. Mais si une seule personne rencontre un problème, et cela se produit périodiquement, et que l'utilisateur s'est déjà adapté pour économiser plus souvent, alors le technologue du produit devrait donner au ticket une priorité inférieure.

- Le danger caractérise la perception d'un problème par une personne: s'il le rencontre dans un certain cas, il évaluera le danger au maximum. Priorité décrit comment l'équipe de gestion de projet perçoit un bogue: les bogues signalés par les plaignants les plus précieux - les clients qui rapportent beaucoup d'argent, un directeur qui a des difficultés, etc. reçoivent une valeur plus élevée. N'utilisez pas le danger des bogues pour évaluer la priorité car ils sont interconnectés indirectement .

- L'expérience de l'utilisation de la priorité et du danger suggère qu'en théorie, il peut y avoir une différence entre eux, mais en réalité la plupart ne le voient pas. Ces termes sont si souvent confondus qu'ils deviennent inséparables.

- Le système de suivi des bogues interne de Google gère à la fois la priorité et le danger. P0 S0 est la tâche la plus urgente, P2 S2 est la norme, P4 S4 est la moins urgente. C'est un peu une plaisanterie de service que le danger n'a pas de sens (car en fait il ne diffère pas de la priorité).

- Nous n'utilisons que la priorité. Le testeur attribue une valeur initiale basée sur l'heuristique (par exemple, chutes - P1, améliorations cosmétiques - P5). Le développeur se concentre sur cette valeur pour sélectionner les bogues avec lesquels vous devez commencer à travailler en premier. Et puis la priorité est ajustée en fonction de l'expérience utilisateur et du comportement de l'application. Si nous avons vraiment besoin de voir quelles valeurs le testeur a définies, nous utilisons la fonction "historique" ou "révision" dans notre application pour suivre les erreurs.

Modèle de ticket


Le modèle aidera votre équipe à couvrir efficacement et de manière exhaustive des sujets importants.

Il peut utiliser:

  • Le principal plaignant: une description générale du problème donnée par la personne qui l'a rencontré.
  • Participants: qui est impliqué dans la situation - utilisateurs, employés, partenaires, personnes spécifiques, etc.
  • Symptômes: signes évidents d'un problème - opinions des utilisateurs, déclencheurs, alertes, etc.
  • Histoire: informations secondaires pertinentes à la situation - cas similaires, rapports, liens, etc.
  • Diagnostic: ce qui se passe sous le capot - les causes sous-jacentes ou la chaîne de causes, etc.
  • Prévision: évaluation des conséquences potentielles, des changements, etc.
  • Fractures: informations perdues, application en panne, processus bloqué, etc.
  • Traitement: ce que nous faisons pour améliorer la situation - procédures, listes de tâches, restrictions, etc.

Fichier de modèle d'auteur: TEMPLATE.md

Lancement post mortem


Le lancement de messages d'autopsie indiquera à l'équipe quand faire face à la situation.

Vous pouvez exécuter l'analyse:

  • Avec tous les problèmes visibles par l'utilisateur, tels que des plantages ou des erreurs inattendus.
  • En cas d'interventions sur demande, par exemple par des ingénieurs ou la direction.
  • Dans toute enquête sur un incident, car cela reflète la nécessité d'une surveillance.
  • Dans le cas de demandes de parties intéressées d'effectuer des examens, des audits ou de réduire les conséquences d'incidents.

Autopsie innocente


Avec l'autopsie innocente, il vaut la peine de se concentrer sur les symptômes, les causes et le traitement, plutôt que de blâmer quelqu'un. Ces examens commencent par la confirmation que tout le monde a de bonnes intentions, que tout a été fait en utilisant les informations disponibles à ce moment-là.

More articles:


All Articles