# Development Methodologies
## Classic / Plan-based
### Waterfall Model
- [OOAD Waterfall](SoftwareProcesses.md#waterfall-model)
- Einzelne Phasen werden sequentiell durchlaufen
- Phasen überlappen sich kaum oder nicht
- Sobald eine Phase abgeschlossen ist, wird sie nicht mehr verändert

- Nur für kleine Projekte geeignet

### V-Model
- [OOAD V-Model](SoftwareProcesses.md#v-modell)
- Erweiterung des Waterfall-Modells
- Testphasen werden explizit in den Entwicklungsprozess integriert
- Jede Phase hat eine zugehörige Testphase

### Spiral Model
- [OOAD Spiral Model](SoftwareProcesses.md#spiral-modell)
- Iteratives Modell, das die Phasen des Waterfall-Modells in Zyklen durchläuft


## Agile
### The Agile Manifesto
#### 4 Werte
- **Individuen und Interaktionen** über _Prozesse und Werkzeuge_
- **Funktionierende Software** über _verständliche Dokumentation_
- **Arbeit mit Kunden** über _Vertragsverhandlungen_
- **Anpassung an Veränderung** über _folgen des Plans_

#### 12 Prinzipien
![image_901.png](image_901.png)
1. Kunden glücklich machen
    - Frühe und durchgehende Lieferung von wertvoller Software
    - Auf Kundenfeedback reagieren
2. Anforderungsänderungen willkommen heißen
    - Auch spät in der Entwicklung
3. Regelmäßig funktionierende Software liefern
    - Alle paar Wochen - Monate
    - Viele Vorteile durch kurze Iterationen
4. Tägliche Zusammenarbeit
    - Entwickler, Tester, Kunden
5. Projekte um motivierte Individuen aufbauen
    - Vertrauen in die Teammitglieder
    - Gute Umgebung und Unterstützung
6. Face-to-Face Kommunikation
    - Effektivste Methode der Kommunikation
7. Fortschritt in funktionierender Software messen
    - Nicht in Dokumentation oder Berichten
8. Konstante Geschwindigkeit halten (Marathon, nicht Sprint) 
    - Nicht zu viel vornehmen
9. Technische Exzellenz und gutes Design
    - Verbessert die Agilität
    - Weniger technische Schulden
10. Einfachheit
    - Die Kunst, die Menge an nicht gemachter Arbeit zu maximieren
    - Weniger Features, die nicht benötigt werden
11. Vertraue deinem Team
    - Selbstorganisierte Teams
    - Cross-funktionale Teams
12. Reflektieren und Anpassen
    - Regelmäßige Retrospektiven
    - Kontinuierliche Verbesserung

## Agile: Scrum
### Scrum Theory
- Scrum ist ein agiles Framework für die Softwareentwicklung
- Fokus auf Transparenz, Inspektion und Anpassung

#### Scrum Pillars
- **Transparenz**
  - Alle Aspekte des Prozesses sind sichtbar für alle Beteiligten
  - Ermöglicht informierte Entscheidungen
- **Inspektion**
  - Alle Aspekte des Prozesses und der Arbeitsergebnisse werden regelmäßig überprüft
  - Frühzeitiges Erkennen von Problemen
- **Adaption**
  - Alle Aspekte des Prozesses und der Arbeitsergebnisse werden angepasst, wenn nötig
  - Kontinuierliche Verbesserung des Prozesses

### Scrum Team
- fokussiert sich nur auf das Ziel des Projekts
- ist cross-funktional
  - alle notwendigen Fähigkeiten sind im Team vorhanden
  - managed sich selbst

#### Product Owner
![image_903.png](image_903.png)

- Verantwortlich für den Erfolg des Produkts
  - Stellt sicher, dass das Team den höchsten Wert liefert
  - Kommuniziert mit Stakeholdern
- Verantwortlich für das Product Backlog
  - Was wird wann gemacht?
- Skillset:
  - Domain
    - Produktvision haben und das Team leiten
    - tiefgreifende Business- und Domainkenntnisse
  - People
    - "Stimme der Kunden"
    - Gutes Verhältnis mit jedem
  - Decision-Making
    - (schwere) Entscheidungen über Features und Releases treffen
    - Prioritäten setzen
  - Verantwortung
    - Verantwortung für den (Miss-)Erfolg des Produkts
    - Klare Kommunikation der Ziele und Prioritäten

#### Scrum Master
![image_904.png](image_904.png)
- Verantwortlich für den Scrum-Prozess
  - Moderation der Meetings
  - Beseitigung von Hindernissen
- Skillset:
  - Scrum
    - tiefgreifendes Wissen über Scrum und agile Methoden
  - Kollaborativ
    - arbeitet eng mit dem gesamten Team zusammen
    - fördert Selbstorganisation
  - Coaching
    - Team bei der kontinuierlichen Verbesserung unterstützen
    - Fragen stellen, um das Team zum Nachdenken zu bringen
  - Beschützend
    - vor äußeren Störungen schützen
      - z.B. Meetings, die während des Sprints stattfinden
  - Transparent
    - sorgt dafür, dass alle Aspekte des Prozesses transparent sind
    - fördert offene Kommunikation im Team

#### Development Team
![image_905.png](image_905.png)
- Verantwortlich für die Umsetzung der Arbeit
  - Liefert das Inkrement am Ende jedes Sprints
- Skillset:
  - Cross-funktional
    - Alle notwendigen Fähigkeiten sind im Team vorhanden
    - Jeder kann an jedem Feature arbeiten
  - Selbstorganisiert
    - Team entscheidet, wie die Arbeit erledigt wird
    - Keine externen Anweisungen
  - T-Shaped Skills
    - Teammitglieder haben tiefes Wissen in ihrem Bereich
    - Breites Wissen über andere Bereiche
  - Teamorientiert
    - einer für alle, alle für einen
    - gemeinsame Verantwortung für den Erfolg des Sprints
  - Kommunikativ
    - offener Austausch im Team
    - regelmäßige Updates über den Fortschritt
  - richtige Größe
    - ≤ 10 Personen
    - zu große Teams führen zu Kommunikationsproblemen und Ineffizienz
    - zu kleine Teams haben nicht genug Fähigkeiten, um alle Aufgaben zu erledigen

### Scrum Events
![image_902.png](image_902.png)
#### Sprint
- Zeitfenster von 1 bis 4 Wochen
- Ziel: Ein Inkrement liefern
#### Sprint Planning
- initiiert den Sprint
- Ziele und Aufgaben für den Sprint festlegen
  - Warum ist der Sprint wichtig?
  - Was soll erreicht werden?
  - Wie wird entschieden, was im Sprint umgesetzt wird?
    - Sprint Kapazität muss berücksichtigt werden
- PO präsentiert das Product Backlog
- Input:
  - Product Backlog
  - Team-Kapazität
  - Abhängigkeiten
  - Team-Fähigkeiten
  - Initiales Sprint-Ziel
- Arten:
  - **2-Part Sprint Planning**
    1. Teil: _Was wird im Sprint gemacht?_
       - PO präsentiert das Product Backlog
       - Team wählt Items aus, die sie umsetzen können
    2. Teil: _Wie wird es umgesetzt?_
       - Team plant die Umsetzung der ausgewählten Items
       - Aufgaben werden aufgeteilt und geschätzt
    - ![image_906.png](image_906.png)
  - **1-Part Sprint Planning**
    - Team eruiert Kapazität
      - Sprint-Ziel ggf. anpassen
    - Team wählt Items aus dem Product Backlog aus
    - ![image_907.png](image_907.png)

#### Sprint Execution
- Daily Scrum
  - 15min tägliches Meeting
  - Jeder beantwortet 3 Fragen:
    - _Was habe ich seit dem letzten Meeting gemacht?_
    - _Was werde ich bis zum nächsten Meeting tun?_
    - _Gibt es Hindernisse/Hilfsbedarf?_
- Input:
  - Task-Board
    - ![image_908.png](image_908.png)
  - Sprint Burndown Chart
    - Grafik, die zu erledigende Arbeit vs verbleibende Zeit zeigt
    - ![image_909.png](image_909.png)

#### Sprint Review
- Ergebnisse des Sprints präsentieren
- Feedback von Stakeholdern einholen
- Anpassungen am Product Backlog vornehmen

#### Sprint Retrospective
- Wege erarbeiten, um Qualität und Effizienz nächstes Mal zu verbessern
- Fragen:
  - _Was lief gut?_
  - _Was kann verbessert werden?_
  - _Welche Maßnahmen können ergriffen werden?_

### Scrum Artefakte
- **Product Backlog**
  - Liste aller Anforderungen und Features
    - Priorisierung
    - Detaillierung
      - _nicht alle Items müssen gleich detailliert sein_
    - Aufwandsschätzung
    - Definition of Ready (DoR)
      - _Checkliste, ob ein Product Backlog Item abgearbeitet werden kann_
  - Wird vom Product Owner gepflegt und priorisiert
- **Sprint Backlog**
  - Liste der Aufgaben, die im aktuellen Sprint umgesetzt werden sollen
  - Wird vom Development Team erstellt
- **Increment**
  - Fertiges Produkt am Ende eines Sprints

## Agile: Extreme Programming (XP)
- Ziel: hohe Softwarequalität und hohe Lebensqualität für Entwickler
- Fokus auf technische Exzellenz und kontinuierliche Verbesserung

### Values
- Kommunikation
  - Jeder weiß, wer was macht
- Einfachheit
  - Einfache und direkte Lösungen
- Feedback
  - Regelmäßiges Feedback von Kunden und Teammitgliedern
- Mut
  - für die besten Entscheidungen
    - auch wenn sie zunächst unbequem sind
- Respekt
  - Respektvoller Umgang im Team
  - Wertschätzung der Arbeit aller Teammitglieder

### Prinzipien
- Humanität
  - Ausgleich zwischen Arbeit und Privatleben
- Economy
  - Fokus auf das Wesentliche
- Gemeinsamer Nutzen
  - Praktische Lösungen, die für alle funktionieren
- Selbstähnlichkeit
  - monatlicher Zyklus ist gleich wie wöchentlicher/täglicher
- Verbesserung
  - sich ständig verbessern
- Diversität
  - verschiedene Perspektiven und Ansätze einbeziehen
- Reflektion
  - regelmäßig über die eigene Arbeit nachdenken
- Flow
  - konstante und flüssige Arbeitsweise
- Möglichkeiten
  - Probleme sind eine Chance zum Lernen und Wachsen
- Redundanz
  - verhindert Fehler und verbessert die Qualität
- Failure
  - ist absolut okay
- Qualität
  - hat hohe Priorität
  - schlechte Qualität führt nicht zu schnellerer Lieferung
- Verantwortlichkeit
  - Teammitglieder sind für ihre Arbeit verantwortlich
- Baby-Steps
  - kleine Schritte, um schnell Feedback zu erhalten

### Practices
#### Primär
##### Programmieren
- **Pair Programming**
  - Zwei Entwickler arbeiten zusammen an einem Computer
  - Fördert Wissenstransfer und Codequalität
- **Test-Driven Development (TDD)**
  - Tests werden vor dem Code geschrieben
  - Sicherstellen, dass der Code die Anforderungen erfüllt

##### Integration
- **Ten-Minute Build**
  - Builden und Testen sollte nicht länger als 10 Minuten dauern
    - Wenns länger dauert, führt man es seltener aus
  - Fördert schnelle Feedback-Zyklen
- **Continuous Integration**
  - Direkt nach dem Commit wird der Code gebaut und getestet
  - Schnelles Feedback über den aktuellen Stand des Codes

##### Planning
- **Weekly Cycle**
  - Synonym zu Sprint
    - Montags wird geplant
    - Freitags wird geliefert
- **Quarterly Cycle**
  - Synonym zu Release
    - Kunde bekommt alle 3 Monate eine neue Version
    - Feedback / Wünsche werden in den nächsten Zyklus aufgenommen
- **User Stories**
  - Anforderungen werden in Form von User Stories formuliert
  - [OOAD User-Stories](RequirementsAnalysis.md#user-stories)
- **Slack**
  - ein paar niedrig priorisierte Aufgaben einplanen
    - um Puffer für Unvorhergesehenes zu haben

##### Team
- **Sit Together**
  - Teammitglieder sitzen zusammen
  - Fördert Kommunikation und Zusammenarbeit
- **Informative Workspace**
  - Kommunikation fördern
  - Privatsphäre respektieren
  - Wissen teilen
    - z.B. Whiteboards, Post-Its, etc.

##### Holistic
- **Incremental Design**
  - Design wird schrittweise verbessert
    - nicht alles auf einmal
- **Whole Team**
  - Cross-funktionales Team
- **Energized Work**
  - Höchste Effizienz, wenn jeder fokussiert ist und nicht abgelenkt wird
    - niemanden überarbeiten
    - Gesundheit und Wohlbefinden fördern

#### Corollary 
- Folgen aus primären Praktiken
- **Real Customer Involvement**
  - Kunden in die wöchentliche / vierteljährliche Planung einbeziehen
- **Incremental Deployment**
  - mehrere kleinere Releases statt eines großen
- **Team continuity**
  - Effektive Teams bleiben zusammen (auch in anderen Projekten)
- **Shrinking Teams**
  - Wenn ein Team effizienter arbeitet, kann es kleiner werden
  - nicht mehr Arbeit geben
    - "unnötiges" Mitglied kann in anderen Teams XP einführen
- **Root-cause analysis**
  - Wenn irgendwas schiefgeht, die Grund-Ursache finden und beheben
- **Shared code**
  - Jeder im Team kann auf den Code zugreifen und ihn ändern
  - jeder ist für die Qualität des Codes verantwortlich
- **Single codebase**
  - Es gibt nur einen Code, nicht mehrere Versionen gleichzeitig
- **Daily Deployment**
  - täglich eine neue Version ausliefern
- **Negotiated scope contract**
  - Kunden und Team einigen sich auf den Umfang der Arbeit
- **Pay-per-use**
  - Nicht für Arbeit bezahlen lassen
  - Kunde zahlt, wenn er das Produkt nutzt

## XP vs Scrum
- Scrum ist ein Framework, XP ist eine Sammlung von Praktiken
- ![image_910.png](image_910.png)

## Agile: DevOps
- [OOAD DevOps](SoftwareProcesses.md#devops)
- Kombination von Entwicklung (Dev) und Betrieb (Ops)
- Ziel: schnellere und zuverlässigere Software-Lieferung
- Fokus auf Automatisierung, Continuous Integration und Continuous Deployment (CI/CD)
![image_911.png](image_911.png)


## Agile Praktiken skalieren
### Scrum of Scrums
- ![image_912.png](image_912.png)
- Scrum-Team-Repräsentanten treffen sich regelmäßig
  - bilden neues Scrum-Team

### Release Train
- ![image_913.png](image_913.png)
- Zug-Metapher
  - Plan, für Features, wann sie die "Station" verlassen
  - Alle Teams wollen ihre Produkte noch auf den Zug bringen
  - Falls nicht, müssen sie auf den nächsten Zug warten

### Frameworks
- **LeSS (Large Scale Scrum)**
  - Skalierung von Scrum auf mehrere Teams
  - Fokus auf Einfachheit und Transparenz
- **Disciplined Agile Delivery (DAD)**
  - Agnostisches, hybrides Toolkit, das verschiedene agile Praktiken kombiniert
- **Nexus**
- **Scaled Agile Framework (SAFe)**
  - Skalierung von Scrum auf mehrere Teams und Programme
  - Fokus auf Planung, Koordination und Integration