This commit is contained in:
David Schirrmeister 2025-06-15 13:42:36 +02:00
parent 8fc91f469f
commit 17f3491f05
15 changed files with 397 additions and 0 deletions

Binary file not shown.

After

Width:  |  Height:  |  Size: 682 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 304 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 505 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 243 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 269 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 125 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 118 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 54 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 79 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 334 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 30 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 92 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 595 KiB

View File

@ -126,6 +126,7 @@
<toc-element topic="02_TestingForContinuousQuality.md"/> <toc-element topic="02_TestingForContinuousQuality.md"/>
<toc-element topic="03_ContinousDevelopment.md"/> <toc-element topic="03_ContinousDevelopment.md"/>
<toc-element topic="04_Operations.md"/> <toc-element topic="04_Operations.md"/>
<toc-element topic="05_DevelopmentMethodologies.md"/>
</toc-element> </toc-element>
<toc-element toc-title="Theoretische Informatik"> <toc-element toc-title="Theoretische Informatik">

View File

@ -0,0 +1,396 @@
# 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