2Cycles Model

Pair Programming

Zwei Personen arbeiten gemeinsam an einem Computer; eine schreibt Code, die andere reviewt und unterstützt. Wann: Bei der Entwicklung von Software, insbesondere in Teams, die Wert auf hohe Codequalität und Wissensaustausch legen. Warum: Es ermöglicht kontinuierliches Feedback, erhöht die Codequalität und fördert das Lernen zwischen Entwicklern. Voraussetzungen - Kompatible Teammitglieder: Die Entwickler sollten offen für Zusammenarbeit sein und gut miteinander kommunizieren können. - Klare Ziele: Es sollte klar sein, was erreicht werden soll (z. B. Implementierung eines Features oder Behebung eines Bugs). - Räumliche oder virtuelle Nähe: Pair Programming funktioniert am besten, wenn die Entwickler leicht miteinander interagieren können, sei es vor Ort oder über Tools. Wie erkennt man, dass es nicht passt? - Mangelnde Bereitschaft zur Zusammenarbeit: Wenn ein Entwickler die Arbeit lieber allein erledigen möchte, kann das die Effizienz mindern. - Unklare Aufgabenstellung: Ohne klar definiertes Ziel kann Pair Programming ineffizient werden. - Ungleiche Fähigkeiten: Wenn ein Entwickler deutlich weniger erfahren ist, kann es zu Frustration oder einem Ungleichgewicht in der Zusammenarbeit kommen.

Test-Driven Development (TDD)

Erst Tests schreiben, dann minimalen Code, bis der Test besteht, und anschließend refaktorisieren. Wann: Bei der Softwareentwicklung, um Qualität zu sichern und Fehler frühzeitig zu vermeiden. Warum: TDD fördert robuste und wartbare Software, da die Anforderungen in Form von Tests formuliert werden, bevor der eigentliche Code geschrieben wird. Voraussetzungen - Verständnis der Methode: Entwickler müssen mit der TDD-Methode vertraut sein und sie konsequent anwenden. - Automatisierte Testumgebung: Eine funktionierende Infrastruktur für automatisierte Tests ist erforderlich. - Klare Anforderungen: Die zu testenden Funktionen müssen ausreichend spezifiziert sein, um sinnvolle Tests zu erstellen. Wie erkennt man, dass es nicht passt? - Zeitdruck: Wenn der Fokus stark auf schneller Lieferung liegt, wird TDD oft als zu zeitaufwendig wahrgenommen. - Unklare Anforderungen: Ohne genaue Anforderungen entstehen Tests, die nicht den gewünschten Nutzen bringen. - Widerstand im Team: Wenn Entwickler TDD nicht akzeptieren oder anwenden möchten, wird es ineffektiv.

Refactoring

Kontinuierliche Verbesserung des Codes, um die Wartbarkeit und Lesbarkeit zu erhöhen, ohne das Verhalten zu ändern. Wann: Während oder nach der Entwicklung von Software, um den Code zu verbessern, ohne dessen Verhalten zu ändern. Warum: Refactoring erhöht die Wartbarkeit, Lesbarkeit und langfristige Qualität des Codes. Voraussetzungen - Bestehende Tests: Automatisierte Tests sollten vorhanden sein, um sicherzustellen, dass das Verhalten des Codes nach dem Refactoring unverändert bleibt. - Klare Ziele: Es muss definiert sein, welche Verbesserungen (z. B. Lesbarkeit, Reduktion von Redundanz) erreicht werden sollen. - Zeit für Qualitätsarbeit: Das Team sollte Zeit für Refactoring einplanen und es nicht als nachrangige Aufgabe behandeln. Wie erkennt man, dass es nicht passt? - Fehlende Tests: Ohne Tests besteht das Risiko, bestehende Funktionen unbeabsichtigt zu verändern. - Zeitdruck: Wenn der Fokus ausschließlich auf neuen Features liegt, wird Refactoring oft vernachlässigt. - Unstrukturiertes Vorgehen: Wenn Refactoring ohne klaren Plan erfolgt, können neue Probleme entstehen oder der Code unübersichtlicher werden.

Continuous Integration (CI)

Häufiges Zusammenführen (Merge) von Code in ein Haupt-Repository, um rasch Fehler zu entdecken. Wann: Durchgängig während der Entwicklungsarbeit, insbesondere in Teams, die regelmäßig Code entwickeln und integrieren. Warum: CI stellt sicher, dass Code-Änderungen kontinuierlich integriert, getestet und überprüft werden, wodurch Probleme frühzeitig erkannt und behoben werden können. Voraussetzungen - Automatisierte Tests: Ein solides Set an automatisierten Tests ist notwendig, um jede Integration zu überprüfen. - Versionskontrolle: Der gesamte Code muss in einem zentralen Repository (z. B. Git) versioniert sein. - Build- und Test-Pipelines: Eine automatisierte Pipeline, die den Code nach jeder Änderung baut und testet, ist essenziell.

Wie erkennt man, dass es nicht passt? - Fehlende Automatisierung: Wenn Tests oder Builds manuell ausgeführt werden, wird CI ineffizient. - Langsame Prozesse: Wenn die Build- und Testzyklen zu lange dauern, behindert das die Produktivität und den Fluss der Integration. - Schlechte Testabdeckung: Wenn wichtige Bereiche des Codes nicht durch Tests abgedeckt sind, können schwerwiegende Fehler unbemerkt bleiben.

Continuous Delivery (CD)

Häufiges Ausliefern (Delivery) vom Inkrement, um rasch Wert zu liefern. Wann: In Teams, die regelmäßig und zuverlässig neue Versionen eines Produkts oder Services bereitstellen möchten. Warum: CD sorgt dafür, dass Software jederzeit in einem auslieferungsfähigen Zustand ist, wodurch schnelle, automatisierte Releases möglich werden. Voraussetzungen - Continuous Integration: CI muss implementiert und stabil sein, da CD darauf aufbaut. - Automatisierte Deployment-Pipelines: Alle Schritte vom Build über Tests bis zur Auslieferung müssen automatisiert sein. - Versionskontrolle: Der gesamte Code und die Deployment-Skripte müssen versioniert sein. Wie erkennt man, dass es nicht passt? - Manuelle Schritte: Wenn wichtige Schritte im Auslieferungsprozess manuell durchgeführt werden, ist CD ineffizient oder fehleranfällig. - Fehlende Stabilität: Wenn Builds oder Tests häufig fehlschlagen, ist der Prozess nicht reif genug für CD. - Kein Bedarf für schnelle Releases: In Umgebungen mit seltenen oder geplanten Releases könnte der Aufwand für CD unverhältnismäßig hoch sein.

Collective Code Ownership

Jeder im Team darf den Code ändern; Verantwortung für Codequalität liegt beim gesamten Team. Wann: In agilen Teams, die eng zusammenarbeiten und Code kontinuierlich refaktorieren. Warum: Um die Verantwortung für den gesamten Code auf das gesamte Team zu verteilen, Wissenssilos abzubauen und die Codequalität zu erhöhen. Voraussetzungen - Klare Coding Standards: Einheitliche Regeln, damit Änderungen konsistent bleiben. - Automatisierte Tests: Damit Änderungen keine unerwarteten Fehler verursachen. - Teamkultur: Vertrauen und Respekt innerhalb des Teams, um konstruktiv mit Änderungen umzugehen. Wie erkennt man, dass es nicht passt? - Verantwortungslosigkeit: Wenn niemand sich zuständig fühlt, sinkt die Codequalität. - Mangelnde Abstimmung: Wenn Änderungen unkoordiniert erfolgen und Konflikte verursachen. - Fehlende Standards: Ohne klare Coding-Regeln führt Collective Code Ownership zu Chaos.

Coding Standards

Gemeinsame Vereinbarungen zu Stil, Namenskonventionen und strukturgebenden Richtlinien im Code. Wann: Von Beginn an in der Entwicklung, um Konsistenz und Lesbarkeit des Codes sicherzustellen. Warum: Gemeinsame Regeln erleichtern die Zusammenarbeit, verbessern die Wartbarkeit und verringern Missverständnisse. Voraussetzungen - Teamabstimmung: Die Standards müssen gemeinsam erarbeitet und akzeptiert sein. - Werkzeuge: Tools wie Linter und Code-Formatierer (z. B. Prettier) helfen bei der Durchsetzung. - Regelmäßige Überprüfung: Standards sollten bei Bedarf angepasst werden. Wie erkennt man, dass es nicht passt? - Inkonsequente Anwendung: Wenn Standards nicht eingehalten werden, leidet die Lesbarkeit. - Überkomplexität: Zu viele oder zu strikte Regeln können die Produktivität hemmen. - Fehlende Akzeptanz: Wenn das Team die Standards nicht mitträgt, sinkt die Compliance.

Sustainable Pace

Arbeit in einem Tempo, das langfristig durchhaltbar ist (Vermeidung von „Burnout-Sprints“). Wann: Immer, wenn das Team langfristig leistungsfähig bleiben soll. Warum: Übermäßiger Stress und Überstunden führen zu Burnout, schlechter Qualität und Demotivation. Voraussetzungen - Realistische Planung: Der Umfang der Arbeit muss an die Kapazität des Teams angepasst sein. - Transparenz: Teammitglieder sollten ihre Belastung offen kommunizieren können. - Management-Support: Führungskräfte müssen den Wert eines nachhaltigen Arbeitstempos anerkennen. Wie erkennt man, dass es nicht passt? - Burnout-Anzeichen: Wenn Teammitglieder regelmäßig Überstunden machen oder sich überfordert fühlen. - Abnehmende Qualität: Fehler häufen sich, weil das Team überlastet ist. - Kurzfristiger Fokus: Wenn kurzfristige Erfolge Priorität vor langfristiger Stabilität haben.

Simple Design

Möglichst einfache technische Lösungen finden, die gerade die aktuellen Anforderungen erfüllen. Wann: Kontinuierlich, um die Komplexität des Codes gering zu halten. Warum: Einfache Lösungen sind leichter verständlich, wartbarer und anpassbarer. Voraussetzungen - Reflexion: Regelmäßige Überprüfung, ob bestehende Designs überarbeitet werden können. - Automatisierte Tests: Um sicherzustellen, dass Änderungen keine Probleme verursachen. - Disziplin: Das Team muss bereit sein, unnötige Komplexität zu vermeiden. Wie erkennt man, dass es nicht passt? - Overengineering: Wenn unnötige Features oder Strukturen eingebaut werden. - Unklare Anforderungen: Ohne klare Anforderungen kann keine einfache Lösung gefunden werden. - Ignoranz: Wenn das Team Einfachheit nicht priorisiert, steigt die technische Schuld.

System Metaphor

Ein gemeinsames, eingängiges Bild oder eine Metapher, die das System beschreiben soll und dem Team zur Ausrichtung hilft („Unser System ist wie…“). Wann: Zu Beginn eines Projekts, um eine gemeinsame Vision und ein besseres Verständnis für das System zu schaffen. Warum: Eine gute Metapher erleichtert die Kommunikation und hilft dem Team, sich auf eine gemeinsame Vorstellung zu einigen. Voraussetzungen - Kreativität: Das Team muss in der Lage sein, eine passende Metapher zu entwickeln. - Einfachheit: Die Metapher sollte klar und leicht verständlich sein. - Teamverständnis: Alle Teammitglieder sollten die Metapher verinnerlichen. Wie erkennt man, dass es nicht passt? - Unklare Metapher: Wenn die Metapher nicht greifbar ist, führt sie zu mehr Verwirrung. - Vergessene Nutzung: Wenn die Metapher im Alltag nicht genutzt wird, verliert sie an Wert. - Ungeeignetheit: Wenn die Metapher nicht die Komplexität oder Natur des Systems widerspiegelt.

Planning Game

Kurze, wiederkehrende Planungszyklen, in denen das Team und der Kunde gemeinsam klären, was kurzfristig umgesetzt wird und was warten muss. Wann: Regelmäßig, um kurzfristige und langfristige Planung iterativ zu gestalten. Warum: Es ermöglicht enge Zusammenarbeit zwischen Team und Kunden, um Prioritäten klar zu definieren. Voraussetzungen - Klarheit über Ziele: Das Team und der Kunde müssen wissen, was sie erreichen wollen. - Transparenz: Alle Informationen über Anforderungen und Kapazitäten müssen verfügbar sein. - Flexibilität: Der Plan muss an neue Erkenntnisse anpassbar sein. Wie erkennt man, dass es nicht passt? - Unklare Prioritäten: Wenn Kunden und Team sich nicht einig sind, was wichtig ist. - Überplanung: Wenn zu viele Details geplant werden, geht die Agilität verloren. - Fehlende Beteiligung: Wenn nur eine Partei dominiert, bleibt der Nutzen begrenzt.

Specification by Example / Behaviour-Driven Development (BDD)

Eine praxisnahe Art, Anforderungen und Tests zu formulieren, indem man konkrete Beispiele für das gewünschte Verhalten nutzt. Wann: Beim Formulieren von Anforderungen und Tests, insbesondere in agilen Projekten. Warum: Es sorgt dafür, dass Anforderungen präzise und verständlich sind, und fördert die Zusammenarbeit zwischen Entwicklern, Testern und Fachexperten. Voraussetzungen - Kollaboration: Entwickler, Tester und Fachleute müssen gemeinsam an den Beispielen arbeiten. - Werkzeuge: Frameworks wie Cucumber oder SpecFlow können den Prozess unterstützen. - Klare Anforderungen: Die Beispiele müssen reale Szenarien abbilden. Wie erkennt man, dass es nicht passt? - Unklare Beispiele: Wenn Beispiele nicht verständlich oder relevant sind, leidet die Qualität der Tests. - Fehlende Akzeptanz: Wenn das Team den Ansatz nicht unterstützt, bleibt der Nutzen gering. - Überkomplexe Szenarien: Zu viele Details führen zu Verwirrung.

Three Amigos

Kollaboratives Treffen zwischen Fachexperte (Product Owner / BA), Entwickler und Tester, um Anforderungen und Akzeptanzkriterien vor dem Start zu klären.
Wann: Vor der Umsetzung von Anforderungen, um sicherzustellen, dass alle Beteiligten die Anforderungen verstehen. Warum: Es minimiert Missverständnisse und stellt sicher, dass alle Perspektiven berücksichtigt werden. Voraussetzungen - Klare Agenda: Das Ziel des Treffens muss klar sein. - Teilnehmer: Product Owner (oder BA), Entwickler und Tester müssen beteiligt sein. - Vorbereitung: Anforderungen und erste Ideen sollten vorbereitet werden. Wie erkennt man, dass es nicht passt? - Fehlende Vorbereitung: Wenn die Teilnehmer nicht vorbereitet sind, wird das Treffen ineffektiv. - Unvollständige Teilnehmer: Wenn eine Perspektive fehlt, bleiben wichtige Aspekte unberücksichtigt. - Dominanz einzelner Personen: Wenn eine Rolle zu stark dominiert, wird die Zusammenarbeit eingeschränkt.