Kanban-Projektstart für die Desktop-App: Board, WIP-Limits, Pull und Serviceklassen

Kanban-Projektstart für die Desktop-App: Board, WIP-Limits, Pull und Serviceklassen

https://bildung.social/@oerinformatik/

https://oer-informatik.de/javafx-kanban-projektstart

Kanban, Kanban-Board, WIP-Limit, Pull-Prinzip, Serviceklasse, Expedite, Definition of Done, Akzeptanzkriterien, Scrum, JavaFX, Mitfahr-App

tl/dr; (ca. 24 min Lesezeit): Bevor die erste Zeile JavaFX entsteht, richtet das Team ein Kanban-Board ein: Aus den Wünschen von Fahrer*innen und Verwaltung werden Tickets mit Akzeptanzkriterien, jede Spalte bekommt eine Regel für den Eintritt und ein WIP-Limit, und wer frei ist, zieht sich die nächste Arbeit. Serviceklassen regeln, was schneller gehen darf. Zum Schluss vergleichst Du Kanban mit Scrum und ziehst das erste Ticket [AI-Assisted]. (Zuletzt geändert am 11.11.2026)

Dieser Artikel ist 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

Schon fit in diesem Thema? Nutze die Kann-Liste und die Leitfragen unter dem Artikel als Checkliste, ob Du die relevanten Kompetenzen bereits hast. Hier klicken, um Kann-Liste ein- oder auszublenden

Am Anfang eines Projekts steht selten eine ordentliche Liste. Bei der Desktop-App des Mitfahrlabors ist es nicht anders: Thomas Becker, der das Projekt für die Schule leitet, hat eine Mail mit Wünschen der Fahrer*innen weitergeleitet, Andrea Wolf hat ihre Wünsche für die Verwaltung in einem Gespräch aufgezählt, und im Projektteam liegen Notizen zu Technik, Tests und Installation. Bevor die erste Zeile JavaFX entsteht, bringt das Team Ordnung in diese Sammlung: mit einem Kanban-Board.

Am Ende dieses Artikels sieht das Board so aus wie im Bild: fünf Spalten mit WIP-Limits, eine eigene Bahn für Eiliges, Tickets in vier Farben für vier Serviceklassen, und das erste Ticket ist gezogen.

Stand auf dem Board

Jeder Artikel der Reihe beginnt mit einem Blick auf das Board. Diesmal ist der Blick kurz, denn es gibt noch keins:

Im Team sind drei Personen: Du, Oksana Melnyk, die selbst ohne Auto pendelt und das Projekt von Anfang an begleitet, und eine weitere Person aus dem Projektteam. Thomas Becker entscheidet als Auftraggeber über die Reihenfolge, Andrea Wolf ist Ansprechpartnerin für alles, was die Verwaltung betrifft.

Kanban in Kürze: drei Grundsätze, sechs Praktiken

Der Artikel Kanban erklärt Herkunft und Theorie ausführlich. Für den Projektstart reicht ein kurzer Überblick. Die Kanban-Methode nach David J. Anderson beginnt mit drei Grundsätzen, die sagen, wie man Kanban einführt:

• Beginne mit dem, was Du jetzt tust. Kanban ersetzt keinen Ablauf, sondern macht den vorhandenen sichtbar. Für uns heißt das: Wir bilden die Schritte ab, die wir sowieso gehen (vorbereiten, programmieren, testen), statt einen neuen Prozess zu erfinden.

• Verändere in kleinen Schritten. Spalten, Limits und Regeln sind ein Startpunkt. Das Team ändert sie, wenn es merkt, dass etwas hakt.

• Führung auf allen Ebenen. Jede Person darf Verbesserungen vorschlagen, nicht nur die Projektleitung.

Daraus folgen sechs Kernpraktiken. In der rechten Spalte steht, woran Du sie auf unserem Board erkennst:

Das Pull-Prinzip (ziehen statt zuteilen) steht nicht als eigene Praktik in der Liste, sondern ist die Folge der WIP-Limits: Wenn eine Spalte voll ist, kann man ihr keine Arbeit mehr hineinschieben, sondern nur Arbeit herausziehen, sobald Platz ist. Wie das im Alltag aussieht, zeigt der Abschnitt „Ziehen statt schieben“.

Vom Wunsch zum Ticket

Ein Wunsch wie „Ich will meine Buchungen sehen“ ist noch keine Arbeit, die jemand anfangen kann. Ein Ticket (auch Karte) macht daraus eine Aufgabe mit klaren Grenzen. Unsere Tickets haben immer dieselben Felder:

JFX-nn  <Titel>
Serviceklasse: Standard | Expedite | Fixed Date (<Termin>) | Intangible
Sicht: Fahrer*in | Verwaltung | Technik
Nutzen: Als <Rolle> möchte ich <Ziel>, damit <Nutzen>.
Akzeptanzkriterien:
  - Angenommen <Ausgangslage>, wenn <Handlung>, dann <Ergebnis>.
Gezogen am: <Datum>   Fertig am: <Datum>

Der Nutzen ist als User Story formuliert: Rolle, Ziel und Nutzen. Die Akzeptanzkriterien im Muster „Angenommen … wenn … dann …“ sagen, woran man erkennt, dass das Ticket fertig ist; aus ihnen entstehen später die Abnahmetests. Das Präfix JFX steht für die Desktop-App und unterscheidet die Tickets von denen der anderen Reihen. Ein Ticket soll so klein sein, dass eine Person es in höchstens drei Projekttagen abschließen kann. Was größer ist, wird geteilt.

So sieht das Ticket für die Angebotsliste aus:

JFX-03  Angebotsliste mit ViewModel und Beispieldaten
Serviceklasse: Standard
Sicht: Fahrer*in
Nutzen: Als Fahrer*in möchte ich meine Angebote mit Datum, Uhrzeit,
        Richtung, Haltepunkt und freien Plätzen sehen, damit ich weiß,
        was ansteht.
Akzeptanzkriterien:
  - Angenommen, Ben Richter hat zwei Angebote für den 19.10.2026,
    dann zeigt die Liste beide, nach Abfahrtszeit sortiert.
  - Das ViewModel ist ohne Fenster mit JUnit getestet.

Aus der Wunschsammlung entstehen so zwölf Tickets. Sie decken beide Sichten der App ab und dazu Arbeiten, die nur das Team betreffen (Sicht „Technik“). Die letzte Spalte zeigt, in welchem Artikel der Reihe das Ticket umgesetzt wird:

Die Reihenfolge ist kein fester Plan. Sie zeigt, was nach heutigem Stand sinnvoll aufeinander aufbaut. Kommt ein neuer Wunsch dazu, wird er als Ticket ins Backlog gelegt und beim nächsten Auffüllen eingeordnet.

Die Spalten und ihre Regeln

Die Spalten bilden den Weg ab, den jedes Ticket geht. Wir starten mit fünf:

• Backlog: alle notierten Wünsche, noch nicht geordnet und noch nicht ausgearbeitet.

• Bereit: Tickets, die ausgearbeitet und in eine Reihenfolge gebracht sind. Von hier zieht sich das Team die nächste Arbeit.

• In Arbeit: Eine Person programmiert. Die Spalte ist zweigeteilt in „läuft“ und „erledigt“. In „erledigt“ wartet ein Ticket, bis jemand Kapazität für den Test hat. Ohne diese Unterspalte sähe man nicht, ob ein Ticket noch bearbeitet wird oder nur auf den nächsten Schritt wartet.

• Test: Eine zweite Person prüft die Akzeptanzkriterien und liest den Code (Review).

• Fertig: Das Ticket ist abgeschlossen und kann ausgeliefert werden.

Wichtiger als die Namen sind die Regeln an den Spalten. Kanban verlangt, dass das Team ausdrücklich festhält, wann ein Ticket in eine Spalte darf. Diese Eintrittsregel ist zugleich die Definition of Done der Spalte davor: Sie beschreibt, was erledigt sein muss, bevor das Ticket weiterwandert. Scrum kennt eine Definition of Done für das ganze Inkrement, Kanban hat sie je Übergang.

Die Regel für „Bereit“ verdient einen zweiten Blick. Sie verhindert, dass ein Ticket gezogen wird, bei dem noch unklar ist, was eigentlich verlangt ist. Wer mitten in der Arbeit erst fragen muss, was „übersichtlich“ heißen soll, blockiert einen Platz im WIP-Limit. Ein Ticket ohne Akzeptanzkriterien bleibt deshalb im Backlog, so wichtig es auch sein mag.

WIP-Limits festlegen

Ein WIP-Limit ist eine Zahl über der Spalte: Mehr Tickets dürfen dort nicht gleichzeitig liegen. Das klingt nach einer Einschränkung, und genau das ist es. Ohne Limit fängt jede Person an, was gerade wichtig erscheint. Nach einer Woche sind sieben Tickets „in Arbeit“, keines ist fertig, und niemand weiß, was als Nächstes kommt. Mit Limit gilt: Stop starting, start finishing. Erst wenn etwas fertig ist, darf etwas Neues anfangen.

Für die Startwerte gibt es keine Formel, aber Faustregeln:

• In Arbeit: höchstens so viele wie Personen im Team, besser weniger. Mit drei Personen und einem Limit von 2 ist immer eine Person frei, um zu testen, zu helfen oder ein Expedite-Ticket aufzunehmen. Zusätzlich gilt: jede Person höchstens ein Ticket in „läuft“.

• Test: so groß, dass Tickets nicht vor dem Test liegen bleiben, aber klein genug, dass Testen nicht auf später verschoben wird. Wir starten mit 2.

• Bereit: so viele, wie das Team bis zum nächsten Auffüllen ungefähr schafft. Wir füllen einmal pro Woche auf und schaffen anfangs etwa drei Tickets pro Woche, also 3.

• Backlog und Fertig: ohne Limit. Das Backlog ist ein Wunschspeicher, „Fertig“ das Ende des Wegs.

Warum lohnt sich das? Einen Zusammenhang zwischen den Größen beschreibt Littles Gesetz:

mittlere Durchlaufzeit = mittlerer WIP / mittlerer Durchsatz

Es gilt für Durchschnittswerte über einen längeren Zeitraum. Schafft das Team drei Tickets pro Woche (Durchsatz) und liegen im Mittel sechs Tickets zwischen „Bereit“ und „Fertig“ (WIP), dauert ein Ticket im Mittel zwei Wochen. Senkt das Team den WIP auf drei, ohne langsamer zu arbeiten, sinkt die Durchlaufzeit auf eine Woche. Wer also schneller Ergebnisse will, fängt weniger gleichzeitig an. Die Durchlaufzeit misst Du in Artikel 11 an echten Tickets.

Ziehen statt schieben: der erste Tag am Board

Beim Push-Prinzip teilt jemand Arbeit zu: „Mach Du bitte noch JFX-05.“ Beim Pull-Prinzip holt sich jede Person selbst die nächste Arbeit, und zwar nur dann, wenn sie frei ist und die Zielspalte Platz hat. Wer in welcher Reihenfolge gezogen wird, entscheidet die Reihenfolge in „Bereit“, nicht die lauteste Stimme.

Das tägliche Kanban-Meeting dauert zehn Minuten und geht das Board von rechts nach links durch: Was kann nach „Fertig“? Was wartet auf den Test? Erst danach wird gefragt, was neu begonnen werden kann. So zeigt die Reihenfolge der Fragen schon, worauf es ankommt: erst fertig machen, dann anfangen.

Ein Beispiel aus der zweiten Woche: JFX-01 ist fertig. JFX-02 und JFX-03 stehen in „In Arbeit“, JFX-02 schon in „erledigt“. In „Test“ liegen zwei kleine Tickets, die nachträglich dazukamen und noch niemand geprüft hat. Oksana Melnyk wird frei und möchte JFX-04 beginnen.

• Darf sie JFX-04 ziehen? Nein. „In Arbeit“ hat mit JFX-02 und JFX-03 sein Limit von 2 erreicht.

• Kann sie JFX-02 in den Test holen? Auch nicht, denn „Test“ ist mit zwei Tickets voll.

• Was tut sie stattdessen? Sie hilft beim Test und prüft eines der beiden wartenden Tickets. Ist es fertig, hat „Test“ wieder Platz, sie zieht JFX-02 hinein, und „In Arbeit“ hat Platz für das nächste Ticket aus „Bereit“.

Das Board hat in diesem Moment einen Engpass sichtbar gemacht: Es wird schneller programmiert als getestet. Ohne WIP-Limit wäre JFX-04 einfach angefangen worden, und vor dem Test hätte sich ein immer größerer Stapel gebildet. Mit Limit staut sich die Arbeit sichtbar an einer Stelle, und das Team reagiert dort. Bleibt der Stau mehrere Tage, ist das ein Thema für das Review: Liegt es am Ablauf (zu große Tickets, zu viel Handarbeit beim Testen) oder an den Limits?

Neben dem täglichen Treffen gibt es zwei weitere Termine. Beim Replenishment (Auffüllen) ordnet Thomas Becker einmal pro Woche mit dem Team das Backlog und füllt „Bereit“ bis zum Limit auf. Im Review alle zwei Wochen schaut das Team auf den Ablauf selbst: Wie lange haben Tickets gebraucht, wo hat es gestaut, welche Regel sollte sich ändern?

Serviceklassen: nicht jedes Ticket ist gleich eilig

Bisher folgt alles einer einfachen Regel: Reihenfolge in „Bereit“, WIP-Limits beachten. Manche Aufgaben passen nicht in dieses Schema. Ein Installationspaket, das nach einem bestimmten Tag niemandem mehr nützt, braucht eine andere Behandlung als die Pflege von Abhängigkeiten, die irgendwann erledigt sein soll. Kanban fasst Tickets mit gleichen Regeln deshalb zu Serviceklassen (Classes of Service) zusammen.

Das Expedite-Ticket braucht Disziplin. Die Regel „am WIP-Limit vorbei“ ist bequem, und wenn plötzlich jedes zweite Ticket eilig ist, hebelt das die Limits aus. Deshalb darf es nur eines gleichzeitig geben, und das Team prüft im Review, wie oft es nötig war. Ein Beispiel wird in dieser Reihe tatsächlich vorkommen: Die REST-API kann Haltepunkte bisher nur lesen. Muss die Verwaltung kurzfristig einen Haltepunkt ändern, weil eine Haltestelle wegfällt, kommt ein Ticket für die fehlenden Endpunkte in die Expedite-Bahn. Wie das abläuft, zeigt Artikel 09.

Für JFX-12 lohnt sich ein kurzer Blick auf den Kalender. Am Freitag, dem 18.12.2026, kurz vor den Weihnachtsferien, sollen die Rechner der Verwaltung das Installationspaket bekommen. Braucht ein Ticket im Mittel eine Woche und hat das Paket Abhängigkeiten zu allen anderen Tickets (es muss ja eine fertige App verpacken), muss es spätestens Anfang Dezember in „Bereit“ stehen, besser früher. Ein Fixed-Date-Ticket ist kein Expedite-Ticket: Es bekommt keinen Platz am Limit vorbei, sondern einen rechtzeitigen Platz in der Reihenfolge.

Kanban und Scrum: was anders ist

Den Flurmonitor entwickelt das Projektteam in der Reihe Flurmonitor mit Thymeleaf mit Scrum. Der Scrum-Projektstart des Flurmonitors und dieser Artikel lösen dieselbe Aufgabe, nämlich die Arbeit zu Beginn zu ordnen, aber auf verschiedene Weise. Das Bild stellt die beiden Abläufe gegenüber:

Warum Kanban für die Desktop-App? Die App ergänzt ein System, das schon läuft. Neben geplanten Funktionen kommen Rückfragen der Verwaltung, Fehlermeldungen und Änderungen am Backend. Feste Sprints würden solche Anfragen bis zu zwei Wochen warten lassen oder den Sprint stören. Kanban nimmt sie über das Backlog und die Serviceklassen auf, ohne dass die übrige Arbeit liegen bleibt. Umgekehrt fehlt Kanban der feste Rhythmus, der ein neues Team zu regelmäßigen Ergebnissen und Rückblicken zwingt. Diese Aufgabe übernehmen bei uns das Review alle zwei Wochen und die Kennzahlen.

Das Board im Repository

Ein Board kann an einer Wand hängen, in einem Ticketsystem leben oder als Board in GitLab angelegt werden. Damit Du die Reihe ohne weitere Werkzeuge mitmachen kannst, steht die Workflow-Definition unseres Teams als Markdown-Datei im Repository: src/01-kanban/board.md. Sie enthält Team und Termine, Spalten mit Limits und Regeln, die Serviceklassen, die Ticket-Vorlage, alle Tickets mit ihrer Spalte und einen Abschnitt für Regeländerungen. Ein Ausschnitt aus dem Abschnitt „Spalten, WIP-Limits und Regeln“:

| 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 | 3 | Akzeptanzkriterien stehen fest; Ticket ist klein genug für höchstens drei Projekttage; Reihenfolge im Replenishment abgestimmt. |
| In Arbeit – läuft | 2 (mit „erledigt“) | Eine Person hat das Ticket gezogen und ihren Namen eingetragen. |
...

Weitere Regeln:

- Gezogen wird nur, wenn die Zielspalte unter ihrem WIP-Limit liegt.
- Ist eine Spalte voll, hilft wer frei ist zuerst dort, wo es staut (von rechts nach links schauen).
- Jede Person hat höchstens ein Ticket in „läuft“.
- Ein blockiertes Ticket bekommt einen roten Punkt und den Grund; es zählt weiter zum WIP.

Wenn Du lieber mit einem echten Board arbeitest: GitLab bietet unter „Plan > Issue boards“ Boards an, deren Spalten Labels entsprechen. Die Regeln für den Eintritt schreibst Du dann in die Beschreibung des Labels; ob sich WIP-Limits direkt an einer Spalte eintragen lassen, hängt von der GitLab-Fassung ab, sonst steht das Limit im Namen der Spalte. Wichtig ist nicht das Werkzeug, sondern dass die Regeln für alle sichtbar sind.

Nächster Schritt: das erste Ticket ziehen

Das Board steht, „Bereit“ ist gefüllt, und Du ziehst das erste Ticket: JFX-01 „Projekt anlegen, leeres Fenster startet“. Im nächsten Artikel, JavaFX-Projekt anlegen, legst Du das Projekt mit Gradle an, lernst den Lebenszyklus einer JavaFX-Anwendung kennen und schreibst einen Smoke-Test, der das Fenster startet. Erfüllt das Projekt beide Akzeptanzkriterien, wandert JFX-01 in den Test.

Zum Üben gibt es die Übungsaufgaben zum Kanban-Projektstart: Dort richtest Du ein Board für die Mitfahrgesuche ein und suchst den Engpass in einem Board, das schon eine Weile läuft.

Leitfragen

1. Welche drei Grundsätze stehen am Anfang der Kanban-Methode, und was bedeutet „Beginne mit dem, was Du jetzt tust“ für das Board der Desktop-App? Antwort

Beginne mit dem, was Du jetzt tust; verändere in kleinen Schritten; Führung auf allen Ebenen. Für das Board heißt der erste Grundsatz, dass die Spalten die Schritte abbilden, die das Team ohnehin geht (vorbereiten, programmieren, testen), statt einen neuen Prozess zu erfinden. siehe Abschnitt „Kanban in Kürze“

2. Welche Felder hat ein Ticket auf dem Board, und wozu dienen die Akzeptanzkriterien? Antwort

Nummer und Titel, Serviceklasse, Sicht, Nutzen als User Story, Akzeptanzkriterien sowie die Daten „gezogen am“ und „fertig am“. Die Akzeptanzkriterien legen fest, woran man erkennt, dass das Ticket fertig ist; aus ihnen entstehen die Abnahmetests. siehe Abschnitt „Vom Wunsch zum Ticket“

3. Was ist die Regel für den Eintritt in eine Spalte, und wie hängt sie mit der Definition of Done zusammen? Antwort

Die Eintrittsregel legt fest, was erledigt sein muss, damit ein Ticket in die Spalte darf. Sie ist damit die Definition of Done der Spalte davor. Kanban hat sie je Übergang, Scrum eine für das ganze Inkrement. siehe Abschnitt „Die Spalten und ihre Regeln“

4. Wie wählst Du ein WIP-Limit für die Spalte „In Arbeit“, und was sagt Littles Gesetz über die Wirkung? Antwort

Höchstens so viele Tickets wie Personen im Team, besser weniger, damit jemand für Test und Hilfe frei bleibt. Nach Littles Gesetz ist die mittlere Durchlaufzeit WIP geteilt durch Durchsatz; weniger gleichzeitige Arbeit verkürzt bei gleichem Durchsatz die Durchlaufzeit. siehe Abschnitt „WIP-Limits festlegen“

5. Eine Person wird frei, aber die Spalte „In Arbeit“ ist voll. Was tut sie nach dem Pull-Prinzip? Antwort

Die Person beginnt kein neues Ticket, sondern hilft weiter rechts auf dem Board, etwa beim Test, damit dort Platz wird. Dann rückt ein Ticket aus „In Arbeit“ nach, und erst danach kann sie selbst ein neues Ticket aus „Bereit“ ziehen. siehe Abschnitt „Ziehen statt schieben“

6. Worin unterscheiden sich ein Expedite-Ticket und ein Fixed-Date-Ticket? Antwort

Ein Expedite-Ticket ist sofort dringend, darf am WIP-Limit vorbei und wird zuerst übernommen; es darf nur eines gleichzeitig geben. Ein Fixed-Date-Ticket hat einen festen Termin, folgt aber den WIP-Limits; es wird nur so früh eingeplant, dass es rechtzeitig fertig wird. siehe Abschnitt „Serviceklassen“

7. Nenne drei Unterschiede zwischen Scrum und Kanban. Antwort

Scrum arbeitet in Sprints fester Länge, Kanban ohne Takt im Fluss; Scrum begrenzt die Arbeit über den Sprint-Umfang, Kanban über WIP-Limits je Spalte; Scrum schreibt drei Rollen vor, Kanban keine; Scrum misst meist Velocity, Kanban die Durchlaufzeit. siehe Abschnitt „Kanban und Scrum: was anders ist“

8. Woran erkennst Du auf einem Board einen Engpass? Antwort

Vor einer Spalte sammeln sich Tickets in „erledigt“ bzw. die Spalte bleibt an ihrem WIP-Limit, während die Spalten davor nicht weiterkommen und Personen nichts Neues ziehen dürfen. Bleibt das über mehrere Tage so, gehört der Engpass ins Review. siehe Abschnitt „Ziehen statt schieben“

Links und weitere Informationen

• zum Weiterlesen: Kanban: Arbeit sichtbar machen und begrenzen

• zum Vergleich: Scrum und Scrum-Projektstart des Flurmonitors

• zum Ticket-Schreiben: User Stories

• für den Einstieg: Szenario Mitfahrlabor mit Personas und Regeln

• als Nachschlagewerk: The Kanban Guide (Kanban University)

• als Nachschlagewerk: GitLab-Dokumentation: Issue boards

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: “Kanban-Projektstart für die Desktop-App: Board, WIP-Limits, Pull und Serviceklassen” von oer-informatik.de (H. Stein), Lizenz: CC BY 4.0. Der Artikel wurde unter https://oer-informatik.de/javafx-kanban-projektstart 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]