Zum Haaptinhalt sprangen

Severity Categories

1. Introduktioun (Fir Clienten & Partner)​

Eis Severity Categories definéieren wéi mir Bugs a Virfäll klassifizéieren baséiert op hirem Impakt, Dringlechkeet, an Ëmfang. Andeems mir e Schwieregkeetsniveau zouweisen, kënnen eis Teams d'Reparaturen effizient prioriséieren an assuréieren, datt kritesch Problemer direkt Opmierksamkeet kréien. Dëse transparente Klassifikatiounsprozess hëlleft Clienten a Partner ze verstoen, wéi mir Problemer verwalten an léisen, fir d'Produktstabilitéit a Qualitéit ze garantéieren.

2. Wéi ass involvéiert​

RollBeteiligungVirdeel fir Iech
Produkt ManagerIwwerpréift Incident Berichter an assuréiert datt d'Schweregrad Klassifikatiounen mat de Geschäftsprioritéiten übereenstëmmen.Hëlleft ze garantéieren, datt kritesch Problemer prioriséiert a séier behandelt ginn.
EntwécklungsteamAnalyséiert Bugs an assignéiert d'Schweregrad baséiert op technescher Auswierkung an potentiellen Risiken.Garantéiert datt Ressourcen baséiert op der tatsächlecher Auswierkung vum Problem allocéiert ginn.

| QA/Testing Team | Validéiert d'Gravitéit duerch ëmfaassend Tester an Qualitéitsbewäertungen. | Bitt Sécherheet datt Problemer richteg prioriséiert ginn fir Léisung. | | Stakeholders/Clients | Kritt Updates iwwer kritesch Zäitschrëften an d'Schrëtt déi geholl goufen fir se ze léisen. | Garantéiert Transparenz iwwer wéi dringende Problemer verwalt ginn. |

3. Iwwerbléck iwwer d'Schwerekategorien​

Hei sinn d'Haapt-Schweregradniveauen, déi mir benotzen fir d'Zesummenhang vun den Incidents ze kategoriséieren:

  • Kritesch (Schweregrad 1):

    • Definitioun: Problemer, déi eng komplett Systemausfall oder kritesch Funktiounsfehler verursaachen, déi d'Benotzeroperatiounen schwéier beaflossen.
    • Reaktioun: Sofort Opmierksamkeet mat engem Hotfix, deen am aktuellen Sprint implementéiert gëtt.

  • Héich (Schweregrad 2):

    • Definitioun: Problemer, déi d'Funktioun wesentlech beaflossen, ouni d'Operatiounen komplett ze stoppen.
    • Reaktioun: Prioriséiert fir Léisung am aktuellen oder nächste Sprint.

  • Mënschlech (Schweregrad 3):

    • Definitioun: Problemer, déi net-kritesch Funktiounen beaflossen oder e moderaten Impakt op d'Benotzererfarung hunn.
    • Reaktioun: Geplangt fir Léisung an den kommende Sprints, souwäit d'Ressourcen et erlaaben.

  • Low (Severity 4):

    • Definition: Kleng Problemer, dorënner kosmetesch oder trivial Bugs, déi minimal Auswierkung op d'gesamt Funktioun hunn.
    • Response: Behandelt während regulärer Ënnerhaltungs- oder Backlog Refinement Sessiounen.

4. Prozessfloss / Diagramm​

Hei ass eng Iwwerbléck wéi d'Schweregradkategorien ugewannt ginn, mat doppelten Zitéierungen fir d'Mermaid Labels:

  1. Feeler oder Incident gemellt: Eng Problem gëtt iwwer eis Reporting-Kanäler agemellt.
  2. Initial Triage & Bewäertung: Eis Teams maachen eng préliminär Evaluatioun fir den Impakt vum Problem ze bestëmmen.
  3. Schäerf Niveau zouweisen: Baséierend op der Bewäertung gëtt d'Problem als Kritesch, Héich, Mënschlech, oder Niddereg klasséiert.
  4. Reaktiounshandlungen:
    • Kritesch: Sofort Hotfix.
    • Héich: Prioriséiert fir de aktuelle oder nächsten Sprint.
    • Mënschlech: Geplangt fir d'Léisung an den kommende Sprints.
    • Niddereg: Gestiéiert während der regulärer Backlog Refinement.

5. FAQ​

Q1: Wat sinn Severity Categories?
A1: Severity Categories sinn Klassifikatiounen, déi d'Urgency an d'Impakt vun Bugs oder Incidénte bestëmmen, an déi eis Reaktioun an Prioriséierung guidéieren.

Q2: Wéi bestëmmt d'Severity vun engem Problem?
A2: D'Entwécklungs- an QA-Teams maachen eng initial Triage, mat Iwwerwaachung vum Product Manager fir sécherzestellen, datt et mat de Geschäftsprioritéiten übereestëmmt.

Q3: Wéi séier ginn kritisch Problemer behandelt?
A3: Kritesch Problemer kréien direkt Opmierksamkeet an sinn typesch duerch e Hotfix an der aktueller Sprint geléist.

Q4: Wéi profitéieren d'Clienten vun der Severity Klassifikatioun?
A4: Et gëtt kloerheet iwwer eise Prioriséierungsprozess, wat sécherstellt, datt déi meescht impaktvoll Problemer séier geléist ginn, fir d'Produktstabilitéit z'erhaalen.

6. Nächste Schrëtt an zousätzlech Ressourcen​

  • Bug Lifecycle: Léiert méi iwwer wéi Problemer vun der Berichterstattung bis zur Léisung progresséieren op eiser Bug Lifecycle Säit.
  • Backlog Management: Entdeckt eis Approche fir d'Gestion an d'Prioriséierung vun den gemeldeten Problemer op eiser Backlog Management Säit.
  • Kontaktéiert eis: Fir weider Froen oder urgent Uleien, kontaktéiert eis w.e.g. iwwer contact support oder chat mat eisem Team op eiser Websäit.