Home

• Prozessdokumentation
  • Allgemeine Regeln
  • Spalten
    • Backlog (nicht im Budget 2021)
    • Aufwandschätzung
    • Ready [Monatsname]
    • In progress
    • Review
    • Testable on Integration
    • Deployment on Production
    • Deployed on Production
    • Done
  • Offene Punkte

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.

Developer Workflow: 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]

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

Developer Workflow: 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

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.

Developer Workflow: Wenn man fertig ist mit der Arbeit an einem Ticket, schliesst man es und verschiebt es nach Review. Dies ist automatisiert möglich, per commit oder PR.

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.

Developer Workflow: Das Ticket wird der/den gewünschten Person/en zugewiesen, die das Ticket reviewen soll/en. Nach einem Deployment auf der Integration wird ein Ticket nach Testable on Integration verschoben.

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.

Developer Workflow: Nach einem Deployment auf der Produktion wird ein Ticket nach Deployed on Production verschoben.

Notiz: Ein Ticket wird per Text als ok dokumentiert und mit dem Tag "ready for production" markiert und somit gut sichtbar.

Vorschlag: Ein Label namens ready for production

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 ([email protected], oder mit ScrumMaster oder mit demjenigen Dev, der für den Release arbeitet) 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.

Offene Punkte

• Welche Labels wollen wir verwenden?
  • 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.