-
Notifications
You must be signed in to change notification settings - Fork 2
Home
Wir arbeiten Ticket-basiert unter Projects - OCL. Der Workflow eines Tickets (auch Issue genannt) verläuft durch die folgenden Spalten von links nach rechts.
- 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
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.
Ein Issue in dieser Spalte soll durch einen Entwickler analysiert und der Aufwand zur Umsetzung grob geschätzt werden.
Ein Issue in dieser Spalte soll im entsprechenden Monat umgesetzt werden. Die Spalte ist priorisiert.
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.
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.
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.
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.
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.
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.
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.
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
.
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.
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.
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
Hier liegen Tickets, die ein letztes Mal vom Kunden abgenommen werden.
In dieser Spalte müssen wir nichts mehr machen.
- welche Labels wollen wir verwenden?
-
ready_for_production
Um getestete Tickets auf der Integration als bereit für ein Deployment auf Produktion zu kennzeichnen.
-