Issue boards

Issue boards unterstützen die Softwareentwicklung durch die Planung, Organisierung und Visualisierung von Abläufen einzelner Aufgaben. Mithilfe der boards kann der Stand von einzelnen Issues schnell und einfach überprüft werden.

Development board

Das Development board nutzen wir für die Entwicklung von Issues innerhalb der Raindancer Gruppe. Dafür wird immer eine einzelne Person (assignee) ausgewählt. Das Board besitzt 8 verschiedene Spalten: Open, Analysis, Development, Review, Testing - Dev, Testing - Sup, Done - Tested und Closed. Issues dürfen selbst verschoben werden, sofern die Person für den aktuellen Schritt des Issues zuständig ist.

Open

Dieser Bereich umfasst Issues, die geöffnet und dieser Person zugewiesen sind. Die dort enthaltenen Themen werden zurzeit nicht bearbeitet. Die Anordnung der Issues gibt eine Priorisierung an, die höher zu werten ist, als die hinterlegten Sterne im Issue. Dadurch wird deutlich, welche Issues als nächstes bearbeitet werden sollen.

Analysis

Diesr Schritt ist die Vorstufe zur Entwicklung. Hier steht die Spezifizierung und Informationsbeschaffung im Vordergrund. Dadurch kann die Grundlage für den Start der Entwicklung geschaffen werden, sofern diese noch nicht gegeben ist. Zusammenfassend befinden sich in diesem Bereich befinden Issues, für die bereits Informationen angefragt wurden oder eine Analyse aussteht, um nähere Informationen oder auch estimates festzulegen. Issues sollen und dürfen erst dann in die Entwicklung übergehen, wenn ausreichend Informationen vorhanden sind.

Development

Hier sind Issues enthalten, die derzeit in der Entwicklung sind. Sollten Informationen fehlen, sodass die Entwicklung pausiert wird, muss das Issue in Analysis verschoben werden. Wenn es sich um Code-Änderungen handelt, ist dieser Schritt erst abgeschlossen, wenn der finale MR erstellt und einem Reviewer zugewiesen wurde.

Review

Diesr Schritt umfasst Issues, für die bereits ein finaler MR gestellt, aber noch nicht gemerged wurde. Hat die Überprüfung des MRs stattgefunden und es hat sich gezeigt, dass noch etwas überarbeitet werden soll, muss das Issue wieder zurück nach in die Entwicklung, also Development. Wurde der MR gemerged oder die Aufgabe ohne MR abgeschlossen, kann das Issue in den nächsten Schritt übergehen. Dabei kommt es darauf an, ob es getestet werden muss oder direkt geschlossen werden kann. Der Entwickler muss sich überlegen, ob das Issue von einem Supporter oder einem Entwickler getestet werden muss. Je nachdem wird es in Testing - Sup oder Testing - Dev verschoben. Wurde es bereits erfolgreich getestet, kann es in Done - Tested verschoben werden. Issues die keinen Test benötigen, können direkt in Closed (Done) verschoben werden.

Testing - Dev

Issues die diesem Schritt zugewiesen sind, müssen von einem Entwickler getestet werden. Bei aufgetretenen Fehlern oder Problemen, die durch die Entwicklung dieses Issues aufgetreten sind, muss das Issue wieder zurück in Development verschoben werden. Wurde es erfolgreich getestet, kann es in Done - Tested geschoben werden.

Testing - Sup

Issues die den Status Testing - Sup aufweisen, müssen vom Support getestet werden. Bei aufgetretenen Fehlern oder Problemen, die durch die Entwicklung dieses Issues aufgetreten sind, muss das Issue wieder zurück in Development verschoben werden. Wurde es erfolgreich getestet, kann es in Done - Tested geschoben werden.

Done - Tested

Issues die diesen Schritt erreicht haben, wurden erfolgreich getestet und sind nun geschlossen.

Closed (Done)

Dieser Schritt beschreibt Issues, die geschlossen, aber nicht abseits der Entwicklung getestet wurden.