Issue boards

Issue boards unterstützen die Softwareentwicklung durch die Planung, Organisierung und auch 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 58 verschiedene Spalten: Open, Stage: Analysis, Stage: Development, Stage:Review, ReviewTesting - Dev, Testing - Sup, Done - Tested und Closed.

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.

Stage: Analysis

DieseDiesr PhaseSchritt ist die Vorstufe zuzur Stage: DevelopmentEntwicklung. Hier steht die Spezifizierung und Informationsbeschaffung im Vordergrund. Dadurch kann die Grundlage für den Start der Entwicklung geschaffen werden.werden, Insofern diese noch nicht gegeben ist. Zusammenfassend befinden sich in diesem Bereich befinden sich also 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.

Stage: Development

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

Stage: Review

DieseDiesr PhaseSchritt umfasst IssuesIssues, 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 Stage: Development. AndernfallsWurde bleibtder MR gemerged oder die Aufgabe ohne MR abgeschlossen, kann das Issue so lange in dieserden Phase,nächsten bisSchritt übergehen. Dabei kommt es nachdarauf Absprachean, inob es Closedgetestet werden muss oder direkt geschlossen verschobenwerden wird.kann. WennDer dasEntwickler Issue diese Phase verlassen hat, ist die Entwicklung abgeschlossen. Bevor Issues diese Phase jedoch verlassen, muss festgelegtsich werden,überlegen, ob das Issue zuvon einem testenSupporter oder einem Entwickler getestet werden muss. Je nachdem wird es in Testing - Sup oder zuTesting - Dev verschoben. Wurde es bereits erfolgreich getestet, kann es in dokumentierenDone - Tested ist.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, währenddie desdurch Testens,die kannEntwicklung dieses Issues aufgetreten sind, muss das Issue wieder neuzurück geöffnet und in Stage: Development verschoben werden. Wurde es erfolgreich getestet, kann es in Closed (Done) geschoben werden.