🚁 👨‍👨‍👧‍👧 👇 Wie man effektiv mit Problemen bei Problemen auf GitHub arbeitet ⛔️ 😐 🌘

Tickets auf GitHub sind unterschiedlich: Anforderungen für die Implementierung einiger Funktionen, Fehlerberichte, Beschwerden von Kunden, Warnungen von Sicherheitssystemen, Rückblicke für das Team usw. Hier sehen wir, wie das Team sie verwenden und diskutieren kann.

Inhalt:

Was ist ein Ticket?

Für viele Teams ist „Ticket“ ein Oberbegriff, der Folgendes bedeuten kann:

Antrag auf Implementierung von Funktionen.
Fehlermeldung.
Kundenbeschwerde.
Sicherheitsalarm.
Rückblick für das Team.

Öffentlich oder privat?

Für Projekte können Sie öffentliche und private Tickets erstellen. Öffentlich sind in der Regel für Benutzer, Kunden, Agenten usw. bestimmt. Privat - für Entwickler, Auftragnehmer, Partner usw.

Für öffentliche Tickets

Konzentrieren Sie sich auf das Endergebnis.
Betonen Sie, was getan werden kann.
Veröffentlichen Sie keine vertraulichen Informationen.

Für private Tickets

Konzentrieren Sie sich auf die Details.
Markieren Sie Forschungsinformationen, da dies dazu beiträgt, mögliche Muster zwischen verschiedenen Tickets zu identifizieren.
Fügen Sie nach Bedarf vertrauliche Informationen hinzu.

Bewertung

Alle Tickets müssen so bewertet werden, dass sie miteinander verglichen werden können und verstanden werden, woran genau gearbeitet werden muss. Es gibt verschiedene Möglichkeiten, die folgenden zu bewerten, und in der Praxis funktionieren sie gut.

Prioritätsbewertung

Beispiel : Priorität 1 (zuerst ausführen), Priorität 2 (zweite ausführen), Priorität 3 (dritte ausführen) usw.
Analogie : Eine Aufgabenliste, in der Priorität 1 die höchste Priorität hat.
: , . , .
: 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 : Die Häufigkeit des Auftretens von etwas oder der Wiederholung während eines bestimmten Zeitraums oder in der betreffenden Stichprobe.
Vorteile : Hier können Sie bewerten, wie oft das Problem auftritt. Kann in Noten wie "20 mal am Tag" umgewandelt werden. Sie können in Form von "immer", "oft", "manchmal", "selten", "nie" zusammenfassen. Es kann als Prozentsatz ausgedrückt werden: „80% der Fälle sind betroffen.“

Kumulative Bewertung

Beispiel : Ticketbewertung durch eine Kombination aus Priorität, Einfluss, Schaden, Größe, MoSCoW und Häufigkeit.

Angenommen, ein wichtiger Kunde kam innerhalb einer Stunde ins Büro, um eine Vereinbarung zu unterzeichnen, und das Verkaufsteam fand einen Tippfehler im Namen des Unternehmens des Kunden auf der Website.

Verkäufer legen zuerst die Ticketpriorität 1 fest.
1 ( ), .
3 (), .
«» , .
MoSCoW « », .
2 %, 2 % .

Hier finden Sie Beispiele für die Diskussion von Ticketbewertungen.

- Normalerweise wird neben der Gefahr auch die Frequenz unabhängig ausgewertet. Wenn es unwahrscheinlich ist, dass der Fehler während des normalen Gebrauchs auftritt, kann die Priorität auch bei hohem Risiko verringert werden. So werden Risiken normalerweise gehandhabt.

- Ein Entwickler oder Tester kann die Gefahr eines Fehlers gut einschätzen, weiß jedoch nicht, ob alle Benutzer oder nur einige von ihnen mit diesem Problem konfrontiert sind. Frequenz ist eine andere Dimension. Die Priorität kann berechnet werden, indem die Gefahr mit der Häufigkeit multipliziert wird.

- Das Formular sollte wie folgt aussehen: Gefahr * Häufigkeit - einfache Problemumgehung = Priorität. Wenn sich ein Mitglied der Gleichung ändert (z. B. eine neue Problemumgehung gefunden wird oder sich herausstellt, dass fast niemand zur fallenden Webseite geht), wird die Priorität angepasst. Es gibt nur eine Gefahr, ohne „die Anzahl der betroffenen Personen abzuschätzen“ und „wie stark werden sie davon betroffen sein“. Es sieht nur ein Teil des Bildes aus.

- Der QS-Ingenieur identifizierte die Gefahr während der ersten Forschung anhand technischer Kriterien. Dies ist nur einer der Faktoren, die der Produktspezialist bei der Bestimmung der Priorität verwendet, die ab diesem Zeitpunkt zu einem Schlüsselparameter wird.

- Bei einigen Benutzern stürzt das Programm manchmal ab, sie verlieren die gesamte geleistete Arbeit und sind sehr wütend. Sie weisen dem Ticket die höchste Gefahr zu. Wenn jedoch nur eine Person auf ein Problem stößt und dies in regelmäßigen Abständen geschieht und der Benutzer sich bereits angepasst hat, um häufiger zu sparen, sollte der Produkttechnologe dem Ticket eine niedrigere Priorität einräumen.

- Gefahr kennzeichnet die Wahrnehmung eines Problems durch eine Person: Wenn sie in einem bestimmten Fall darauf stößt, bewertet sie die Gefahr als maximal. Die Priorität beschreibt, wie das Projektmanagementteam einen Fehler wahrnimmt: Fehler, die von den wertvollsten Beschwerdeführern gemeldet werden - Kunden, die viel Geld mitbringen, ein Direktor, der Schwierigkeiten hat usw. erhalten einen höheren Wert. Nutzen Sie die Gefahr von Fehlern nicht, um die Priorität zu bewerten, da sie indirekt miteinander verbunden sind .

- Die Erfahrung mit Priorität und Gefahr legt nahe, dass es theoretisch einen Unterschied zwischen ihnen geben kann, aber in Wirklichkeit sehen die meisten dies nicht. Diese Begriffe werden so oft verwechselt, dass sie untrennbar miteinander verbunden sind.

- Das interne Fehlerverfolgungssystem von Google behandelt sowohl Priorität als auch Gefahr. P0 S0 ist die dringendste Aufgabe, P2 S2 ist der Standard, P4 S4 ist die am wenigsten dringende. Dies ist ein Witz im Dienst, dass Gefahr keinen Sinn ergibt (weil sie sich tatsächlich nicht von der Priorität unterscheidet).

- Wir verwenden nur Priorität. Der Tester weist basierend auf den Heuristiken einen Anfangswert zu (z. B. Stürze - P1, kosmetische Verbesserungen - P5). Der Entwickler konzentriert sich auf diesen Wert, um die Fehler auszuwählen, mit denen Sie zuerst arbeiten müssen. Anschließend wird die Priorität entsprechend der Benutzererfahrung und dem Anwendungsverhalten angepasst. Wenn wir wirklich sehen müssen, welche Werte der Tester festgelegt hat, verwenden wir die Funktion "Verlauf" oder "Revision" in unserer Anwendung, um Fehler zu verfolgen.

Ticketvorlage

Die Vorlage hilft Ihrem Team dabei, wichtige Themen effektiv und umfassend abzudecken.

Es kann verwenden:

Der Hauptbeschwerdeführer: eine allgemeine Beschreibung des Problems durch die Person, die darauf gestoßen ist.
Teilnehmer: Wer ist in die Situation involviert - Benutzer, Mitarbeiter, Partner, bestimmte Personen usw.
Symptome: offensichtliche Anzeichen eines Problems - Meinungen der Benutzer, Auslöser, Warnungen usw.
Verlauf: Sekundärinformationen, die für die Situation relevant sind - ähnliche Fälle, Berichte, Links usw.
Diagnose: Was passiert unter der Haube - die zugrunde liegenden Ursachen oder Ursachenketten usw.
Prognose: Einschätzung möglicher Folgen, Veränderungen usw.
Frakturen: Informationsverlust, Absturz der Anwendung, blockierter Prozess usw.
Behandlung: Was wir tun, um die Situation zu verbessern - Verfahren, Aufgabenlisten, Einschränkungen usw.

Autorenvorlagendatei: TEMPLATE.md

Postmortaler Start

Der Start von Post-Mortem-Nachrichten teilt dem Team mit, wann es mit der Situation umgehen soll.

Sie können die Analyse ausführen:

Bei Problemen, die für den Benutzer erkennbar sind, z. B. unerwartete Abstürze oder Fehler.
Im Falle von Eingriffen auf Anfrage, zum Beispiel von Ingenieuren oder dem Management.
Bei jeder Vorfalluntersuchung, da dies die Notwendigkeit einer Überwachung widerspiegelt.
Bei Anfragen von Interessenten, Überprüfungen durchzuführen, Audits durchzuführen oder die Folgen von Vorfällen zu verringern.

Unschuldige Obduktion

Bei unschuldiger Obduktion lohnt es sich, sich auf die Symptome, Ursachen und Behandlung zu konzentrieren, anstatt jemandem die Schuld zu geben. Solche Überprüfungen beginnen mit der Bestätigung, dass jeder gute Absichten hat und dass alles Mögliche unter Verwendung der zu diesem Zeitpunkt verfügbaren Informationen getan wurde.

Wie man effektiv mit Problemen bei Problemen auf GitHub arbeitet