ABAP Cloud Projektmanagement: Agile Methoden fuer SAP-Projekte

Sprint-Struktur fuer ABAP Cloud:
┌─────────────────────────────────────────────────┐
│ Sprint Planning (4h)                            │
│ - Backlog Refinement mit Business Analyst       │
│ - Story Point Schaetzung (Planning Poker)       │
│ - Sprint Goal definieren                        │
└─────────────────────────────────────────────────┘
           │
           ▼
┌─────────────────────────────────────────────────┐
│ Sprint (2 Wochen)                               │
│ - Daily Standup (15 min)                        │
│ - Pair Programming Sessions                    │
│ - Continuous Integration                        │
│ - Code Reviews                                  │
└─────────────────────────────────────────────────┘
           │
           ▼
┌─────────────────────────────────────────────────┐
│ Sprint Review + Retrospektive (2h + 1h)         │
│ - Demo fuer Stakeholder                         │
│ - Feedback einarbeiten                          │
│ - Prozessverbesserungen                         │
└─────────────────────────────────────────────────┘

Kanban Board fuer ABAP Cloud:

┌──────────┬──────────┬──────────┬──────────┬──────────┐
│ Backlog  │ Analysis │ Dev      │ Review   │ Done     │
├──────────┼──────────┼──────────┼──────────┼──────────┤
│ ┌──────┐ │ ┌──────┐ │ ┌──────┐ │ ┌──────┐ │ ┌──────┐ │
│ │Bug-42│ │ │US-123│ │ │US-119│ │ │US-115│ │ │US-110│ │
│ └──────┘ │ └──────┘ │ └──────┘ │ └──────┘ │ └──────┘ │
│ ┌──────┐ │          │ ┌──────┐ │          │ ┌──────┐ │
│ │US-130│ │          │ │US-120│ │          │ │US-111│ │
│ └──────┘ │          │ └──────┘ │          │ └──────┘ │
│          │          │          │          │          │
│ WIP: ∞   │ WIP: 2   │ WIP: 3   │ WIP: 2   │ WIP: ∞   │
└──────────┴──────────┴──────────┴──────────┴──────────┘

Jahresplanung ABAP Cloud Team:

Q1 2026:
┌─────────────────────────────────────────────────────────────┐
│ Jan        │ Feb        │ Mrz                               │
├─────────────────────────────────────────────────────────────┤
│ Sprint 1   │ Sprint 2   │ Sprint 3   │ Sprint 4   │ Sprint 5│
│            │            │ ▲ SAP Feb Release                 │
│            │            │ (2 Tage Upgrade-Buffer)           │
└─────────────────────────────────────────────────────────────┘

Sprint 3 Besonderheiten:
- Reduzierte Velocity (Upgrade-Aufwand einplanen)
- Upgrade-Testing als Sprint-Ziel
- Release Notes Review

Als [Rolle]
moechte ich [Funktionalitaet]
damit [Nutzen].

Akzeptanzkriterien:
□ [Testbares Kriterium 1]
□ [Testbares Kriterium 2]
□ [Testbares Kriterium 3]

Technische Hinweise:
- CDS Entity: ZI_[EntityName]
- Behavior: managed/unmanaged
- UI: List Report / Object Page

US-042: Bestellpositionen verwalten

Als Einkaeuferin
moechte ich Bestellpositionen in der Fiori-App anlegen und bearbeiten
damit ich Bestellungen vollstaendig erfassen kann.

Akzeptanzkriterien:
□ Positionen koennen im Object Page angelegt werden
□ Material-ID mit Value Help auswaehlen
□ Menge und Einheit erfassen (Pflichtfelder)
□ Preis wird automatisch aus Materialstamm uebernommen
□ Loeschen mit Bestaetigung
□ Validierung: Menge > 0
□ Summe wird im Header aktualisiert

Technische Hinweise:
- Parent Entity: ZI_PurchaseOrder
- Child Entity: ZI_PurchaseOrderItem (Composition)
- Draft-faehig
- Numbering: Late Numbering fuer ItemNumber

Definition of Done:
□ Code implementiert und getestet
□ Unit Tests > 80% Coverage
□ Code Review bestanden
□ ATC ohne Fehler
□ Dokumentation aktualisiert

Epic: Lieferanten-Verwaltung

User Stories:
1. Lieferanten anzeigen (Read-Only List Report)
   - Effort: 3 Story Points

2. Lieferanten anlegen (Create)
   - Effort: 5 Story Points

3. Lieferanten bearbeiten (Update)
   - Effort: 3 Story Points

4. Lieferanten sperren (Action)
   - Effort: 2 Story Points

5. Lieferanten-Historie (Readonly View)
   - Effort: 3 Story Points

6. Lieferantenbewertung (Child Entity)
   - Effort: 5 Story Points

Gesamt: 21 Story Points
Release: 2-3 Sprints

Definition of Done - ABAP Cloud Team

□ Code
  - Implementierung abgeschlossen
  - Clean ABAP Richtlinien befolgt
  - Keine Hardcoded Strings (Textelemente nutzen)
  - Fehlerbehandlung implementiert

□ Testing
  - Unit Tests vorhanden (min. 80% Coverage)
  - Integration Tests fuer RAP-Logik
  - Manuelle Tests auf Dev-System durchgefuehrt
  - Edge Cases getestet

□ Qualitaetssicherung
  - ATC ohne Errors (Warnings dokumentiert)
  - Code Review durch min. 1 Teammitglied
  - Keine offenen SonarQube Issues

□ Dokumentation
  - Code-Kommentare wo noetig
  - API-Dokumentation aktualisiert
  - README.md bei neuen Komponenten

□ Deployment
  - In Development-System getestet
  - Transport erstellt (nicht freigegeben)
  - Release Notes aktualisiert

US-042 spezifische DoD:
□ Performance: Listenabruf < 2 Sekunden
□ Barrierefreiheit: Alle Felder mit Labels
□ Mobile: Responsive Layout getestet

DoD Review (quartalsweise):

Retrospektive-Fragen:
- Welche Bugs haetten wir mit zusaetzlichen Checks verhindert?
- Welche Checks kosten Zeit, bringen aber wenig?
- Welche neuen Tools/Practices sollten wir aufnehmen?

Beispiel-Anpassung Q2 2026:
+ Security Scan mit ATC Security Checks
+ Accessibility Test mit axe-core
- Manuelle Cross-Browser Tests (automatisiert)

Stakeholder-Matrix:

                    Einfluss
                 hoch    niedrig
            ┌─────────┬─────────┐
     hoch   │ MANAGE  │ INFORM  │
            │         │         │
Interesse   │ - PM    │ - End-  │
            │ - IT-   │   user  │
            │   Leiter│ - Auditor│
            ├─────────┼─────────┤
     niedrig│ SATISFY │ MONITOR │
            │         │         │
            │ - CFO   │ - HR    │
            │ - Legal │ - Andere│
            │         │   Teams │
            └─────────┴─────────┘

Feedback-Mechanismen:

1. Sprint Review (alle 2 Wochen)
   - Live-Demo neuer Features
   - Direktes Feedback von Fachbereich
   - Backlog-Priorisierung

2. User Acceptance Testing (vor Release)
   - Definierte Testszenarien
   - Dokumentierte Findings
   - Go/No-Go Entscheidung

3. Post-Release Survey (nach 2 Wochen)
   - NPS-Score
   - Verbesserungsvorschlaege
   - Bug-Reports

4. Quarterly Business Review
   - Zielerreichung
   - ROI-Betrachtung
   - Strategische Ausrichtung

# Sprint [X] Planning - [Datum]

## Sprint Goal
[Ein Satz, der den Mehrwert des Sprints beschreibt]

## Velocity
- Team Velocity (Durchschnitt): [X] Story Points
- Verfuegbare Kapazitaet: [X] Personentage
- Geplante Velocity: [X] Story Points

## Sprint Backlog

| ID | Story | SP | Assignee | Status |
|----|-------|-----|----------|--------|
| US-042 | Bestellpositionen | 5 | @dev1 | Committed |
| US-043 | Validierungen | 3 | @dev2 | Committed |
| BUG-12 | Preisberechnung | 2 | @dev1 | Committed |

## Risiken
- [ ] SAP-Update am [Datum]
- [ ] [Teammitglied] 2 Tage Urlaub

## Abhaengigkeiten
- US-043 benoetigt API-Spezifikation von Team B

# Sprint [X] Retrospektive - [Datum]

## Was lief gut? (Keep)
-
-

## Was war herausfordernd? (Drop/Improve)
-
-

## Neue Ideen (Try)
-
-

## Action Items
| Action | Owner | Deadline |
|--------|-------|----------|
| | | |

## Metriken
- Velocity: [X] SP (Plan: [Y] SP)
- Bugs: [X] (Vorheriger Sprint: [Y])
- Cycle Time: [X] Tage

# Definition of Ready

Eine User Story ist bereit fuer den Sprint, wenn:

□ Beschreibung
  - User Story Format (Als... moechte ich... damit...)
  - Akzeptanzkriterien vorhanden
  - Technische Hinweise dokumentiert

□ Schaetzung
  - Story Points vergeben
  - Team hat Story verstanden
  - Keine offenen Fragen

□ Abhaengigkeiten
  - Externe Abhaengigkeiten identifiziert
  - Mockups/Designs verfuegbar (falls UI)
  - Testdaten vorhanden

□ Groesse
  - Max. 8 Story Points
  - In einem Sprint abschliessbar

Sprint Burndown Chart:

SP │
20 │■
   │ ■
15 │   ■ ─ ─ Ideal
   │     ■
10 │       ■     ● Actual
   │         ■ ●
 5 │           ● ■
   │             ● ■
 0 │──────────────●─■────
   │ M  D  M  D  F  M  D  F