Agile Softwareentwicklung für technische Teams
Agile Prinzipien mit professionellem Software Engineering verbinden
01 Intro
Agile Softwareentwicklung bedeutet mehr als Sprints, Boards und Meetings.
Kurze Entwicklungszyklen funktionieren nur dann dauerhaft, wenn Software
zuverlässig geändert, getestet, integriert und ausgeliefert werden kann.
Technische Praktiken sind deshalb keine Ergänzung zur Agilität, sondern
eine wesentliche Voraussetzung dafür.
Der Kurs richtet sich an technische Teams und verbindet agile Arbeitsweisen
mit konkreten Engineering-Praktiken. Im Mittelpunkt stehen kleine
Änderungen, schnelles Feedback, gemeinsame Verantwortung für Qualität und
die Fähigkeit, Software kontinuierlich weiterzuentwickeln.
Kurs-ID
SWE-011
Dauer
2 Tage
Format
Präsenz · Live Online · Inhouse
Vorkenntnisse
Praktische Erfahrung in Softwareentwicklung oder technischer Qualitätssicherung
02 Trainingsprogramm
Inhalte
Agilität aus technischer Perspektive
- Agiles Manifest
- Feedback
- kurze Zyklen
- Veränderbarkeit
- Unsicherheit
- technische Voraussetzungen
Von Anforderungen zu kleinen Änderungen
- User Stories
- fachliche Beispiele
- Akzeptanzkriterien
- Vertical Slicing
- kleine Increments
- Walking Skeleton
Definition of Done
- funktionierende Software
- Tests
- Code Review
- Integration
- Dokumentation
- echte Fertigstellung
Continuous Integration
- häufig integrieren
- kleine Commits
- Build
- automatisierte Tests
- Branching
- schnelles Feedback
Testautomatisierung
- Unit Tests
- Integration
- API
- Oberfläche
- Regression
- Verantwortung des Teams
Testgetriebene Entwicklung und Refactoring
- Red-Green-Refactor
- kontinuierliche Verbesserung
- Verhalten erhalten
- kleine Schritte
- Design Feedback
- pragmatischer Einsatz
Code Reviews und Zusammenarbeit
- Pull Requests
- Pair Programming
- gemeinsame Standards
- Wissenstransfer
- Collective Ownership
- Feedback
Technische Schulden im Sprint
- Schulden sichtbar machen
- Ursachen
- Auswirkungen
- Boy Scout Rule
- kontinuierlicher Abbau
- Product Backlog
Architektur in agilen Projekten
- ausreichende Architektur
- emergentes Design
- Architekturentscheidungen
- Architecture Decision Records
- Enabler
- evolutionäre Architektur
Fehler und Produktionsfeedback
- Defects
- Monitoring
- Logs
- Observability
- Incident Learning
- Feedback in die Entwicklung zurückführen
Technische Teamverantwortung
- Ownership
- Entwickler und Tester
- Silos
- Qualität
- Betrieb
- kontinuierliches Lernen
Team-Workshop
- bestehenden Ablauf analysieren
- Feedbackwege identifizieren
- technische Engpässe finden
- Verbesserungen auswählen
- konkrete Maßnahmen definieren
- nächste Iteration planen
03 Durchführung
Rahmen und Organisation
Dauer
2 Tage
Durchführung
Präsenz oder Live Online, vorzugsweise als Inhouse-Schulung
Schwerpunkt
Inhouse-Schulungen für Unternehmen und Teams
Sprache
Deutsch, englische Fachbegriffe und Dokumentation
Unterlagen
Kursunterlagen, Beispiele und Übungsaufgaben
Technik
Eigener Rechner für die praktischen Übungen
Inhouse-Schulungen
Der eigene Entwicklungsablauf kann als Grundlage für den Team-Workshop
dienen.
04 Zielgruppe
Für wen ist der Kurs gedacht?
Entwickler, Tester, Quality Engineers und technische Leads in agilen oder
auf agile Arbeitsweisen umstellenden Teams.
Voraussetzungen
Praktische Erfahrung in Softwareentwicklung oder technischer
Qualitätssicherung.
05 Lernziele
Was Sie nach dem Kurs können
Die Teilnehmer können agile Prinzipien mit technischen
Engineering-Praktiken verbinden, kurze Feedbackzyklen unterstützen und
technische Qualität als Bestandteil der täglichen Entwicklungsarbeit
organisieren.
06 FAQ
Häufige Fragen
Ist das eine Scrum-Schulung?
Nein. Scrum kann als organisatorischer Kontext vorkommen, der Kurs konzentriert sich aber auf die technische Seite agiler Softwareentwicklung.
Werden testgetriebene Entwicklung und Testautomatisierung vollständig vermittelt?
Nein. Sie werden als Bestandteile agiler Engineering-Praxis behandelt. Der Kurs zu Test-Driven Development und die Kurse zur Testautomatisierung vertiefen diese Themen.
Gehören technische Schulden in den Sprint?
Technische Schulden sind Teil der Produktrealität und sollten sichtbar und steuerbar sein. Wie sie behandelt werden, hängt von Risiko, Auswirkungen und Umfang ab. Der Kurs zu technischen Schulden vertieft dieses Thema.