Ordnung vor Funktionalität: Die Grundidee ist, dass es einfacher ist, Änderungen in sauberem Code vorzunehmen.Kontinuierliches Aufräumen: Code sollte regelmäßig aufgeräumt werden, um technische Schulden zu vermeiden.Empirisches Softwaredesign: Entscheidungen sollten auf Grundlage von Erfahrungen und Experimenten getroffen werden.
Definition: Software Engineering Body of Knowledge.Inhalt: Umfasst grundlegende Prinzipien, Praktiken und Techniken des Software Engineerings.
Vorteile: Vorhersagbarkeit, klare Struktur und Dokumentation, gut für große, komplexe Projekte.Nachteile: Weniger Flexibilität, schwierig bei sich ändernden Anforderungen.Einsatzgebiete: Große, stabile Projekte mit klaren Anforderungen (z.B. Regierungsprojekte).
Lehman's Laws: Software altert und muss kontinuierlich weiterentwickelt werden.
Conway’s Law: Systemdesign spiegelt die Kommunikationsstruktur der Organisation wider.Brooks’s Law: Hinzufügen von mehr Personal zu einem verspäteten Projekt verzögert es weiter.Parkinson’s Law: Arbeit dehnt sich aus, um die verfügbare Zeit zu füllen.Pareto’s Fallacy: 80% der Effekte kommen von 20% der Ursachen.Sturgeon’s Revelation: 90% von allem sind Schrott.The Iceberg Fallacy: Der größte Teil eines Problems ist unsichtbar.The Peter Principle: In einer Hierarchie steigt jeder bis zu seiner Inkompetenz auf.Eagleson’s Law: Jeder Programmierer verdoppelt den Speicherbedarf des Programms.Greenspun’s 10th Rule: Jede komplexe Software enthält ein schlechtes, in sich verborgenes Lisp.
Individuen und Interaktionen über Prozesse und Werkzeuge. Funktionierende Software über umfassende Dokumentation. Zusammenarbeit mit dem Kunden über Vertragsverhandlungen. Reagieren auf Veränderung über das Befolgen eines Plans.
Frühe und kontinuierliche Auslieferung wertvoller Software. Begrüßen von sich ändernden Anforderungen. Lieferung funktionierender Software häufig. Tägliche Zusammenarbeit zwischen Geschäftsleuten und Entwicklern. Projekte um motivierte Individuen herum aufgebaut. Effektive Kommunikation von Angesicht zu Angesicht. Funktionierende Software als wichtigstes Fortschrittsmaß. Nachhaltige Entwicklung. Technische Exzellenz und gutes Design fördern Agilität. Einfachheit. Selbstorganisierte Teams. Regelmäßige Reflexion und Anpassung.
Risk: Potenzielle Probleme, die den Projekterfolg beeinträchtigen könnten.Cost of Change: Der Aufwand, der nötig ist, um Änderungen am Projekt vorzunehmen.Iron Triangle: Die drei Variablen Scope, Time, und Cost beeinflussen sich gegenseitig.
Kommunikation, Einfachheit, Feedback, Mut, Respekt.
Menschliche Werte, Wirtschaftlichkeit, gegenseitiger Nutzen, Selbstähnlichkeit, kontinuierliche Verbesserung.
Planungsspiel, kleine Releases, Metapher, einfaches Design, Tests, Refactoring, Pair Programming, kollektive Code-Eigentümerschaft, kontinuierliche Integration, 40-Stunden-Woche, Vor-Ort-Kunde, Coding-Standards, TDD, Slack, Spike, inkrementelles Design, selbstorganisiertes Team.
Notwendigkeit: Reaktion auf mangelhafte Softwarequalität und -praktiken.Formate: Coding Dojo, Code Katas zur Übung und Verbesserung der Programmierfähigkeiten.Community-Prinzipien: Kontinuierliches Lernen und Teilen von Wissen.
Technische Praktiken: Grundlagen wie Testen und Refactoring.Team Praktiken: Zusammenarbeit und Kommunikation.Business Praktiken: Kundenorientierung und Wertschöpfung.
Ziele: Verständnis der Nutzerbedürfnisse.Anwendung: Agile Planung und Priorisierung.Format: "Als [Rolle] möchte ich [Funktion], um [Nutzen]."Zusammenhang: Epics (große Stories), Themes (thematische Gruppierung), Stories (kleinere, umsetzbare Einheiten).Merkmale: Unabhängig, verhandelbar, wertvoll, schätzbar, klein, testbar.
User Stories, User Roles, Epics, Themes, Story Points, Velocity, Planning Poker, Conditions of Satisfaction, Levels of Planning, Product Backlog, Priorisierung. Schätzungstechniken: Relativ, Planning Poker.Planung für Wert: Kosten, finanzieller Wert, Risiko, neues Wissen, Kano-Modell der Kundenzufriedenheit.
On-demand, scheduled, triggered.
Schritte von Code-Commit bis Deployment.
Scrum-Rollen: Scrum Master, Product Owner, Team.Scrum-Events: Sprint, Daily Scrum, Review, Retrospektive.Scrum-Artefakte: Product Backlog, Sprint Backlog, Increment.Scrum-Werte: Mut, Fokus, Offenheit, Respekt, Commitment.
Sprint, Sprintziel, Retrospektive, Task Board, Burndown Chart, Definition of Done, Definition of Ready, Daily Scrum, Increment.
CQRS: Trennung von Lese- und Schreiboperationen.Event Sourcing: Speicherung aller Zustandsänderungen als Ereignisse.Strangler Pattern: Schrittweise Ersetzung eines alten Systems durch ein neues.Online-Migration: Live-Migration von Daten.Circuit Breaker: Schutz vor Ausfällen durch Überlastung.Bulkhead: Isolation von Systemkomponenten.Retry: Wiederholungsmechanismen bei Fehlern.Serverless: Betrieb von Anwendungen ohne Verwaltung von Servern.Microservices: Modularisierung von Anwendungen in kleine, unabhängige Dienste.Self-contained Systems: Autonome Systeme mit eigener Datenhaltung.Monolith (Modulith): Großer, zusammenhängender Codeblock, der in Module aufgeteilt werden kann.
Software-Architektur: Struktur und Organisation eines Softwaresystems.Software-Architekt: Verantwortlich für das Design und die Integrität der Architektur.Enterprise Architecture vs. Application Architecture: Unternehmensweite vs. anwendungsspezifische Architektur.Schwierigkeiten: Komplexität, Konformität, Änderbarkeit, Unsichtbarkeit.
Faktoren, die die Architektur beeinflussen (Geschäftsanforderungen, technische Anforderungen).
Standardisierte Lösungen für wiederkehrende Probleme.
Unterschiede zwischen Layer und Tier.
Vor- und Nachteile von Stilen wie Monolith, Microservices.
Transaction Script: Verarbeiten von Transaktionen durch einfache Skripte.Domain Model: Modellierung der Geschäftslogik.Table Module: Datenbanktabellen als zentrale Logikstrukturen.
Kontextsensitive Architekturmodellierung.
Werkzeug zur Visualisierung und Planung von Architekturen.
Cynefin (Komplexitätsframework), Exaptation (Nutzung bestehender Strukturen für neue Zwecke), 4 + 1 Domains (Einfach, Kompliziert, Komplex, Chaotisch, Unordnung), Causality, Correlation, Constraint.
Nutzung des Cynefin-Frameworks zur Entscheidungsfindung und Problemlösung in der Softwareentwicklung.
Agile, Lean, Scrum, XP und Kanban stammen aus der Lean-Philosophie.
Visualisieren des Workflows, Limitierung von WIP (Work in Progress), Management des Flusses.
Werkzeug zur Visualisierung des Workflows.
Darstellung des Arbeitsflusses zur Identifikation von Engpässen.