Übungsaufgaben zu Abnahmetest und Kanban-Metriken

https://bildung.social/@oerinformatik/

https://oer-informatik.de/javafx-abnahmetest-kanban-metriken-uebungsaufgaben

Abnahmetest, Akzeptanzkriterien, JUnit-Tags, Kanban, Durchlaufzeit, Lieferzeit, Durchsatz, Cumulative Flow Diagram, Service Delivery Review, Mitfahrgesuche, Übungsaufgaben, Prüfungsvorbereitung

tl/dr; (ca. 48 min Lese- und Bearbeitungszeit): Übungsaufgaben zu Abnahmetest und Kanban-Metriken in der Desktop-App des Mitfahrlabors: Kennzahlen des Flusses zuordnen und berechnen, ein Cumulative Flow Diagram des Übungsteams lesen, den Abnahmetest für die Gesuche-Ansicht mit JUnit-Tags schreiben und im Service Delivery Review aus Kennzahlen Maßnahmen ableiten [AI-Assisted]. (Zuletzt geändert am 11.11.2026)

Diese Übungsaufgaben sind Teil einer Artikelreihe über eine Desktop-App mit JavaFX: Übersicht / Kanban-Projektstart / Projekt anlegen / FXML, Layouts und CSS / Properties, Bindings und MVVM / Backend anbinden / TableView für Buchungen / Formulare und Dialoge / Anmeldung mit Keycloak / Verwaltung und Diagramme / GUI-Tests mit TestFX / Abnahmetest und Kanban-Metriken / Paketieren mit jpackage

Cumulative Flow Diagram der Desktop-App für die Projekttage 1 bis 33 mit den Bändern Bereit, In Arbeit – läuft, In Arbeit – erledigt, Test und Fertig; eingezeichnet sind der WIP von 3 Tickets am Projekttag 26 und die Lieferzeit von JFX-06 (mit KI erstellt)

Diese Übungsaufgaben gehören zum Artikel Abnahmetest und Kanban-Metriken. Sie führen den Übungsstrang Mitfahrgesuche im Mitfahrlabor fort: Das Übungsteam (drei Personen) entwickelt die Gesuche-Ansicht der Desktop-App weiter und arbeitet nach derselben Workflow-Definition wie das Projekt (Spalten Bereit, In Arbeit – läuft, In Arbeit – erledigt, Test, Fertig; WIP-Limits Bereit 3, In Arbeit 2, Test 2). Für Aufgabe 2.2 ist der Startcode der Ordner src/10-gui-test-testfx/uebung-mitfahrgesuche; die Beispiellösung liegt im Ordner src/11-abnahmetest-kanban-metriken/uebung-mitfahrgesuche. Der Board-Verlauf des Übungsteams steht in src/11-abnahmetest-kanban-metriken/kanban/uebungsteam-verlauf.csv; öffne ihn erst zur Kontrolle.

Hinweise zur Bearbeitung: Bis zur Teil-1-Prüfung der IT-Berufe solltest Du die Basiskompetenz beherrschen, also Aufgabe 1.1. Als FIA, FIDP oder FIDV musst Du zur Teil-2-Prüfung Aufgaben auf Kernkompetenz-Ebene lösen können, das sind Aufgabe 2.1 und Aufgabe 2.2. Von FIA wird zusätzlich erwartet, dass ihnen Aufgaben auf Profilkompetenz-Ebene (Aufgabe 3.1) keine Probleme bereiten. Die Operatoren (ordne zu, berechne, lies ab, nenne, beschreibe, schreibe, entscheide, ermittle, leite ab, beurteile, nimm Stellung) zeigen, wie ausführlich die Antwort sein soll. Durchlaufzeit und Lieferzeit zählen wie im Artikel in Projekttagen, und beide Tage zählen mit. Code schreibst Du in Java mit JUnit 5 und TestFX 4.0.18; statische Importe darfst Du weglassen. Schreib Deine Lösung zuerst vollständig auf und vergleiche erst danach mit der Beispiellösung.

Du möchtest eigene Aufgaben zum Üben von einem KI-Sprachmodell generieren lassen?

Kopiere den Text in ein KI-Sprachmodell Deiner Wahl und passe Kompetenzstufe, Anzahl, Bearbeitungszeit und Szenario bei Bedarf an. Wie die Aufgaben aufgebaut sind, beschreibt der Artikel Wie sind die Aufgaben aufgebaut?. Prüfe die Ergebnisse mit dem Lehrartikel: KI-Sprachmodelle machen Fehler.

Erstelle neue Übungsaufgaben zum Thema „Abnahmetest und Kanban-
Metriken“.

Bauplan: Halte Dich an Aufbau, Kompetenzstufen, Operatoren,
Anforderungsbereiche, Punkte und Zeitschätzung, die im Artikel
https://oer-informatik.de/aufgaben-aufbau beschrieben sind.

Fachliche Grundlage:
- https://oer-informatik.de/javafx-abnahmetest-kanban-metriken
- https://oer-informatik.de/szenario-mitfahrlabor
- https://oer-informatik.de/javafx-kanban-projektstart
- Stilbeispiel: https://oer-informatik.de/javafx-abnahmetest-kanban-metriken-uebungsaufgaben

Die Aufgaben sollen Inhalte zu diesen Schlagwörtern abdecken:
- Abnahmetest
- Akzeptanzkriterien
- JUnit-Tags
- Kanban
- Durchlaufzeit
- Lieferzeit
- Durchsatz
- Cumulative Flow Diagram
- Service Delivery Review
- Mitfahrgesuche

Kompetenzstufe: Kernkompetenz (alternativ: Basiskompetenz, Profilkompetenz, Expertise)
Anzahl: 1 Aufgabe mit Teilaufgaben
Bearbeitungszeit in Minuten ca.: <5 bis 30 min>
Szenario: eines der Szenarien aus dem Bauplan

Vorgehen:
1. Lies zuerst die verlinkten Artikel. Kannst Du keine Webseiten
   abrufen, sag mir das, statt zu raten.
2. Steht bei einer Angabe noch ein Platzhalter in <…>, frag mich
   zuerst danach. Richte Punkte und Zahl der Teilaufgaben nach der
   Bearbeitungszeit (ca. 0,9 min je Punkt).
3. Gib je Aufgabe Titel mit Kompetenzstufe, Ausgangssituation und
   Teilaufgaben mit Operator und Punktzahl aus, dazu die geschätzte
   Bearbeitungszeit.
4. Gib die Beispiellösungen mit Punkteverteilung erst aus, wenn ich
   danach frage.

Aufgabe 1.1: Kennzahlen des Flusses definieren (Basiskompetenz)

Im Service Delivery Review des Übungsteams am Projekttag 49 sagen die Beteiligten folgende Sätze:

Nr.	Aussage
1	„Zwischen Projekttag 42 und 46 sind zwei Gesuche-Tickets fertig geworden.“
2	„Ich habe JFX-35 am Projekttag 38 gezogen, am Projekttag 43 war es fertig.“
3	„JFX-40 steht seit Projekttag 46 in Arbeit oder Test.“
4	„Am Projekttag 44 waren vier Tickets angefangen und noch nicht fertig.“
5	„Ich habe JFX-37 im Replenishment am Projekttag 39 bestellt und konnte es am Projekttag 47 nutzen.“

Ordne jeder Aussage die Kennzahl zu, die sie beschreibt: Durchlaufzeit, Lieferzeit ab Zusage, Durchsatz, WIP oder Ticketalter. (5 Punkte)
Berechne aus den Aussagen 2 und 5 die Durchlaufzeit von JFX-35 und die Lieferzeit ab Zusage von JFX-37. (2 Punkte)
Nenne Start- und Endpunkt der Lieferzeit ab Zusage auf dem Board und beschreibe, was der Commitment Point ist. (2 Punkte)
Gib an, warum das Ticketalter die einzige der fünf Kennzahlen ist, die etwas über ein laufendes Ticket aussagt. (1 Punkt)

je Aussage 1 Punkt:

Nr.	Kennzahl
1	Durchsatz (fertige Tickets je Zeitraum)
2	Durchlaufzeit (vom Ziehen bis „Fertig“)
3	Ticketalter (seit Beginn, noch nicht fertig)
4	WIP (angefangen, nicht fertig, an einem Tag)
5	Lieferzeit ab Zusage (vom Replenishment bis „Fertig“)

je 1 Punkt: Durchlaufzeit JFX-35 = 43 − 38 + 1 = 6 Projekttage. Lieferzeit JFX-37 = 47 − 39 + 1 = 9 Projekttage.
2 Punkte: Start ist der Eintritt in „Bereit“, Ende der Eintritt in „Fertig“ (1 Punkt). Der Commitment Point ist der Punkt, an dem das Team zusagt, das Ticket zu bearbeiten; im Projekt die Aufnahme nach „Bereit“ im Replenishment. Ab dort wartet die Kundschaft (1 Punkt).
1 Punkt: Durchlaufzeit und Lieferzeit stehen erst fest, wenn ein Ticket fertig ist; Durchsatz und WIP sagen etwas über das ganze Board. Nur das Ticketalter zeigt, wie lange ein einzelnes noch offenes Ticket schon unterwegs ist.

Aufgabe 2.1: Ein Cumulative Flow Diagram lesen (Kernkompetenz)

Das Übungsteam hat seinen Board-Verlauf der Projekttage 37 bis 49 als Cumulative Flow Diagram gezeichnet. Jedes Band zeigt die Tickets, die am Ende eines Tages in der jeweiligen Spalte stehen; ein Projekttag reicht im Bild von seiner Markierung bis zur nächsten.

Cumulative Flow Diagram des Übungsteams für die Projekttage 37 bis 49 mit den Bändern Bereit, In Arbeit – läuft, In Arbeit – erledigt, Test und Fertig; die oberste Linie steigt von 3 auf 9 Tickets, die Fertig-Linie von 0 auf 6; ab Tag 41 liegt ein deutliches Band „Test“ zwischen „erledigt“ und „Fertig“ (mit KI erstellt)

Lies ab, wie viele Tickets am Projekttag 44 zwischen „läuft“ und „Fertig“ stehen (WIP) und wie viele am Projekttag 47 in „Test“ stehen. (2 Punkte)
Lies den Durchsatz ab: Wie viele Tickets wurden in den Projekttagen 37 bis 41, 42 bis 46 und 47 bis 49 fertig? (2 Punkte)
Das vierte Ticket, das „Bereit“ erreicht hat, ist JFX-37. Lies seine Lieferzeit ab Zusage waagerecht im Diagramm ab und beschreibe Dein Vorgehen. (2 Punkte)
Beschreibe, welches Band zwischen Projekttag 41 und 48 auffällt, und erläutere, was dieses Muster für den Fluss bedeutet. (3 Punkte)
Ein Teammitglied schätzt mit Littles Gesetz aus WIP und Durchsatz der Projekttage 37 bis 49 die mittlere Durchlaufzeit. Beurteile, ob diese Schätzung hier verlässlich ist. Begründe mit dem Diagramm. (3 Punkte)

je 1 Punkt: Am Tag 44 haben 6 Tickets „läuft“ und 2 „Fertig“ erreicht: 6 − 2 = 4 Tickets WIP (zwei in Arbeit, zwei in Test). Am Tag 47 haben 6 Tickets „Test“ und 4 „Fertig“ erreicht: 2 Tickets in „Test“.
2 Punkte (alle drei richtig 2, zwei richtig 1): Die Fertig-Linie steht am Ende von Tag 41 bei 1, Tag 46 bei 3 und Tag 49 bei 6: Durchsatz 1, 2 und 3 Tickets.
2 Punkte: Auf der Höhe zwischen 3 und 4 Tickets waagerecht von der Stelle, an der die oberste Linie (Bereit) die 4 erreicht (Tag 39), bis zur Stelle, an der die Fertig-Linie die 4 erreicht (Tag 47) (1 Punkt). Lieferzeit 47 − 39 + 1 = 9 Projekttage (1 Punkt). Das Ablesen setzt voraus, dass die Tickets in der Reihenfolge fertig werden, in der sie kommen; hier trifft das zu.
3 Punkte: Das Band „Test“ (lila) ist ab Tag 41 durchgehend ein bis zwei Tickets breit, während es in den Tagen davor nicht zu sehen ist (1 Punkt). Am Tag 45 stehen außerdem zwei Tickets in „erledigt“: Sie sind fertig entwickelt, kommen aber nicht in den vollen Test (1 Punkt). Bedeutung: „Test“ ist der Engpass; Tickets warten dort, die Fertig-Linie steigt langsamer als die Linien darüber, und die Lieferzeit wächst (1 Punkt).
3 Punkte: Nicht verlässlich (1 Punkt). Littles Gesetz gilt für Mittelwerte in einem stabilen System, in dem etwa so viel fertig wird, wie hereinkommt. Im Diagramm laufen die Linien auseinander: Die oberste Linie steigt von 3 auf 9, die Fertig-Linie nur auf 6, der WIP wächst (1 Punkt). Außerdem sind am Ende drei Tickets noch nicht fertig; sie zählen zum WIP, aber noch nicht zum Durchsatz. Die Schätzung (WIP 3,08 / Durchsatz 0,46 ≈ 6,7 Projekttage) liegt deshalb über der gemessenen mittleren Durchlaufzeit der fertigen Tickets (5,7 Projekttage) (1 Punkt).

Aufgabe 2.2: Abnahmetest für die Gesuche-Ansicht (Kernkompetenz)

Thomas Becker möchte das Ticket JFX-13 „Offene Gesuche an meinem Haltepunkt anzeigen“ abnehmen. Für die Abnahme hat das Übungsteam die Akzeptanzkriterien auf den Stand der Gesuche-Ansicht gebracht:

K1: Angenommen, das Gesuche-Fenster öffnet sich, dann zeigt es die offenen Gesuche zur Schule, und darunter steht, wie viele von allen offenen Gesuchen das sind.
K2: Angenommen, ich wähle „nach Hause“ und einen Haltepunkt, dann zeigt die Tabelle nur die Gesuche in diese Richtung an diesem Haltepunkt.
K3: Angenommen, ich tippe einen Teil der Notiz in das Suchfeld, dann zeigt die Tabelle nur Gesuche mit passender Notiz; Groß- und Kleinschreibung spielen keine Rolle.
K4: Angenommen, ich habe Filter gesetzt und klicke „Zurücksetzen“, dann sind die Filter leer und die Tabelle zeigt wieder alle Gesuche zur Schule.
K5: Angenommen, ich bin als Fahrer*in angemeldet, dann lädt die App die offenen Gesuche aus dem Backend und zeigt auch die Gesuche, die andere Personen eingetragen haben.

Im Startcode (src/10-gui-test-testfx/uebung-mitfahrgesuche) startet GesucheGuiTest die Gesuche-Ansicht mit TestFX und den Beispielgesuchen: fünf offene Gesuche, davon drei zur Schule (zwei in Gütersloh, eines in Halle) und zwei nach Hause (Gesuch 2 in Bielefeld-Brackwede, Gesuch 4 in Gütersloh mit der Notiz „mit Sporttasche“). Gesuch 1 (Gütersloh, zur Schule, 16.11.2026, 07:00 bis 08:00) hat die Notiz „komme mit dem Rad zum Bahnhof“. Die fx:ids: haltepunktAuswahl, zurSchule, nachHause, notizSuche, zuruecksetzen, gesucheTabelle, gesuchHinweis.

Entscheide für jedes Kriterium K1 bis K5, ob es sich mit den Beispielgesuchen automatisiert prüfen lässt oder bei der Abnahme von Hand geprüft werden muss. Begründe Deine Entscheidung für K5. (3 Punkte)
Schreibe die Testklasse AbnahmeGesucheTest mit je einem Test für K1 bis K4. Kennzeichne die Klasse so, dass sich nur die Abnahmetests ausführen lassen, und gib jedem Test das Kriterium als lesbaren Namen. Die Methode mit @Start darfst Du aus GesucheGuiTest übernehmen. (8 Punkte)
Ergänze build.gradle.kts so, dass gradlew test -Ptags=abnahme nur die Abnahmetests ausführt, und gib den entsprechenden Maven-Aufruf an. (2 Punkte)
Bei der Abnahme sagt Thomas Becker: „Mir fehlt eine Spalte mit dem Pseudonym der Person, die sucht.“ Entscheide, ob das ein Mangel ist, und gib an, wie das Team damit umgeht. (2 Punkte)

3 Punkte: K1 bis K4 automatisiert, denn sie beschreiben nur die Oberfläche und lassen sich mit den Beispielgesuchen nachstellen (1 Punkt). K5 von Hand (1 Punkt): Das Kriterium verlangt das echte Backend, eine Anmeldung und Gesuche anderer Personen; mit Beispieldaten gibt es weder Backend noch Anmeldung. Teile davon sind durch den Integrationstest RestGesuchQuelleIntegrationTest gegen WireMock abgesichert, die Abnahme prüft aber das Zusammenspiel in der echten Umgebung (1 Punkt).
8 Punkte: Tag und Anzeigenamen 2 Punkte, je Test 1,5 Punkte (Handlung 0,5, Prüfung 1). Statt containsRow reicht in K2 und K3 auch die Prüfung der Zeilenzahl plus eines eindeutigen Werts.

@Tag("abnahme")
@ExtendWith(ApplicationExtension.class)
class AbnahmeGesucheTest {

    private static final LocalDate MONTAG = LocalDate.of(2026, 11, 16);

    @BeforeAll
    static void offeneFensterSchliessen() throws TimeoutException {
        FxToolkit.registerPrimaryStage();
        FxToolkit.cleanupStages();
    }

    @Start
    void start(Stage stage) throws Exception {
        GesucheViewModel viewModel = new GesucheViewModel(Beispielgesuche::offeneGesuche, Runnable::run);
        FXMLLoader loader = new FXMLLoader(MitfahrgesucheApp.class.getResource("gesuche.fxml"));
        loader.setControllerFactory(typ -> new GesucheController(viewModel));
        Parent wurzel = loader.load();
        stage.setScene(new Scene(wurzel, 960, 520));
        stage.show();
    }

    @Test
    @DisplayName("JFX-13 K1: Beim Öffnen zeigt das Fenster die Gesuche zur Schule und wie viele von allen das sind")
    void k1BeimOeffnenGesucheZurSchule() {
        verifyThat("#gesucheTabelle", hasNumRows(3));
        verifyThat("#gesuchHinweis", hasText("3 von 5 offenen Gesuchen"));
    }

    @Test
    @DisplayName("JFX-13 K2: Mit Richtung und Haltepunkt zeigt die Tabelle nur die passenden Gesuche")
    void k2RichtungUndHaltepunkt(FxRobot robot) {
        robot.clickOn("#nachHause");
        robot.clickOn("#haltepunktAuswahl");
        // der Name steht auch in der Tabelle: nur Zellen der Auswahlliste kommen infrage
        robot.clickOn(robot.lookup(".list-cell").match(hasText(Beispielgesuche.GUETERSLOH)).<Node>query());
        verifyThat("#gesucheTabelle", hasNumRows(1));
        verifyThat("#gesucheTabelle", containsRow(MONTAG, LocalTime.of(14, 0), LocalTime.of(15, 0),
                Beispielgesuche.GUETERSLOH, "mit Sporttasche"));
    }

    @Test
    @DisplayName("JFX-13 K3: Ein Teil der Notiz findet das Gesuch, Groß- und Kleinschreibung egal")
    void k3SucheInDerNotiz(FxRobot robot) {
        robot.clickOn("#notizSuche").write("rad");
        verifyThat("#gesucheTabelle", hasNumRows(1));
        verifyThat("#gesucheTabelle", containsRow(MONTAG, LocalTime.of(7, 0), LocalTime.of(8, 0),
                Beispielgesuche.GUETERSLOH, "komme mit dem Rad zum Bahnhof"));
    }

    @Test
    @DisplayName("JFX-13 K4: Zurücksetzen leert die Filter und zeigt wieder alle Gesuche zur Schule")
    void k4Zuruecksetzen(FxRobot robot) {
        robot.clickOn("#nachHause");
        robot.clickOn("#notizSuche").write("Sport");
        verifyThat("#gesucheTabelle", hasNumRows(1));
        robot.clickOn("#zuruecksetzen");
        verifyThat("#gesucheTabelle", hasNumRows(3));
        verifyThat("#notizSuche", node -> ((TextField) node).getText().isEmpty());
    }
}

je 1 Punkt:

tasks.test {
    useJUnitPlatform {
        providers.gradleProperty("tags").orNull?.let { includeTags(it) }
    }
    // ... Monocle-Einstellungen unverändert
}

Maven: mvnw test -Dgroups=abnahme (keine Änderung an der pom.xml nötig).

2 Punkte: Kein Mangel, denn keines der Kriterien K1 bis K5 verlangt das Pseudonym (1 Punkt). Es ist ein neuer Wunsch: Das Team legt ein neues Ticket im Backlog an (Standard), das im Replenishment eingeordnet wird; die Abnahme von JFX-13 wird davon nicht aufgehalten. Weil Gesuch im Vertrag nur die ID der suchenden Person liefert, braucht das Ticket vermutlich auch eine Absprache mit dem Backend-Team (1 Punkt).

Die vollständige Klasse mit Importen liegt im Ordner der Beispiellösung; gradlew test -Ptags=abnahme führt dort genau diese vier Tests aus.

Aufgabe 3.1: Maßnahmen aus Kennzahlen ableiten (Profilkompetenz)

Am Projekttag 49 trifft sich das Übungsteam mit Thomas Becker zum Service Delivery Review. Neben dem Cumulative Flow Diagram aus Aufgabe 2.1 liegen diese Werte vor:

Ticket	Bereit	läuft	Test	Fertig
JFX-34 Gesuch kopieren	37	37	39	39
JFX-35 Gesuche als CSV exportieren	37	38	41	43
JFX-36 Abgelaufene Gesuche ausblenden	37	40	42	45
JFX-37 Gesuche drucken	39	41	44	47
JFX-38 Nur eigene Gesuche anzeigen	41	43	46	48
JFX-39 Tastenkürzel für die Filter	43	44	47	49
JFX-40 Wochenübersicht der Gesuche	44	46	49	–
JFX-41 Auswertung für die Schulkonferenz (Fixed Date: fertig spätestens am Projekttag 53)	46	48	–	–
JFX-42 Gesuch mit Rückfahrt	49	–	–	–

Durchlaufzeit der sechs fertigen Tickets: Mittelwert 5,7, Median 6, 85-%-Perzentil 7 Projekttage. Im Kanban-Meeting hieß es mehrfach: „Wer prüft, ist noch mit dem vorigen Ticket beschäftigt.“ In „Test“ prüft im Übungsteam bisher immer dieselbe Person die Akzeptanzkriterien und liest den Code; die beiden anderen ziehen in der Zeit neue Tickets.

Ermittle für die sechs fertigen Tickets, wie viele Projekttage sie jeweils von „läuft“ bis zum Eintritt in „Test“ und vom Eintritt in „Test“ bis „Fertig“ gebraucht haben. Nenne den Engpass. (4 Punkte)
Leite zwei Maßnahmen für die Workflow-Definition ab. Begründe jede mit den Kennzahlen und gib an, an welcher Kennzahl das Team im nächsten Review erkennt, ob sie gewirkt hat. (6 Punkte)
Beurteile, ob JFX-41 rechtzeitig fertig wird, wenn alles so weiterläuft wie bisher, und schlage ein Vorgehen für die nächsten Kanban-Meetings vor. (4 Punkte)
Ein Teammitglied schlägt vor, das WIP-Limit von „In Arbeit“ von 2 auf 3 zu erhöhen, „damit wir mehr schaffen“. Nimm Stellung. (2 Punkte)

4 Punkte: Tabelle 2 Punkte, Engpass mit Begründung 2 Punkte. „läuft“ bis „Test“ = Test − läuft, „Test“ bis „Fertig“ = Fertig − Test (Tage zwischen den Wechseln):

Ticket	läuft bis Test	Test bis Fertig
JFX-34	2	0
JFX-35	3	2
JFX-36	2	3
JFX-37	3	3
JFX-38	3	2
JFX-39	3	2

Engpass ist „Test“: Nach JFX-34 brauchte kein Ticket weniger als zwei Projekttage in „Test“, obwohl die Prüfung selbst kurz ist. Die Tickets warten auf die eine Person, die prüft; zugleich wächst das Band „Test“ im CFD. Eine Alternative mit gleicher Aussage (Anteil der Zeit in Test an der Durchlaufzeit) ist ebenso richtig.

6 Punkte, je Maßnahme 3 (Maßnahme 1, Begründung 1, Kennzahl 1). Beispiele, zwei davon:

Regel „Wer frei wird, schaut zuerst rechts“: Bevor jemand ein neues Ticket zieht, prüft sie oder er ein Ticket in „Test“, das sie oder er nicht entwickelt hat. Begründung: Prüfen ist nicht an eine Person gebunden, die beiden anderen ziehen sonst neue Arbeit. Wirkung: Zeit von „Test“ bis „Fertig“ sinkt auf höchstens einen Projekttag, Band „Test“ wird schmaler.
Abnahmetests mit @Tag("abnahme") je Kriterium (wie in Aufgabe 2.2) und Bericht aus der Pipeline: Die Prüfung der Kriterien wird schneller, weil nur noch die Kriterien von Hand geprüft werden, die sich nicht automatisieren lassen. Wirkung: Zeit in „Test“ sinkt.
WIP-Limit „Test“ von 2 auf 1 oder ein gemeinsames Limit für „In Arbeit“ und „Test“: Ist „Test“ voll, darf niemand ein neues Ticket ziehen. Begründung: Der WIP stieg auf vier, die Fertig-Linie blieb zurück. Wirkung: WIP sinkt, Lieferzeit ab Zusage sinkt.
Review in Paaren (Entwicklung und Prüfung gemeinsam am Ende von „läuft“). Wirkung: weniger Tage in „Test“.

4 Punkte: JFX-41 läuft seit Projekttag 48. Mit dem 85-%-Perzentil von 7 Projekttagen wäre es spätestens am Projekttag 48 + 7 − 1 = 54 fertig, einen Tag nach dem Termin (2 Punkte: Rechnung 1, Bewertung 1). Vorgehen (2 Punkte): JFX-41 hat Vorrang in „Test“ (es darf am Ende nicht auf die Prüfung warten); im Kanban-Meeting wird jeden Tag das Ticketalter von JFX-41 genannt; ist es nach vier Projekttagen (Projekttag 51) noch nicht in „Test“, helfen zwei Personen daran mit; Thomas Becker wird früh informiert, falls ein Teil der Auswertung später kommen muss.
2 Punkte: Ablehnen (1 Punkt). Der Engpass ist „Test“, nicht „In Arbeit“. Mehr gleichzeitig angefangene Tickets füllen nur „erledigt“ und „Test“ weiter, der Durchsatz steigt nicht, und nach Littles Gesetz steigt bei gleichem Durchsatz mit dem WIP die Durchlaufzeit (1 Punkt).

Links und weitere Informationen

zum Artikel: Abnahmetest und Kanban-Metriken: Akzeptanzkriterien prüfen, den Fluss messen und den Ablauf verbessern
zum Board: Kanban-Projektstart für die Desktop-App
zum Übungsstrang: Übungsaufgaben zu GUI-Tests mit TestFX
als Nachschlagewerk: Der Kanban Guide (Flow-Kennzahlen)
für den Einstieg: Szenario Mitfahrlabor mit Personas und Regeln

Hinweis zur Nachnutzung als Open Educational Resource (OER)

Dieser Artikel und seine Texte, Bilder, Grafiken, Code und sonstiger Inhalt sind - sofern nicht anders angegeben - lizenziert unter CC BY 4.0. Nennung gemäß TULLU-Regel bitte wie folgt: “Übungsaufgaben zu Abnahmetest und Kanban-Metriken” von oer-informatik.de (H. Stein), Lizenz: CC BY 4.0. Der Artikel wurde unter https://oer-informatik.de/javafx-abnahmetest-kanban-metriken-uebungsaufgaben veröffentlicht, die Quelltexte sind in weiterverarbeitbarer Form verfügbar im Repository unter https://gitlab.com/oer-informatik/javafx/javafx-einstieg. Erstellt mit KI-Assistenz; von mir umfassend redaktionell überarbeitet, geprüft und freigegeben. Stand: 11.11.2026.

[Kommentare zum Artikel lesen, schreiben] / [Artikel teilen] / [gitlab-Issue zum Artikel schreiben]

Übungsaufgaben zu Abnahmetest und Kanban-Metriken