 |
|
Die Anfänge
Im Juli 2011 wurde das konventionelle Arbeitsmodell im Ressort RB der GiS, durch ein agiles Entwicklungsmodell abgelöst, das sich an der SCRUM-Methode orientiert. Mit der Einführung der agilen Methode hat sich im Ressort RB einiges geändert, was nun als Anlass dient, einen Rückblick auf die vergangenen 6 Monate zu werfen.Organisation
Zu Beginn stand die Teambildung und somit eine Neustrukturierung an und bisher getrennte Abteilungen wurden in einem Team vereint. Das neue Team besteht nun aus einem Teamleiter, 3 Entwicklern, 2 Testern und einem Technikredakteur. An zentraler Stelle stehen der Product Owner (PO) und zwei Consultants, die die Kommunikation mit dem Kunden führen. Die Koordination der Aufträge übernimmt der PO. Zusätzlich wird der Prozess von einem SCRUM-Master begleitet, der die Abläufe aufmerksam beobachtet, moderiert, unterstützt und gegebenenfalls konstruktiv zu Verbesserungen anregt.Während die Consultants ihre Aufgaben hauptsächlich bei den Kunden vor Ort wahrnehmen, sind Entwickler, Tester und Redakteur nun nicht mehr räumlich voneinander getrennt, sondern agieren als collocated Team (ein Team, ein Raum), was den Vorteil mit sich bringt, dass alle Teammitglieder Hand in Hand arbeiten und sich bei Ihren Aufgaben gezielt unterstützen können. Hier kommen moderne Methoden wie Pairing, sowohl bei der Programmierung als auch bei Tests und Reviews zum Einsatz. Diese Methode wirkt sich nicht nur positiv auf das Arbeitsergebnis, sondern auch auf das Gemeinschaftsgefühl im Team aus.
Methodik
Die Methodik an sich, gibt zwar Rahmenbedingungen vor, wie die Abwicklung von Tätigkeiten durchgeführt werden kann, bietet jedoch einen hohen Grad an Flexibilität. Die Arbeiten, die zu erledigen sind, werden geplant und in dreiwöchigen Zeitzyklen, den sogenannten Sprints, durchgeführt. Feste Bestandteile des Sprints sind:- Planning
- Daily Standup
- Review
- Retrospektive
Schätzrunde
Die Schätzrunde, die im Ressort RB immer Freitags eingeplant ist, dient als Grundlage für die Planung von Arbeiten. Hier stellt der Consultant die Anforderungen vor, die er bei Kunden aufgenommen hat. Diese werden hinsichtlich des Aufwands bewertet, sowie fachlich diskutiert. Häufig ergeben sich aus den fachlichen Diskussionen offene Punkte, die für eine präzise Schätzung nochmals beim Kunden erfragt werden müssen. Oder es werden Wege aufgezeigt, wie man die fachlichen Funktionen, die sich der Kunde wünscht, optimieren kann. Abgeschlossene Schätzungen werden vom PO aufgenommen und dienen als Basis für die Angebotserstellung. Wird das Angebot vom Kunden beauftragt, werden die daraus resultierenden Aufgaben in einen Sprint eingeplant.Planning
Im Planning, der Planungssitzung am ersten Tag des Sprints, werden vom PO die Funktionen vorgestellt, die Bestandteil des Sprints sein sollen.Die Aufgaben werden im Team besprochen und in sogenannte User Stories beschrieben. Eine User Story entspricht einer für den Kunden nützlichen Funktion, die einen Mehrwert generiert. Die Aufgaben, die zur Durchführung der User Storys erledigt werden müssen, werden in Tasks eingeteilt, die im Umfang einer Tagesaufgabe entsprechen. Diese werden auf einem Zettel am SCRUM-Board festgehalten. Durch diese Vorgehensweise ist das gesamte Team in die Planung der Aufgaben involviert und jeder hat einen Überblick über die Gesamtaufgabe.
Daily Standup
Das Daily Standup (Daily), ist eine tägliche Kurzbesprechung mit einer Dauer von 15 Minuten. In dieser Zeit gibt jedes Teammitglied ein kurzes Feedback zu seinen aktuellen Aufgaben. Die einzigen Punkte hierbei sind:- Was habe ich, seit gestern, bis heute getan?
- Was werde ich bis morgen tun?
- Was hindert mich an meiner Arbeit?
Durch das Daily wird die Kommunikation zwischen den Teammitgliedern gefördert. Es wird frühzeitig ersichtlich, wo Probleme bestehen. Folgeaufgaben, die aus der Erledigung eines Tasks resultieren, können unmittelbar angegangen werden und Aufgaben, bei denen Probleme entstehen oder Unterstützung notwendig wird, können frühzeitig identifiziert werden.
Review
Am Ende eines jeden Sprints steht das Review an, die Abnahme des Gesamtpakets durch den PO. Die umgesetzten Aufgaben des gesamten Teams werden betrachtet und auf korrekte Umsetzung geprüft. Hierbei wird nach dem Prinzip vorgegangen, dass Qualität nicht verhandelbar ist. Der PO hat hierbei die Position des „Single wringable Necks“ (der eine Hals der gewürgt wird), also des Alleinverantwortlichen für Nutzbarkeit der Software. Er muss das Produkt vor dem Kunden verantworten und eventuelle von der Anforderung abweichende Umsetzungen vertreten.Retrospektive
Im Anschluss an das Review wird die Retrospektive durchgeführt, eine Reflexion der vergangenen drei Wochen. Alle Teammitglieder lassen die letzten drei Wochen Revue passieren und setzen sich kritisch mit der gesamten Teamarbeit auseinander. Ebenso hält der SCRUM-Master die Teammitglieder dazu an, sich selbst kritisch zu betrachten. Fragen wie:“ Was haben wir aus den letzten drei Wochen gelernt?“, „Was können wir beim nächsten Mal besser machen?“, aber auch, „Was haben wir besonders gut gemacht?“ tragen dazu bei, den gesamten Prozess als kontinuierlichen Verbesserungsprozess zu betrachten und die Erkenntnisse in den nächsten Sprint einfließen zu lassen. Die Selbstreflexion ist hierbei der wichtigste Prozess, der im SCRUM-Gedanken verfolgt wird, denn nur wer sich selbst kritisch betrachten kann und auch die Bereitschaft zeigt sein Verhalten zu ändern, kann erfolgreich in einem agilen Team mitarbeiten.Timeboxing
Ein weiterer Bestandteil der agilen Methode ist das sogenannte Timeboxing, eine Technik der Projektplanung. Eine Timebox ist hierbei ein fester Zeitrahmen für das Projekt oder einen Vorgang im Projekt. Der Vorgang wird nach der festgelegenen Dauer abgeschlossen, auch wenn nicht alle geplanten Inhalte des Vorgangs abgeschlossen werden konnten. Noch offene Teile werden in eine nachfolgende Timebox verschoben oder gestrichen.Zweck des Timeboxings bei agilen Methoden ist es, die Effizienz eines Projekts oder von Besprechungen zu erhöhen.
Das Timeboxing wird bei den regelmäßigen Treffen des agilen Teams praktiziert. Dabei ist zu beobachten, dass aufgrund der festgelegten Start- und Endzeiten, der Fokus auf das Wesentliche gerichtet wird und nebensächliche Themen verdrängt werden, was den eigentlichen Sprintthemen zugutekommt.
Fazit
Vergleicht man nun die Vorgehensweise der agilen Methode mit der, die vor der Einführung der agilen Methode praktiziert wurde, kann man daraus folgendes Fazit ziehen:Im Vergleich zur bisherigen Methode bietet die agile einen höheren Grad an Flexibilität. Aufgaben werden nicht mehr einem Mitarbeiter allein zugewiesen, sondern können im Team erledigt werden. Nicht selten wird auch auf die Pair-Programming Methode zurückgegriffen, bei der sich Entwickler bei komplexen Aufgaben gegenseitig unterstützen. Tester und Entwickler arbeiten Hand in Hand. Aufgrund der räumlichen Nähe können Fehler direkt kommuniziert und gleich behoben werden. Der Testaufwand ist zwar gestiegen, die Häufigkeit von Fehlermeldungen auf Kundenseite ist in den letzten Monaten jedoch kontinuierlich gesunken.
Die Bildung von Informationsinseln wird komplett eingedämmt, da jedes Teammitglied einen Überblick über das große Ganze erhält. Kopfmonopole werden somit systematisch aufgebrochen, jeder Mitarbeiter wird zum Allrounder und kann sich über alle Themen einen schnellen Überblick verschaffen.
Anforderungen sind nach den gemeinsamen Schätzrunden und technischen Klärungen belastbarer, was die Möglichkeit bietet, Testpläne und Dokumentation bereits vor, beziehungsweise parallel zur Entwicklung zu erstellen. So können Entwicklung, Erstellung der Testpläne und Dokumentation nahezu zeitgleich abgewickelt werden.
Verantwortung wird auf das gesamte Team verteilt, jeder sieht sich als vollwertiges Mitglied des Teams und agiert dementsprechend. Ausgrenzungen oder Absonderungen eines Teammitglieds werden vollständig vermieden.
Die agile Methode fordert und fördert die Mitarbeiter also und ermöglicht ein schnelleres und effizienteres Arbeiten, auch wenn das aufgrund der Vielzahl von Besprechungen auf den ersten Blick nicht den Anschein macht. Durch die Beachtung der Regel, dass Kommunikation das A und O ist, werden Informationen an alle Teammitglieder herangetragen.
„Aus Sicht des Technischen Redakteurs ist die Einführung der agilen Methode und meine direkte Zuordnung zum Team das Beste was mir passieren konnte“, so der Redakteur des Teams.
„Informationen, denen ich früher hinterherlaufen musste, oder, von denen ich gar nicht wusste, dass es sie gibt, können mir jetzt nicht mehr entgehen. Durch die enge Zusammenarbeit und den Einbezug ins Testen erhalte ich viel mehr fachliche Informationen, die nicht nur die Qualität der Dokumentation steigern, sondern auch mein persönliches Verständnis für die Fachlichkeit, die in der GiS-Software abgebildet wird.“
Eine weitere Stimme des Teams erklärt: “Durch den Einbezug der Tester ins Team und die Teilnahme an Schätzrunden und technischen Klärungen, ist es uns nun möglich, Testpläne zeitnah zu erstellen und bei Änderungen direkt anzupassen. Dies ermöglicht uns ein effizienteres Arbeiten und den Abschluss der Tests im vorgegebenen Zeitrahmen.“
„Ein Punkt, den wir noch als verbesserungswürdig einstufen“, so ein weiteres Mitglied des Teams, „ist eine noch stärkere Einbindung von PO, Consultants und Kunden in den Prozess. Hierfür erarbeiten wir jedoch schon Lösungsansätze.“
„Wir wissen noch nicht, wie sich der Einsatz der agilen Methode weiter entwickelt, aber wir wissen schon, wir wollen nicht mehr zurück“, so der allgemeine Tenor des Teams im Bezug auf die agile Methode.
Bleibt also zu sagen, dass die Einführung der agilen Methode zwar einige Umbrüche mit sich gebracht hat, denen der ein oder andere anfangs eher skeptisch gegenüber stand, sie jedoch letztendlich ein Zugewinn für das gesamte Team ist, das den Prozess als lebendigen, kontinuierlichen Verbesserungsprozess betrachtet und diesen auch im vollen Umfang lebt.