Quality Gates # Quality Gates ## QG 0: SW Design vorab - [ ] Es existiert ein PAP, der die Highlevel-Struktur aufzeigt - [ ] Aus dem PAP lassen sich Methoden generieren - [ ] Alle Teammitglieder sind in der Lage, über eine IDE mit VCS (z.B. Git) Code zu erzeugen und zu pushen / commiten - [ ] Alle Teamitglieder haben Zugang zum gemeinsamen Ticket-Board - [ ] Es gibt ein Java-Grundgerüst, indem die Haupt-Datenstruktur vorhanden ist und eine Main-Methode ## QG 1: Product-Backlog - [ ] Die User-Stories finden sich im Produkt-Backlog wieder - [ ] Alle User-Stories haben eine vom Team geschätzte Priorität und geschätzte Dauer in Stunden ## QG 2: Erstes Sprint-Planning: Sprint-Backlog - [ ] Für den ersten Sprint werden aus den Product-Backlog die ersten Karten erstellt und verfeinert - [ ] Die Karten haben einen definierten Verantwortlichen und einen Tester, der die Umsetzung überprüfen wird. Die Überprüfung erfolgt im Code Review zu zweit. - [ ] Jede Karte hat eine DoD (Definition of Done) - [ ] Der Scrum-Master (Anleiter des Meetings) wird definiert. (Für diese Runde) - [ ] Der Scrum-Master startet das Standup-Meeting ## QG 3: Erstes Reviev/Retrospektive (ende des ersten Sprints) - [ ] Fortschritt wird vom Team festgestellt. Die Planung des nächsten Sprints wird angepasst. - [ ] Feedbackrunde: Warme Dusche, kalte Dusche zum vergangenen Sprint von jedem - [ ] nächster Sprint! ## QG 4: Funktionsabnahme - [ ] Das Team demonstriert die Funktionsweise der Software, indem alle MUSS-Anforderungen aus dem Anforderungskatalog demonstriert werden. - [ ] Die User-Stories sind dabei größtenteils abgearbeitet ## GQ 5: Teamwissen prüfen - [ ] Jedes Teammitglied ist in der Lage, Teile des Gesamtssystem zu modifizieren. - [ ] Jedes Teammitglied kann Detailfragen zu allen Systemteilen beantworten - [ ] Jedes Teammitglied kann auf Anforderungsniveau 2 zu allen teilen des Systems antworten. - [ ] Einzelne Teammitglieder könntn auf Anforderungsniveau 3 zu bestimmten Systemteilen antworten.