396 lines
13 KiB
Markdown
396 lines
13 KiB
Markdown
# 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
|
|
|
|
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
|
|
|
|
|
|
- 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
|
|
|
|
- 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
|
|
|
|
- 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
|
|
|
|
#### 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
|
|
- 
|
|
- **1-Part Sprint Planning**
|
|
- Team eruiert Kapazität
|
|
- Sprint-Ziel ggf. anpassen
|
|
- Team wählt Items aus dem Product Backlog aus
|
|
- 
|
|
|
|
#### 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
|
|
- 
|
|
- Sprint Burndown Chart
|
|
- Grafik, die zu erledigende Arbeit vs verbleibende Zeit zeigt
|
|
- 
|
|
|
|
#### 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
|
|
- 
|
|
|
|
## 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)
|
|
|
|
|
|
|
|
## Agile Praktiken skalieren
|
|
### Scrum of Scrums
|
|
- 
|
|
- Scrum-Team-Repräsentanten treffen sich regelmäßig
|
|
- bilden neues Scrum-Team
|
|
|
|
### Release Train
|
|
- 
|
|
- 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 |