wiki/e-compliance/Prozesse/20260528_feature_release_bugfix.md

Auditkonformer Prozess: Feature-Entwicklung, Releases und Bug-Management

Dokumenttyp: Prozessbeschreibung / SOP
Geltungsbereich: Softwareentwicklung, Release Management, Bugfixing
Version: 1.0
Status: Entwurf zur internen Freigabe
Owner: Entwicklung / Produktverantwortung
Letzte Aktualisierung: 28.05.2026

---

1. Zweck des Dokuments

Dieses Dokument beschreibt einen auditkonformen Prozess für:

• die strukturierte Aufnahme, Bewertung und Umsetzung von Feature-Requests,
• die Durchführung technischer Workshops vor Implementierungsbeginn,
• die kontrollierte Entwicklung über Branches, Reviews und Staging-Verifikation,
• die versionierte Erstellung von Release Notes,
• die Erfassung, Priorisierung, Bearbeitung und Dokumentation von Bugs,
• die Nachvollziehbarkeit von Entscheidungen, Änderungen, Verantwortlichkeiten und Freigaben.

Ziel ist es, einen nachvollziehbaren, wiederholbaren und prüfbaren Entwicklungs- und Release-Prozess sicherzustellen.

---

2. Prozessübersicht

Der Gesamtprozess besteht aus zwei Hauptsträngen:

1. Feature-Entwicklung & Releases
2. Bug-Management & Bugfixing

Beide Stränge folgen gemeinsamen Prinzipien:

• zentrale Erfassung aller Anforderungen und Fehler,
• dokumentierte Bewertung und Priorisierung,
• nachvollziehbare technische Entscheidungen,
• Vier-Augen-Prinzip vor produktivem Release,
• dokumentierte Release Notes,
• klare Verantwortlichkeiten,
• prüfbare Nachweise in Tickets, Branches, Pull Requests und Changelogs.

---

3. Prozessbild

flowchart TD

    A[Feature Request oder Bug Report geht ein] --> B{Art des Eingangs}

    B -->|Feature Request| F1[Zentrale Erfassung<br/>z. B. GitHub Issues, Linear, Notion]
    F1 --> F2[Priorisierung nach Kundenwert,<br/>strategischer Relevanz und Aufwand]
    F2 --> F3[Feature mit hoher Priorität<br/>für Tech Workshop vormerken]
    F3 --> F4[Tech Workshop mit beiden Entwicklern]
    F4 --> F5[Architektur-, API-, Datenmodell-<br/>und Schnittstellenanalyse]
    F5 --> F6[Aufwandsschätzung,<br/>Aufgabenverteilung und Akzeptanzkriterien]
    F6 --> F7[Dokumentation im Issue<br/>oder internen Ticket]
    F7 --> F8[Entwicklung auf Feature Branch<br/>feature/kurzbeschreibung]
    F8 --> F9[Commits mit aussagekräftigen Messages<br/>z. B. feat:, fix:, chore:]
    F9 --> F10[Code Review durch zweiten Entwickler]
    F10 --> F11{Review bestanden?}
    F11 -->|Nein| F12[Überarbeitung durch Entwickler]
    F12 --> F10
    F11 -->|Ja| F13[Merge in Main/Development Branch]
    F13 --> F14[Deployment in Staging]
    F14 --> F15[Finale Verifikation gegen Akzeptanzkriterien]
    F15 --> F16{Verifikation bestanden?}
    F16 -->|Nein| F12
    F16 -->|Ja| F17[Release / Push in Produktion]
    F17 --> F18[Release Notes erstellen und versionieren]
    F18 --> F19[CHANGELOG.md und /changelog aktualisieren]

    B -->|Bug Report| G1[Zentrale Erfassung<br/>z. B. ClickUp Formular]
    G1 --> G2[Initiale Antwort gemäß Schweregrad]
    G2 --> G3[Triage durch Mitarbeiter 1]
    G3 --> G4[Prüfung auf Vollständigkeit<br/>und Reproduzierbarkeit]
    G4 --> G5[Klassifizierung:<br/>Kritisch / Hoch / Mittel / Niedrig]
    G5 --> G6[Zuweisung an zuständigen Entwickler]
    G6 --> G7[Fix auf Bugfix Branch<br/>fix/kurzbeschreibung]
    G7 --> G8[Code Review durch Mitarbeiter 1]
    G8 --> G9{Review bestanden?}
    G9 -->|Nein| G10[Nachbesserung durch Entwickler]
    G10 --> G8
    G9 -->|Ja| G11[Merge analog Feature-Prozess]
    G11 --> G12[Staging-Verifikation]
    G12 --> G13{Fix verifiziert?}
    G13 -->|Nein| G10
    G13 -->|Ja| G14[Release in Produktion]
    G14 --> G15[Dokumentation in Release Notes / CHANGELOG]
    G15 --> G16[Melder informieren und Ticket schließen]

---

4. Rollen und Verantwortlichkeiten

Rolle	Verantwortung
Entwickler 1	Teilnahme am Tech Workshop, Entwicklung, Review, ggf. Triage
Entwickler 2	Teilnahme am Tech Workshop, Entwicklung, Review, Release-Durchführung
Mitarbeiter 1 / Triage-Rolle	Prüfung eingehender Bug Reports, Klassifizierung, Reproduzierbarkeit, Zuweisung, Review von Bugfixes
Mitarbeiter 2 / Entwicklungsrolle	Umsetzung von Bugfixes auf separatem Branch, Dokumentation technischer Änderungen
Release-Verantwortlicher	Durchführung des Releases, Pflege der Release Notes, Aktualisierung von CHANGELOG.md und /changelog
Produkt-/Business-Verantwortlicher	Bewertung von Kundenwert und strategischer Relevanz bei Feature Requests

---

5. Feature-Entwicklung & Releases

5.1 Feature-Request-Prozess

Eingehende Feature-Requests werden zentral gesammelt. Mögliche Systeme sind:

• GitHub Issues,
• Linear,
• Notion,
• ein internes Produkt-Backlog.

Jeder Feature Request muss mindestens folgende Informationen enthalten:

Pflichtfeld	Beschreibung
Titel	Kurze, eindeutige Beschreibung des gewünschten Features
Beschreibung	Fachliche Beschreibung des Bedarfs
Nutzen	Erwarteter Mehrwert für Kunden, Nutzer oder internes Team
Quelle	Kunde, interner Stakeholder, Entwickler, Support oder Management
Prioritätsbewertung	Bewertung nach definierten Kriterien
Status	Neu, in Bewertung, geplant, in Umsetzung, umgesetzt, abgelehnt

5.2 Priorisierung

Die Priorisierung erfolgt anhand folgender Kriterien:

Kriterium	Beschreibung	Bewertung
Kundenwert	Relevanz für Nutzer oder Kunden	1 = gering, 2 = mittel, 3 = hoch
Strategische Relevanz	Beitrag zur Produktstrategie	1 = gering, 2 = mittel, 3 = hoch
Implementierungsaufwand	Technischer und organisatorischer Aufwand	1 = gering, 2 = mittel, 3 = hoch

Alternativ kann eine MoSCoW-Kategorisierung verwendet werden:

Kategorie	Bedeutung
Must have	zwingend erforderlich
Should have	wichtig, aber nicht kritisch
Could have	optional, wenn Kapazität vorhanden
Won't have	bewusst zurückgestellt

Features mit höchster Priorität werden für den nächsten Tech Workshop vorgemerkt.

---

5.3 Tech Workshop vor Implementierungsbeginn

Vor der Implementierung priorisierter Features findet ein Tech Workshop statt.

Teilnehmer:

• beide Entwickler,
• optional Produkt-/Business-Verantwortlicher bei fachlicher Klärung.

Inhalte des Tech Workshops:

• Analyse architektonischer Auswirkungen,
• Prüfung betroffener Systeme, Schnittstellen und Datenmodelle,
• Definition möglicher API-Änderungen,
• Definition neuer Endpunkte,
• Prüfung von Abhängigkeiten zu Drittdiensten,
• Aufwandsschätzung,
• Aufgabenverteilung,
• Definition von Akzeptanzkriterien,
• Festlegung von technischen Risiken,
• Dokumentation der Entscheidung.

Auditnachweis:

Das Ergebnis des Tech Workshops wird dokumentiert, z. B. als:

• Issue-Kommentar,
• internes Ticket,
• kurzer Workshop-Vermerk,
• technische Entscheidungsnotiz.

---

5.4 Entwicklungsprozess

Jedes Feature wird auf einem separaten Feature Branch entwickelt.

Branch-Konvention:

feature/kurzbeschreibung

Beispiele:

feature/user-export
feature/payment-dashboard
feature/api-rate-limit

Commit-Konvention:

Commits sollen aussagekräftige Messages enthalten, vorzugsweise nach dem Muster der Conventional Commits.

Beispiele:

feat: add user export endpoint
fix: correct validation for release note dates
chore: update dependency configuration

---

5.5 Code Review

Vor jedem Merge ist ein Code Review durch den jeweils anderen Entwickler erforderlich.

Review-Fokus:

• Codequalität,
• Sicherheit,
• Konsistenz,
• Architektur,
• Einhaltung der Akzeptanzkriterien,
• potenzielle Seiteneffekte,
• Lesbarkeit und Wartbarkeit,
• Auswirkungen auf Schnittstellen oder Datenmodelle.

Auditkontrolle:

Ein Merge darf nur erfolgen, wenn das Review dokumentiert und freigegeben wurde.

---

5.6 Staging-Verifikation und Release

Nach bestandenem Review erfolgt:

1. Merge in den Main- oder Development-Branch,
2. Deployment in die Staging-Umgebung,
3. finale Verifikation gegen die Akzeptanzkriterien,
4. Release bzw. Push in Produktion,
5. Dokumentation im Release-Prozess.

Die produktive Veröffentlichung darf erst erfolgen, wenn die Staging-Verifikation erfolgreich abgeschlossen wurde.

---

6. Release Notes

6.1 Grundsatz

Release Notes werden mit jedem Merge bzw. Release erstellt und versioniert.

Es wird semantische Versionierung verwendet:

MAJOR.MINOR.PATCH

Beispiel:

1.4.2

6.2 Inhalt einer Release Note

Jede Release Note enthält mindestens:

Abschnitt	Inhalt
Versionsnummer	z. B. 1.4.2
Datum	Datum des Releases
Neue Features	kurze Beschreibung, ggf. Nutzen für User
Behobene Bugs	Liste der korrigierten Fehler
Breaking Changes	prominent hervorgehobene inkompatible Änderungen
Technische Änderungen	interne Infrastruktur-, API- oder Architekturänderungen

6.3 Ablageorte

Ablageort	Zielgruppe	Inhalt
CHANGELOG.md im Wiki-Repository	technische Zielgruppe	vollständige Release-Historie
/changelog	intern / technisch	ausführliche Details je Release
Produktbereich	Endnutzer	kurze, nicht-technische Zusammenfassung, derzeit optional

6.4 Verantwortlichkeit

Verantwortlich für die Release Notes ist der Entwickler, der den Release durchführt.

---

7. Bug-Management & Bugfixing

7.1 Eingang und Erstreaktion

Bug Reports werden zentral erfasst, z. B. über ein ClickUp Formular.

Jeder Bug Report soll mindestens enthalten:

Pflichtfeld	Beschreibung
Titel	Kurze Fehlerbeschreibung
Beschreibung	Was ist passiert?
Erwartetes Verhalten	Was hätte passieren sollen?
Tatsächliches Verhalten	Was ist tatsächlich passiert?
Reproduktionsschritte	Schritte zur Nachstellung des Fehlers
Schweregrad	Kritisch, Hoch, Mittel, Niedrig
Screenshots / Logs	falls vorhanden
Melder	Person oder Quelle des Reports

7.2 Initiale Antwortzeiten

Schweregrad	Beschreibung	Initiale Antwort
Kritisch	Produktionsausfall, Datenverlust	innerhalb von 2 Stunden
Hoch	wesentliche Funktion defekt	innerhalb von 1 Werktag
Mittel	eingeschränkte Funktion, Workaround möglich	innerhalb von 2 Werktagen
Niedrig	kosmetisch oder selten auftretend	innerhalb von 5 Werktagen

---

7.3 Triage und Priorisierung

Die Triage wird durch Mitarbeiter 1 durchgeführt.

Aufgaben der Triage-Rolle:

• Prüfung auf Vollständigkeit,
• Prüfung auf Reproduzierbarkeit,
• Rückfrage bei unvollständigen Reports,
• Klassifizierung nach Schweregrad,
• Zuweisung an zuständigen Entwickler,
• Dokumentation der Entscheidung im Ticket.

Schweregrade:

Schweregrad	Definition
Kritisch	Produktionsausfall, Datenverlust, sicherheitsrelevanter Vorfall oder vollständige Nichtnutzbarkeit
Hoch	zentrale Funktion defekt, erhebliche Nutzerbeeinträchtigung
Mittel	eingeschränkte Funktion, Workaround vorhanden
Niedrig	kosmetischer Fehler, seltenes Randverhalten, geringe Auswirkungen

---

7.4 Ziellösungszeiten / SLOs

Priorität	Initiale Antwort	Angestrebte Lösung
Kritisch	2 Stunden	24 Stunden
Hoch	1 Werktag	3 Werktage
Mittel	2 Werktage	2 Wochen
Niedrig	5 Werktage	nächster Release

Die SLOs sind Zielwerte. Abweichungen müssen im Ticket nachvollziehbar begründet werden.

---

7.5 Fixing und Release

Die Umsetzung erfolgt durch Mitarbeiter 2 bzw. den zuständigen Entwickler.

Branch-Konvention:

fix/kurzbeschreibung

Beispiele:

fix/login-timeout
fix/export-validation
fix/payment-status-mapping

Ablauf:

1. Bugfix Branch erstellen,
2. Fehler reproduzieren,
3. Ursache analysieren,
4. Fix implementieren,
5. Tests bzw. Verifikation durchführen,
6. Code Review durch Mitarbeiter 1,
7. Merge analog Feature-Prozess,
8. Deployment in Staging,
9. finale Verifikation,
10. Release in Produktion,
11. Dokumentation in Release Notes / CHANGELOG,
12. Information an Melder,
13. Ticket schließen.

---

8. Kontrollpunkte und Auditnachweise

Kontrollpunkt	Beschreibung	Nachweis
Zentrale Erfassung	Alle Requests und Bugs werden in definierten Systemen erfasst	Issue, Ticket, Formular
Priorisierung	Bewertung anhand definierter Kriterien	Prioritätsfeld, Score, Kommentar
Tech Workshop	technische Analyse vor Implementierung	Workshop-Kommentar, Ticketnotiz
Akzeptanzkriterien	fachliche und technische Erfolgskriterien	Ticketbeschreibung
Branching	getrennte Branches je Feature oder Bugfix	Git Branch
Commit-Konvention	nachvollziehbare Änderungshistorie	Git Commit History
Code Review	Vier-Augen-Prinzip vor Merge	Pull Request Review
Staging-Verifikation	Prüfung vor Produktion	Testkommentar, Checkliste
Release Notes	versionierte Dokumentation jeder Änderung	CHANGELOG.md, /changelog
Bug-Triage	Klassifizierung und Zuweisung	Bug Ticket
SLO-Überwachung	Prüfung von Antwort- und Lösungszeiten	Ticket-Zeitstempel
Ticketabschluss	Abschluss mit nachvollziehbarem Ergebnis	Status, Kommentar, Melderinfo

---

9. Definition of Done

Ein Feature oder Bugfix gilt erst als abgeschlossen, wenn folgende Kriterien erfüllt sind:

• Umsetzung auf separatem Branch erfolgt,
• aussagekräftige Commits vorhanden,
• Code Review durch zweite Person durchgeführt,
• Review-Kommentare wurden bearbeitet,
• Merge in Main/Development erfolgt,
• Staging-Verifikation erfolgreich abgeschlossen,
• Akzeptanzkriterien erfüllt,
• Release Notes aktualisiert,
• CHANGELOG.md bzw. /changelog aktualisiert,
• bei Bugs: Melder informiert,
• Ticket geschlossen oder auf erledigt gesetzt.

---

10. Risiken und Kontrollen

Risiko	Auswirkung	Kontrolle
Unklare Anforderungen	Fehlentwicklung, Rework	Akzeptanzkriterien und Tech Workshop
Fehlende Priorisierung	falsche Ressourcenallokation	Scoring oder MoSCoW
Direkter Merge ohne Review	Qualitäts- und Sicherheitsrisiken	verpflichtendes Vier-Augen-Prinzip
Unvollständige Release Notes	fehlende Nachvollziehbarkeit	Release-Checkliste
Bugs ohne Triage	falsche Dringlichkeit	definierte Triage-Rolle
SLO-Verletzungen ohne Begründung	fehlende Steuerbarkeit	Ticketkommentar bei Abweichung
Produktivfehler nach Release	Nutzerbeeinträchtigung	Staging-Verifikation vor Produktion

---

11. Empfohlene Ticket-Templates

11.1 Feature Request Template

## Feature Request

### Titel
Kurzbeschreibung des Features

### Beschreibung
Was soll umgesetzt werden?

### Nutzen
Welchen Mehrwert liefert das Feature?

### Quelle
Kunde / intern / Support / Management

### Priorisierung
- Kundenwert: 1 / 2 / 3
- Strategische Relevanz: 1 / 2 / 3
- Implementierungsaufwand: 1 / 2 / 3

### Akzeptanzkriterien
- [ ] Kriterium 1
- [ ] Kriterium 2
- [ ] Kriterium 3

### Technische Hinweise
Betroffene Systeme, APIs, Datenmodelle oder Schnittstellen

### Entscheidung Tech Workshop
Kurzprotokoll / Ergebnis

---

11.2 Bug Report Template

## Bug Report

### Titel
Kurzbeschreibung des Fehlers

### Beschreibung
Was ist passiert?

### Erwartetes Verhalten
Was hätte passieren sollen?

### Tatsächliches Verhalten
Was ist tatsächlich passiert?

### Reproduktionsschritte
1. Schritt 1
2. Schritt 2
3. Schritt 3

### Schweregrad
Kritisch / Hoch / Mittel / Niedrig

### Auswirkungen
Welche Nutzer, Systeme oder Daten sind betroffen?

### Workaround
Ja / Nein / Beschreibung

### Anhänge
Screenshots, Logs, Videos

### Triage-Ergebnis
- Vollständig: Ja / Nein
- Reproduzierbar: Ja / Nein
- Zugewiesen an:
- Zieltermin:

---

11.3 Release Note Template

# Release Notes

## Version
x.y.z

## Datum
TT.MM.JJJJ

## Neue Features
- Beschreibung des Features und Nutzen

## Behobene Bugs
- Beschreibung des behobenen Fehlers

## Breaking Changes
- Keine / Beschreibung der Änderung

## Technische Änderungen
- API, Infrastruktur, Datenmodell oder Abhängigkeiten

## Verantwortlich
Name des Release-Verantwortlichen

## Referenzen
- Issue / Ticket / Pull Request

---

12. Freigabe und Review des Prozesses

Dieser Prozess sollte regelmäßig überprüft werden, mindestens jedoch:

• bei wesentlichen Änderungen am Entwicklungsprozess,
• bei Einführung neuer Tools,
• nach größeren Incidents,
• vor externen Audits,
• mindestens einmal jährlich.

Freigabefeld	Eintrag
Prozessverantwortlicher
Fachliche Freigabe
Technische Freigabe
Datum der Freigabe
Nächste Überprüfung

---

13. Kurzfazit

Der beschriebene Prozess stellt sicher, dass Feature-Entwicklung, Bugfixing und Releases kontrolliert, nachvollziehbar und auditfähig durchgeführt werden. Durch zentrale Erfassung, klare Rollen, dokumentierte Priorisierung, Tech Workshops, Branching-Konventionen, Code Reviews, Staging-Verifikation und versionierte Release Notes entsteht ein robuster Entwicklungsprozess mit belastbaren Nachweisen für interne und externe Prüfungen.