Home

Defintion of Done

Language

• Quelltext (z.B. Methoden oder Variablennamen) und Kommentare sind auf Englisch geschrieben.
• DoD ist auf Deutsch geschrieben.
• Issues sind in Englisch geschrieben.
• Reviews können auf Deutsch oder Englisch durchgeführt werden.

Meetings

• Regelmäßige obligatorische Treffen finden jeden Samstag um 12:00 Uhr UTC+2 statt.
• Weitere Treffen finden je nach Bedarf statt und werden auf dem Discord Server angekündigt.

Commit-Messages

• Die Commit-Messages ensprechen der Gitmoji-Spezifikation
• Commit-Titel sind auf Englisch verfasst.
• Aus dem Commit-Titel kann der Inhalt des Commits geschlossen werden.
• Branch Name ist auf Englisch verfasst.

Coding-Guidelines

• Alle Typescript Funktionen sind entsprechend jsDoc Guidelines kommentiert.
• EsLint wirft keine Fehler.
• Html und Typescript sind entsprechend der Guidelines von Prettier formatiert.
• Prettier wird keine Fehler.

QA (Reviews)

• Die Akzeptanzkriterien der User Story sind erfüllt.
• Es wurde ein Code Review durchgeführt oder der Code wurde im Pair Programming erarbeitet.
• Es wurde ein funktionaler Test (Chrome browser) auf einem mobilen Endgerät durchgeführt.
• Nachdem ein Issue nachgebessert wurde, führt die gleiche Person QA wie beim ersten Durchlauf der QA-Schleife.
• Falls Assisstenz benötigt wird beim Bearbeiten eines Issues, so soll auch dies als "Ready for Review" markiert werden.

Branches & Merge request

• Die main-Branch bleibt stabil.
• Für jedes Issue muss ein extra Branch erstellt werden.
  • Branchname: $ISSUE_NUM-$TITEL
• Der Merge Request wurde angenommen (siehe QA) und der Code in die main-Branch überführt.
• Die Commit-Nachricht des Merge Request muss mit der Ticketnummer beginnen.
• Der Titel des Merge Request muss in englischer Sprache verfasst werden und es muss hervorgehen, was bearbeitet worden ist. (Diese Nachricht erscheint später als Commit im Main-Branch).
• Beispiel: $ISSUE_NUM-$TITEL => #0 - Add new template page

Workflow

• Wird ein Issue bearbeitet, wird ihm das Label "Under Construction" zugewiesen. Wer das macht, "assigned" sich selbst. Wird in Pair-Programming gearbeitet, wird das durch einen Kommentar verdeutlicht.
• Wird die Arbeit an einem Ticket begonnen,
  1. Wird ein Merge-Request erstellt
  2. Die dabei automatisch erstellte Branch lokal geklont und zur Bearbeitung verwendet
  3. Wird das Issue im Merge-Request verlinkt
• Ist ein Merge-Request erfolgreich gereviewt und entspricht der DoD, wird dem Issue das Label "Done" zugewiesen.

Issue

• Als User Stories formuliert und sind als die zu implementierende Funktion/Feature zu verstehen.
• Eine gute Userstory ist
  • Gut formuliert
    • Als vollständiger Satz formuliert
    • Als {Rolle} möchte ich {Was?} sodass {Warum?}
  • Notwendig klein
    • Sie beschreibt genau eine Anforderung für genau eine Funktion und ist klein genug, dass Sie in einem kurzen Entwicklungszyklus realisierbar ist.
  • Eindeutig
    • Formulierungen lassen keinen Interpretationsspielraum zu.
  • Konfliktfrei
    • Beschreibt nicht das Gegenteil oder ist widersprüchlich zu Anforderungen einer anderen Story
  • Schätzbar
    • Enthält nur eindeutige Anforderungen, die kalkulierbar und planbar sind.
  • Abgeschlossen
    • Steht für sich selbst und hat kein in ihr enthaltende Abhängigkeiten zu anderen Stories.
  • Vollständig
    • Alle Akzeptanzkriterien sind vollständig, es gibt keine logischen Lücken und die Story ist nachvollziehbar.
    • ggf. Textbausteine sind kopierfertig enthalten (in benötigten Sprachen)
  • Erreichbar
    • Ist in einem System (GitLab) als Issue abgelegt

Technisch

• Auswirkungen auf alle relevanten Systeme beschrieben
• Abhängigkeiten zu anderen Systemen sind bekannt
• Datenhaltung und Datenbezug geklärt
• Non-funktionale Anforderungen wurden bedacht (Performance, Sicherheit, ...)

Beispiel

• Titel:
  • Login-Funktion
• User-Story:
  • Als Akteur möchte ich mich anmelden können sodass nur ich auf meinen Account zugreifen kann.
• Beschreibung:
  • Man hat 3 Login Versuche bevor man für 10 Minuten gesperrt wird.

Fortschritts-Updates

An jedem Tag an dem gearbeitet wird, machen die Teammitglieder ihren Fortschritt im GitLab sichtbar (entweder per gepushtem Commit, oder Kommentar im Ticket). Sollte Code bearbeitet werden, muss ein Push in die entsprechende Branch erfolgen.