# 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

```mermaid
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:**

```text
feature/kurzbeschreibung
```

**Beispiele:**

```text
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:**

```text
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:

```text
MAJOR.MINOR.PATCH
```

**Beispiel:**

```text
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:**

```text
fix/kurzbeschreibung
```

**Beispiele:**

```text
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

```markdown
## 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

```markdown
## 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

```markdown
# 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.