Übungsaufgaben zum Kanban-Projektstart: ein Board für die Mitfahrgesuche

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 „Kanban-Projektstart: ein Board
für die Mitfahrgesuche“.

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-kanban-projektstart
- https://oer-informatik.de/szenario-mitfahrlabor
- https://oer-informatik.de/kanban
- Stilbeispiel: https://oer-informatik.de/javafx-kanban-projektstart-uebungsaufgaben

Die Aufgaben sollen Inhalte zu diesen Schlagwörtern abdecken:
- Kanban
- Kanban-Board
- WIP-Limit
- Pull-Prinzip
- Serviceklasse
- Definition of Done
- Akzeptanzkriterien
- Engpass
- Littles Gesetz
- Scrum

Kompetenzstufe: Basiskompetenz (alternativ: Kernkompetenz, 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.

Je Zeile 1 Punkt:

Nicht gebraucht: Backlog, Expedite und Sprint. Ein Sprint gehört zu Scrum, nicht zu Kanban.

Je Situation 1 Punkt für die Entscheidung, 1 Punkt für die Begründung:

a) Erlaubt. In „Test“ liegt nur JFX-02, das Limit von 2 ist nicht erreicht, und JFX-03 erfüllt als „erledigt“ die Voraussetzung für den Test (die Pipeline muss vor dem Ziehen grün sein). Danach hat auch „In Arbeit“ wieder Platz.

b) Nicht erlaubt. „In Arbeit“ ist mit JFX-04 (läuft) und JFX-03 (erledigt) voll, denn beide Unterspalten zählen gemeinsam zum Limit von 2. Wer frei ist, hilft zuerst weiter rechts, also beim Test von JFX-03 (siehe a).

c) Nicht erlaubt. Jede Person hat höchstens ein Ticket in „läuft“, und das Limit ist ohnehin erreicht. JFX-04 wird als blockiert markiert (roter Punkt mit Grund) und zählt weiter zum WIP; Oksana Melnyk klärt die Blockade oder hilft beim Test.

d) Erlaubt. Ein gesperrter Haltepunkt, den die App nicht ändern kann, führt dazu, dass Mitfahrende morgen an einer gesperrten Stelle warten. Das ist ein Expedite-Ticket; es läuft in der eigenen Bahn am WIP-Limit vorbei, und die Expedite-Bahn ist leer.

Je Ticket: Titel und Sicht 1 Punkt, Nutzen mit Rolle, Ziel und Nutzen 1 Punkt, prüfbares Akzeptanzkriterium 1 Punkt.

JFX-13  Offene Gesuche an meinem Haltepunkt anzeigen
Sicht: Fahrer*in
Nutzen: Als Fahrer*in möchte ich die offenen Gesuche an meinem Haltepunkt
        für Datum und Richtung meiner Fahrt sehen, damit ich gezielt
        einen Platz anbieten kann.
Akzeptanzkriterien:
  - Angenommen, für Montag gibt es in Richtung „zur Schule“ ab Gütersloh
    ein offenes Gesuch mit dem Zeitfenster 06:45 bis 07:15 Uhr, wenn
    Ben Richter die Gesuche für sein Angebot öffnet, dann sieht er dieses
    Gesuch mit Zeitfenster, aber ohne Namen der suchenden Person.
  - Angenommen, es gibt kein passendes Gesuch, dann zeigt die Liste
    „Keine offenen Gesuche“.

JFX-14  Zu einem Gesuch eine Fahrt anbieten
Sicht: Fahrer*in
Nutzen: Als Fahrer*in möchte ich zu einem Gesuch direkt eine Fahrt
        anbieten, damit die suchende Person schnell eine Mitfahrt findet.
Akzeptanzkriterien:
  - Angenommen, Niklas Fischer hat zu einem offenen Gesuch eine Fahrt
    angeboten und die suchende Person hat sie gebucht, wenn die Liste
    der Gesuche neu geladen wird, dann erscheint das Gesuch nicht mehr
    als offen, sondern als „vermittelt“.

JFX-15  Abgelaufene Gesuche je Haltepunkt auswerten
Sicht: Verwaltung
Nutzen: Als Administratorin möchte ich sehen, wie viele Gesuche je
        Haltepunkt im letzten Monat abgelaufen sind, damit ich erkenne,
        wo Fahrten fehlen.
Akzeptanzkriterien:
  - Angenommen, im Oktober sind am Haltepunkt Gütersloh drei Gesuche
    abgelaufen und an keinem anderen Haltepunkt eines, wenn Andrea Wolf
    die Auswertung für Oktober öffnet, dann zeigt sie für Gütersloh
    den Wert 3 und für alle anderen Haltepunkte 0.

Andere Formulierungen sind richtig, wenn die Kriterien prüfbar sind (konkrete Ausgangslage, Handlung und beobachtbares Ergebnis). Ein Hinweis auf den Datenschutz (keine Namen in der Liste) ist nicht verlangt, aber gut, denn für Gesuche gelten dieselben Regeln wie für die Flurmonitore.

Je Ticket 1 Punkt (Serviceklasse mit passender Begründung):

• JFX-13: Standard. Ein normaler Wunsch ohne festen Termin und ohne drohenden Schaden; die Reihenfolge wird im Replenishment abgestimmt.
• JFX-15: Fixed Date. Nach dem 28.01.2027 ist die Auswertung für diese Entscheidung wertlos; sie wird so früh nach „Bereit“ geholt, dass sie mit der üblichen Durchlaufzeit rechtzeitig fertig ist.
• Neue Hauptversion der JSON-Bibliothek: Intangible. Kein sichtbarer Nutzen für die Nutzenden, aber Aufwand, der später teurer wird; es eilt nicht, weil die alte Version noch gepflegt wird.
• Absturz beim Öffnen der Gesuche: Expedite. Die App ist für Fahrer*innen nicht benutzbar; der Fehler wird sofort und am WIP-Limit vorbei behoben.

| Spalte | WIP-Limit | Regel für den Eintritt (Definition of Done der Spalte davor) |
|---|---|---|
| Backlog | – | Wunsch ist als Ticket mit Titel, Nutzen und Serviceklasse notiert. |
| Bereit | 2 | Akzeptanzkriterien stehen fest; benötigte Endpunkte unter /gesuche sind im Vertrag vorhanden oder als eigenes Ticket angelegt; Ticket passt in höchstens drei Projekttage. |
| In Arbeit | 2 | Eine Person hat das Ticket gezogen und ihren Namen eingetragen. |
| Test | 1 | Code im Repository; ViewModel-Tests und Integrationstest gegen eine nachgebildete REST-API für /gesuche laufen grün; Pipeline grün. |
| Erprobung | 3 | Review durch die zweite Person ohne offene Punkte; Akzeptanzkriterien geprüft; Listen zeigen keine Namen; alle Bedienelemente haben eine Beschriftung für den Screenreader und sind per Tastatur erreichbar. |
| Fertig | – | Lukas Hofmann und Lina Hartwig haben das Ticket am Donnerstag ausprobiert; Rückmeldungen sind erledigt oder als neues Ticket im Backlog. |

a) Je sinnvolle, prüfbare Regel für Bereit, In Arbeit, Test, Erprobung und Fertig 1 Punkt; 1 weiterer Punkt, wenn mindestens zwei der Besonderheiten (Endpunkte unter /gesuche, keine Namen, Screenreader) in den Regeln stehen.

b) Je Limit mit Begründung 1 Punkt:

• Bereit 2: Zwei Personen schaffen bis zum nächsten Auffüllen etwa zwei Tickets; mehr ausgearbeitete Tickets veralten nur.
• In Arbeit 2: höchstens ein Ticket je Person; bei zwei Personen also 2.
• Test 1: Die zweite Person testet; ein Limit von 1 zwingt dazu, einen Test abzuschließen, bevor neue Arbeit in den Test kommt.
• Erprobung 3: Weil nur einmal pro Woche erprobt wird, sammeln sich Tickets bis Donnerstag. Das Limit entspricht etwa dem, was das Team in einer Woche fertig testet; ist es erreicht, wird nichts Neues in den Test gezogen, bis die Erprobung stattgefunden hat.

Andere Zahlen sind richtig, wenn die Begründung zur Teamgröße und zum wöchentlichen Termin passt. Ein Limit für „In Arbeit“ über 2 ist bei zwei Personen nicht sinnvoll begründbar.

a) Der Engpass ist die Spalte Test (1 Punkt). Beobachtungen (je 1 Punkt, höchstens 2): „Test“ ist mit zwei Tickets am Limit, und beide sind die ältesten Tickets auf dem Board (Alter 9 und 8); JFX-16 ist blockiert, JFX-17 wartet seit fünf Tagen, ohne dass jemand testet; JFX-18 liegt seit vier Tagen in „erledigt“ und kann nicht nachrücken; dadurch ist „In Arbeit“ voll, und zwei Personen dürfen nichts ziehen.

b) Durchsatz = 5 Tickets / 10 Projekttage = 0,5 Tickets pro Projekttag (1 Punkt). Mittlere Durchlaufzeit = mittlerer WIP / mittlerer Durchsatz = 4 / 0,5 = 8 Projekttage (1 Punkt). Das passt zum Alter der beiden Tickets im Test.

c) Je Maßnahme 1 Punkt für den Inhalt, 1 Punkt für Zuständigkeit und Zeitpunkt, zum Beispiel:

• Blockade lösen: Eine der beiden freien Personen kümmert sich noch heute darum, dass der Integrationstest eigene Testdaten mitbringt (Gesuche als Testdaten bzw. eine nachgebildete REST-API für /gesuche), statt vom Testsystem abzuhängen.
• Gemeinsam testen: Die andere freie Person testet sofort JFX-17. Ist es fertig, rückt JFX-18 in den Test nach, und „In Arbeit“ hat Platz für das nächste Ticket.
• Regel ergänzen (im Review): Ein blockiertes Ticket wird im täglichen Kanban-Meeting zuerst besprochen, und wer frei wird, schaut zuerst in „Test“, bevor er etwas Neues zieht.

d) Der Vorschlag behebt den Engpass nicht (1 Punkt). Mehr Tickets in „In Arbeit“ würden nur einen größeren Stapel vor dem Test erzeugen, weil dort weiterhin nichts fertig wird (1 Punkt). Nach Littles Gesetz steigt bei gleichem Durchsatz mit dem WIP die Durchlaufzeit: Bei 0,5 Tickets pro Tag und sechs statt vier Tickets im Fluss würde ein Ticket im Mittel 12 statt 8 Projekttage brauchen (1 Punkt). „Herumstehen“ ist das Signal, beim Engpass zu helfen, nicht neue Arbeit zu beginnen.