Begriffe, Konzepte und Techniken
Hier werden einige Begriffe, Konzepte und Techniken kurz erläutert.
Architecture Decision Record
Ein Architecture Decision Record (ADR) ist ein kurzer, dauerhafter Eintrag, der eine wesentliche Entscheidung im Projekt nachvollziehbar festhält:
- Was war der Kontext (Ziele, Randbedingungen, Zwänge)?
- Welche Optionen standen zur Wahl?
- Wofür haben wir uns entschieden – und warum (Abwägungen, Trade-offs)?
- Welche Folgen und To-dos ergeben sich daraus?
ADRs sind bewusst leichtgewichtig (typisch eine Seite) und funktionieren wie ein Entscheidungslogbuch: Sie helfen neuen Teammitgliedern beim Onboarding, reduzieren wiederkehrende Grundsatzdiskussionen, machen Prüfungen/Reviews effizienter und sichern, dass wir Entscheidungen später reproduzieren können (z.B. bei Fehleranalysen oder Weiterentwicklungen). Wir verfassen ADRs immer dann, wenn eine Wahl Auswirkung auf Architektur, Sicherheit, Daten, Performance oder Team-Workflow hat – nicht für jede Kleinigkeit, aber für alles, was in sechs Monaten noch jemand verstehen können muss.
Hier ein paar Beispiele aus dem Master Beiboot Projekt:
mehr zu Architecture Decision Record
Schulterblick
Ein Schulterblick ist ein kurzes, fokussiertes Review im Projektalltag (ca. 10–20 Minuten). Ziel ist es, früh und häufig Feedback zu bekommen: Wir zeigen einen aktuellen Stand (Skizze, Prototyp, Testaufbau), benennen die konkrete Frage („Worauf sollen wir schauen?“) und sammeln punktgenaues Feedback:
- Was funktioniert?
- Was irritiert?
- Was fehlt für den nächsten Schritt?
Der Schulterblick ist bewusst niedrigschwellig (kleiner Kreis, kurze Demo, klare Timebox) und ergänzt formale Meilenstein-Reviews: Er reduziert Risiko, beschleunigt Lernen und stärkt gemeinsame Verantwortung für Qualität. Wichtig sind psychologische Sicherheit (offenes, sachliches Feedback), eine einfache Struktur (Ziel → Demo → Feedback → Nächste Schritte) und das kurze Protokoll, damit Erkenntnisse nicht verloren gehen.
User Stories
User Stories sind kurze, einfache Beschreibungen einer Funktion oder eines Features aus der Perspektive des Endbenutzers. Sie werden in agilen Projekten verwendet, um die Anforderungen eines Systems zu definieren. Eine User Story ist in der Regel in einer bestimmten Struktur formuliert:
Als [Nutzerrolle] möchte ich [Ziel], um [Nutzen] zu erreichen.
User Stories sind hilfreich, um die Bedürfnisse der Benutzer zu verstehen und den Fokus auf die Wertschöpfung zu legen. Sie sind oft bewusst kurz gehalten, um Raum für Diskussionen und Details während der Entwicklung zu lassen.
Beispiel:
Als Benutzer möchte ich mich mit meinem Google-Account anmelden, um schnell auf mein Konto zugreifen zu können.
Typische Elemente einer User Story:
- Nutzerrolle (Wer nutzt die Funktion?)
- Ziel (Was soll erreicht werden?)
- Nutzen (Warum ist das wichtig?)
Ein Template für User Stories finden Sie hier: User Story Template
Das Template hilft, strukturierte und zielgerichtete User Stories zu erstellen.
Projektplan
Der Projektplan dient dazu, die wichtigsten Phasen, Aufgaben und Meilensteine des Projekts zu definieren und zu koordinieren. Der Plan umfasst in der Regel:
- Ziele: Klare Definition dessen, was das Projekt erreichen soll.
- Meilensteine: Wichtige Etappenziele, die während des Projekts erreicht werden müssen.
- Zeitplan: Eine zeitliche Übersicht, wann welche Aufgaben erledigt werden sollen.
- Ressourcen: Verteilung von Personal, technischen Mitteln oder anderen notwendigen Ressourcen.
- Rollen und Verantwortlichkeiten: Wer ist für welche Aufgaben verantwortlich?
- Risikomanagement: Mögliche Projektrisiken und Strategien, um diese zu minimieren.
Der Projektplan in GitHub kann durch verschiedene Tools und Funktionen unterstützt und abgebildet werden, wie:
- Issues: Dienen zur Erfassung einzelner Aufgaben oder User Stories. Diese können priorisiert und mit Fristen versehen werden.
- Milestones: Mit GitHub-Milestones können große, zentrale Projektetappen abgebildet werden. Sie geben einen Überblick darüber, welche Issues erledigt werden müssen, um einen bestimmten Meilenstein zu erreichen.
- Project Boards: GitHub bietet Kanban-Boards, die es ermöglichen, den Projektverlauf visuell darzustellen. Hier können Aufgaben in verschiedene Phasen unterteilt werden (z.B. „To Do“, „In Progress“, „Done“).
- Pull Requests: Diese helfen, den Fortschritt einzelner Aufgaben in Bezug auf den Code zu verfolgen und sicherzustellen, dass die Implementierung den Projektanforderungen entspricht.
Durch die Abbildung des Projektplans in GitHub wird der Fortschritt für alle Teammitglieder transparent. Es erleichtert die Zusammenarbeit, das Tracking des Projektfortschritts und die Anpassung von Prioritäten bei Bedarf.
Sprintplanung
Sprintplanung ist ein zentrales Meeting im agilen Projektmanagement, das zu Beginn eines jeden Sprints (kurzer, zeitlich begrenzter Entwicklungszyklus) stattfindet. Ziel der Sprintplanung ist es, festzulegen, welche Aufgaben und User Stories im kommenden Sprint umgesetzt werden sollen. Das Team bewertet die Komplexität und den Arbeitsaufwand der Aufgaben und entscheidet gemeinsam, was realistisch in der festgelegten Sprintdauer (oft 1-4 Wochen) abgeschlossen werden kann.
Wichtige Schritte der Sprintplanung:
- Ziele des Sprints festlegen: Welche funktionalen Ziele sollen erreicht werden?
- Auswahl von Aufgaben/User Stories: Der Product Owner priorisiert Aufgaben aus dem Backlog, das Team wählt Aufgaben basierend auf der eigenen Kapazität.
- Schätzung des Arbeitsaufwands: Aufgaben werden in ihrer Komplexität geschätzt (z.B. durch Story Points oder Schätzung in Stunden).
- Verteilung der Aufgaben: Teammitglieder übernehmen konkrete Aufgaben zur Umsetzung.
Die Sprintplanung sorgt dafür, dass das Team fokussiert und effizient an den wichtigsten Features arbeitet.
Dieser Guide bietet praktische Anleitungen zur effektiven Durchführung der Sprintplanung: Atlassian Sprint Planning Guide
Backlog
Ein Backlog ist eine priorisierte Liste von Aufgaben, Anforderungen oder Features, die in einem Projekt erledigt werden müssen. In agilen Projekten dient das Backlog als zentrale Sammelstelle für alle gewünschten Änderungen und neuen Funktionen. Es gibt zwei Hauptarten von Backlogs:
- Product Backlog: Enthält alle User Stories, Features und Anforderungen für das gesamte Produkt.
- Sprint Backlog: Umfasst die spezifischen Aufgaben und User Stories, die in einem bestimmten Sprint (Zeitfenster für die Entwicklung) bearbeitet werden.
Das Backlog wird kontinuierlich gepflegt und priorisiert, um sicherzustellen, dass das Team an den wichtigsten und wertvollsten Aufgaben arbeitet. Es wird in der Regel vom Product Owner verwaltet und dient als Leitfaden für die Entwicklungsarbeit.
Ein Infovideo zum Erstellen von einem Backlog finden Sie hier: Building your backlog with Projects