Die Abgabe (Beschreibung von Abgaben) bezeichnet (außer beim Review/M2) alle zu einem speziellen Commit im git-repository des GitLab-Projekts eines Entwickler-Teams gehörenden Dateien (Dokumente/Quellcode). Je nach Meilenstein werden bestimmte Dateien bewertet.
- Abrenzung: Kann auf GitLab-Issues (User Stories) verweisen. Diese gehören dann auch zur Abgabe.
- Bezeichnung: Identifiziert durch einen git-tag im Format v0.<MeilensteinNummer> (Beispiel: v0.3 oder v0.5)
Ein Feature, welches für die sinnvolle Verwendung/Einsatzfähigkeit der Software wünschenswert ist.
- Abgrenzung: Critical Feature
Beschreibung der Software-Architektur einer Software. Enthält Komponentendiagramme die innere und externe Komponenten und die Schnittstellen zwischen den Komponenten, welche so die Struktur und den Aufbau der Software beschreiben. Weiterhin enthält die Architektur kurze Beschreibungen für Komponenten und die an Schnitstellen aus/-eingehenden Daten.
- Querverweise: Entwurf
Das Budgetmodell legt Rahmenbedingungen für die Bewertung der Abgaben der Entwickler-Teams durch die Investoren fest. Hierfür wird auf Spielgeld in der Währung Euro (€) zurückgegriffen.
Ein Feature, welches für die sinnvolle Verwendung/Einsatzfähigkeit der Software unerlässlich ist.
- Abgrenzung: Additional Feature
Die Definition of Done enthält alle Bedingungen, die erfüllt sein müssen, damit eine User Story als erfolgreich beendet gilt.
- Abgrenzung: Enthält explizit keine Zeit- und Aufwandsschätzung
- Gültigkeit: Im SoPra erwarten wir nur eine Definition of Done für das Gesamtprojekt. Diese kann sich aber im Verlauf des Projekts ändern.
Mitglieder eines Entwickler-Teams werden Entwickler genannt.
Die SoPra-Teilnehmer welche gemeinsam in einer Gruppe bzw. in einem Team an der Entwicklung einer Software beteiligt sind, werden zusammen Entwickler-Team genannt.
Entwurf der zu erstellenden Software. Das Entwurfsdokument enthält mindestens die Dokumentation zur Architektur.
Beschreibung einer Anforderung in Form einer User Story auf höchster Abstraktionsebene. Epic User Stories beschreiben Anforderungen die im Allgemeinen einen Umfang von mehreren Monaten haben.
Beschreibung einer Anforderung in Form einer User Story auf zweithöchster Abstraktionsebene. Features beschreiben Anforderungen die im Allgemeinen einen Umfang von mehreren Wochen haben.
- Querverweise: Critical Feature, Additional Feature
Das im Budgetmodell verwendete Spielgeld wird auf einem Konto als Spielgeldkapital geführt. Das Konto ist eine durch die Investoren geführte Seite im Projekt-Wiki.
- Gültigkeit: Es wird nur durch Investoren nach Meilensteinen aktualisiert.
Beschreibung einer Anforderung in Form einer User Story auf dritthöchster Abstraktionsebene. Implementable Stories beschreiben Anforderungen die im Allgemeinen einen Umfang von mehreren Tagen haben. Ihr werden mehrere Tasks zugewiesen.
Die Bewertung der Abgaben findet durch das Aktualisieren des Kontos statt und wird als Investition bezeichnet.
- Gültigkeit: Findet nur an Meilensteinen statt.
- Querverweise: Budgetmodell
Für die Anwendung des Budgetmodells treten die Betreuer in Kombination mit den Tutoren zur Bewertung der Abgaben als virtuelle Investoren auf, welche neben dem Start-Spielgeldkapital zusätzliches Spielgeld jedem Entwickler-Team individuell, als Investition in die weitere Entwicklung, zur Verfügung stellen.
- Abgrenzung: Kunde
Der Kunde ist derjenige der die zu entwickelnde Software verwenden möchte und die Anforderungen an diese stellt. Der Kunde gibt vor, welche Anforderungen Critical Features und welche Additional Features sind.
- Abgrenzung: Investor
Ein Entwickler-Team hat laufende Kosten mit ihrem Spielgeldkapital zu bezahlen. Laufende Kosten setzen sich aus Fixkosten von 1000 € pro Woche und Personalkosten von 1000 € pro Person pro Woche zusammen. Die Bezahlung erfolgt im Rahmen des Budgetmodells nur an Meilensteinen.
Ein Meilenstein ist ein Zeitpunkt zu dem bestimmte Abgaben von den Investoren als abgegeben erwartet werden und daraufhin bewertet werden und/oder ein wichtiger Termin zu dem das Entwickler-Team anwesend sein muss.
- Abgrenzung: Abgabe, GitLab-Meilenstein zur Gruppierung/Planung von in GitLab-Issues abgebildeten User Stories und Tasks.
- Querverweise: Beschreibung von Meilensteinen
Nach der Bewertung der Abgaben eines Meilensteins werden durch den Meilenstein-Ausgang die Investitionen mit dem aktuellen Spielgeldkapital verrechnet.
- Abgrenzung: Meilenstein-Eingang
- Querverweise: Beschreibung von Meilensteinen
Beim Erreichen eines Meilensteins werden durch den Meilenstein-Eingang die Ausgaben für die laufenden Kosten mit dem aktuellen Spielgeldkapital verrechnet.
- Abgrenzung: Meilenstein-Ausgang
- Querverweise: Beschreibung von Meilensteinen
Das Product Backlog enthält eine Liste der noch zu erfüllenden Anforderungen in Form der User Stories.
- Abgrenzung: Unterscheidet sich vom Sprint-Report
- Unklarheiten: User Stories die erledigt werden sollen, werden in den aktuellen Sprint-Report verschoben und (nur) dort als Done markiert, wenn sie erledigt wurden, oder wieder in das Backlog übernommen, falls nicht.
- Querverweise: Scrum Guide Product Backlog
Fester Zeitraum in dem an durch das Sprint Backlog vorher festgelegten Zielen gearbeitet wird. Im SoPra gibt es zwei Sprints.
Im Sprint Backlog werden alle für den aktuellen Sprint ausgewählten User Stories festgehalten. Es legt damit genau fest, was im Sprint erledigt werden soll.
- Abgrenzung: Sprint Report
- Gültigkeit: Für jeden Sprint erneut festzulegen.
Zusammenfassendes Dokument, welches Testergebnisse, Testabdeckung und zu erledigende sowie erledigte Features, aufgebrochen in ihre Implementable Stories und Tasks, des abgeschlossenen Sprints enthält. Es verwendet den Sprint Backlog als Grundlage.
Beim Schätzen des Umfangs einer User Story (im SoPra nur für Implementable Stories) können als Einheit Story Points verwendet werden. Die genaue Definition wie viel 1 Story Point ist, legt das Team durch das Schätzen der User Storys implizit fest.
- Abgrenzung: Ein Story Point ist keine Zeiteinheit, man kann höchstens im Nachhinein Berechnungen dafür anstellen.
- Gültigkeit: Zeitlich, rämlich, etc.
- Unklarheiten: Häufig wird eine User Story mit einer spontanen Anzahl an Story Points geschätzt und diese Schätzung als Maß für weitere Schätzungen verwendet. Also wie umfangreich andere User Stories im Vergleich mit der ersten User Story sind.
Tasks sind einzelne Aufgaben, die notwendig sind, um die übergeordneten User Stories (Implementable Story oder Feature) fertig zu stellen. Ein Task hat im Allgemeinen einen Umfang von bis zu mehreren Stunden.
In Alltagssprache formulierte Anforderung an eine Software. Je nach Abstraktionsebene werden Epic, Feature und Implementable Story synonym verwendet.
- Querverweise: Task
Definition und Erklärung
- Abgrenzung: Wo ist dieser Begriff nicht anzuwenden
- Gültigkeit: Zeitlich, rämlich, etc.
- Bezeichnung: Eindeutiger Name in der Software, Bezeichnung in der Software
- Unklarheiten:
- Querverweise: Verwandte Begriffe