Home

Prozessdokumentation

Wir arbeiten Ticket-basiert unter Projects - OCL. Der Workflow eines Tickets (auch Issue genannt) verläuft durch die folgenden Spalten von links nach rechts.

Allgemeine Regeln

• Bei priorisierten Spalten haben die Issues zuoberst immer die höchste Priorität
• Wenn Antwort erwartet wird, ist das Issue der entsprechenden Person zuzuweisen
• Wer zuletzt an einem Issue arbeitet, stellt sicher, dass das Issue in der richtigen Spalte ist

Spalten

Backlog (nicht im Budget 2021)

In dieser Spalte werden Ideen als Issue festgehalten, welche noch nicht für die Umsetzung im Rahmen des Budgets 2021 entschieden sind. Das Backlog ist priorisiert.

Aufwandschätzung

Ein Issue in dieser Spalte soll durch einen Entwickler analysiert und der Aufwand zur Umsetzung grob geschätzt werden.

Ready [Monatsname]

Ein Issue in dieser Spalte soll im entsprechenden Monat umgesetzt werden. Die Spalte ist priorisiert.

In progress

Wird ein Issue durch einen Entwickler umgesetzt, wird es in diese Spalte verschoben. Zudem wird die Person, die daran arbeitet, als Assignees zugewiesen (damit auf einen Blick ersichtlich ist, wer an was arbeitet). Die Zuweisung erfolgt in der Regel am Weekly Standup Meeting.

Review

Jedes Ticket wird nach der Umsetzung durch eine zweite Person geprüft, getestet und Feedback gegeben. Zudem können in dieser Spalte auch Tickets abgelegt werden, bei denen eine Antwort ausstehend ist.

Testable on Integration

Hier befinden sich Tickets, die umgesetzt wurden und auf der Integrationsumgebung getestet werden können. Sobald die Auftraggeberin das OK gibt, wird das Ticket auf die Produktionsumgebung deployed. Das OK erfolgt in Form eines kurzen Textes. Beim Deployment auf die Produktion prüft die Auftragnehmerin, dass die Issues OK sind und fragt gegebenenfalls nach, falls noch kein Feedback vorliegt.

Deployment on Production

Basierend auf dem vereinbarten SLA finden Deployments Mo-Fr statt. Auf Empfehlung von Puzzle nutzen wir hierfür die Mittagszeit, 12:00 bis 13:00 Uhr. Wenn etwas geplant auf die Produktion deployed werden soll, wird dies spätestens am Vortag gemeinsam zwischen der Stadt Luzern (Co-Projektleitung) und Puzzle (Ansprechpartner?) festgelegt. Um die Anwender*innen zu informieren, wird zusätzlich im Header gut sichtbar von Dialog Luzern eine Ankündigung in den 24h davor gemacht inkl. den wichtigsten Infos zum Update (einfache Release Notes mit allenfalls weitergehenden Infos z.B. im Falle eines Decidim-Updates, geführt als neue Page im Partizipationsprozess "Dialog Luzern - das Projekt").

Im Falle von dringenden Updates ebenfalls in gegenseitiger Abstimmung, jedoch ohne Vorankündigung und ohne einem Tag Vorlaufzeit.

Deployed on Production

Diese Spalte ermöglicht der Auftraggeberin, ein Ticket auf der Produktionsumgebung nochmals zu prüfen und ggb. Feedback zu geben, falls etwas nicht in Ordnung wäre.

Done

Hier befinden sich alle erledigten Tickets. Issues initiiert durch die Auftraggeberin werden von ihr in diese Spalte geschoben. Analog werden Issues von der Auftragnehmerin nach Done verschoben, wenn erledigt.

Workflow für Entwickler

Aufwandschätzung

Hat es Tickets die noch geschätzt werden müssen? Wir gehen durch die Tickets und geben entweder eine Schätzung ab oder weisen das Ticket jemandem mit dem nötigen Know-how zu.

Wenn es offene Fragen gibt, wird das Ticket allen Personen zugewiesen, die dazu Input geben könnten.

Ready [Monatsname]

Wir nehmen uns die Tickets aus dem frühesten Monat und arbeiten sie der Reihenfolge nach durch.

Wenn diese Spalte leer ist gehen wir zum nächsten Monat über.

Wir bewegen das Ticket woran wir momentan Arbeiten nach In Progress.

In Progress

Hier befinden sich Tickets an denen momentan gearbeitet wird.

Wenn man fertig mit der Arbeit ist, kann man das Ticket schliessen und nach Review verschieben.

Dies ist automatisiert möglich, per commit oder PR.

Review

Hier befinden sich Tickets, die noch ein Review benötigen oder noch nicht auf die Integration deployed wurden.

Falls man ein Review des Tickets möchte, kann man das Ticket der/den gewünschten Person/en zuweisen.

Ein Ticket wird nach Testable on Integration verschoben sobald es auf der Integration deployed wurde.

Testable on Integration

Hier liegen Tickets die vom Kunden getestet werden / wurden.

Tickets die bereit sind für die Produktion können deployed werden und dann nach Deployed on Production verschoben werden.

Notiz: Wir haben noch keinen offiziellen Weg um ein Ticket als ready for production zu markieren.

Vorschlag: Ein Label namens ready for production

Deployed on Production

Hier liegen Tickets, die ein letztes Mal vom Kunden abgenommen werden.

In dieser Spalte müssen wir nichts mehr machen.

Offene Punkte

• welche Labels wollen wir verwenden?
  • ready_for_production um getestete Tickets auf der Integration als bereit für ein Deployment auf Produktion zu kennzeichnen.
  • question oder _feedback um Tickets zu markieren, die noch Feedback benötigen / offene Fragen haben.
    • Brauchen wir beide? question ist default auf GitHub, feedback ist von uns.