Kontakt & Service
Jetzt Beratung vereinbaren

In wenigen Schritten einen Beratungs­termin mit unseren Experten buchen.

Anwender Helpdesk

Hilfestellung bei Problemen in Ihren SAP-Systemen.

Schulungen

Unser Schulungsangebot. Jetzt informieren!

Webinare

Unser Webinarangebot. Jetzt informieren!

News & Wissen Gut pokern und in Sprints ans Ziel: Erfahrungsbericht aus einem agilen ABAP-Entwicklungsprojekt

Johannes Berger (Entwickler)
Autor:

Johannes Berger (Entwickler)

Fast anderthalb Jahre liegt mein erstes agiles ABAP-Entwicklungsprojekt hinter mir. Nun ist es an der Zeit, mit etwas Abstand ein Resümee zu ziehen. Und gleich vorweg: Ich blicke sehr positiv zurück! Ziel des Projekts war die Ablösung eines Alt-Systems, das zur Triebwerküberholung bei einer großen deutschen Fluggesellschaft genutzt wird. Sämtliche Prozesse und Oberflächen mussten dazu in einem SAP R/3-System nachentwickelt werden, was einen erheblichen Aufwand an Individualprogrammierung mit sich gebracht hat. Das Vorgehensmodell des agilen Ansatzes war dabei SCRUM.

Nach drei Jahren, in denen ich ausschließlich in nicht-agilen Projekten gearbeitet habe, war die Umstellung am Anfang groß. Was bedeutet arbeiten nach SCRUM? Was ist die Rolle des Product Owners und was macht ein SCRUM Master? Was sind meine Aufgaben und was nicht? Wichtig zu verstehen war, dass die gesamte Projektzeit in monatliche Sprints aufgeteilt wurde. Das Entwicklungsteam, dem ich angehörte, hatte jeweils vier Wochen Zeit, die vom Product Owner gesetzten Ziele („Sprint Goals“) zu erreichen und diese –  in einem Sprint Review – dem Kunden zu präsentieren.

Der erste Sprint in einem agilen ABAP-Entwicklungsprojekt

Der erste Tag eines jeden Sprints wurde fast ausschließlich der Sprintvorbereitung gewidmet. Dazu präsentierte das Konzeptteam den Entwicklern zunächst alle relevanten Aufgaben („Sprint Items“), wobei direkt erste Fragen geklärt und Feedback gegeben werden konnte. Das Entwicklungsteam hatte nun, in einem zweiten Schritt, die Aufgabe, den Aufwand der einzelnen Aufgaben zu schätzen. Dabei musste jeder Entwickler zunächst für sich in einer Art „Planning Poker“ einschätzen, wie viele „Story Points“ er einer Aufgabe geben würde. Dazu legt er eine Karte mit entsprechender Nummer verdeckt vor sich hin. Story Points sind dabei nicht gleich Tage, sondern vielmehr im Verhältnis zu einer Referenzstory zu sehen.

Die Referenzstory könnte zum Beispiel die Erstellung eines Dynpro mit Verarbeitungslogik sein. Angenommen, der Aufwand dafür wäre mit 3 Story Points beziffert worden, muss jede andere Aufgabe im Verhältnis dazu gesehen werden. Ist der Aufwand der aktuellen Aufgabe kleiner, setzt man weniger Punkte, ist sie größer, mehr. Alle Entwickler deckten nun ihre Karten auf und in der Gruppe wurde solange diskutiert, bis alle mit einer Story Point-Anzahl für eine Aufgabe zufrieden waren. Meist unterhielten sich dabei diejenigen Entwickler zuerst, deren Schätzungen am weitesten auseinanderlagen.

So wurde nach und nach ein Vorrat an Aufgaben aufgebaut, das sogenannte „Sprint-Backlog“, bis die für den jeweiligen Sprint geplanten Story Points erreicht wurden. Sprint Items, die es nicht in den aktuellen Sprint geschafft haben, sind dann automatisch in den nächsten Sprint gewandert. Ein klarer Gewinn für die Entwickler ist dabei, dass nicht der Konzeptschreiber oder der Kunde den Aufwand festlegt, sondern das Entwicklerteam selbst. Auch kann man sich beim Aufwand weniger verschätzen, was wiederum die Effizienz steigern lässt.

Die Vorteile von SCRUM in einem agilen ABAP-Entwicklungsprojekt

Ein weiterer Vorteil beim Arbeiten nach SCRUM war, dass einen die Komplexität eines so umfangreichen Multi-Millionen-Projektes nicht gleich erschlägt. Es ist nämlich erst einmal unerheblich zu wissen, was am Ende rauskommen soll. Ich fokussiere mich ausschließlich auf meine „kleinen“ Aufgaben, die ich mir, der Priorität nach, mit meinen Kollegen vornehme. Die Verantwortung, das große Ganze im Auge zu behalten, trägt alleine der Product Owner.

Der SCRUM Master passt derweil auf, dass das SCRUM-Vorgehen, der Lehre nach, eingehalten wird. Das wiederum bringt einen weiteren Nutzen mit sich: klar abgegrenzte Rollen und Aufgaben! Ich muss nicht nebenbei den Kunden beraten, diskutieren und organisieren, sondern kann mich ganz auf die Entwicklung konzentrieren. Auch die sogenannten „Daylies“, also die morgendliche Runde im Entwicklungsteam, hat die Dynamik und Effizienz steigern lassen. Jeder Entwickler berichtete hier kurz, was er am vorherigen Tag gemacht hat, und was er heute in Angriff nimmt. Vor allem aber wurden über Probleme und Hindernisse diskutiert, die aktuell zu lösen waren. So konnte frühzeitig Unterstützung gegeben oder neue Aufgaben abgeleitet werden. Auch hat es den Zusammenhalt im Team gestärkt und Transparenz im aktuellen Entwicklungsschritt geschaffen. Jeder wusste, woran der andere gerade arbeitet, und eventuelle Überschneidungen konnten vermieden werden.

Der letzte Sprint in einem agilen ABAP-Entwicklungsprojekt

Am letzten Tag eines Sprints wurden dem Kunden die Ergebnisse des Sprints im sogenannten Sprint Review vorgestellt. Als sehr wertig hat sich für uns auch die Sprint Retrospektive herausgestellt, die immer direkt im Anschluss stattfand. Dabei wurde der letzte Monat noch einmal zusammengefasst und man benannte Dinge, die gut und weniger gut liefen. Zu dem verbesserungswürdigsten Punkt leitete man Maßnahmen ab, die im nächsten Sprint umgesetzt wurden. Somit gab es ein ständiges Optimieren der eigenen Arbeitsabläufe, eine Verbesserung der Kommunikation untereinander und zu anderen Projektteilen, und auch die Qualität und Produktivität der Entwicklung wurde hiervon positiv beeinflusst. An Sprint 16 angekommen, war es uns dann fast nicht mehr möglich, weitere Optimierungen vorzunehmen, sodass die Sprint Retrospektive zu Projektende hin dementsprechend kürzer ausfiel.

Fazit

Zusammenfassend kann man sagen, dass das Vorgehen nach SCRUM in einem agilen ABAP-Entwicklungsprojekt erstmal relativ viel Organisation mit sich bringt, die sich in größeren Projekten aber lohnt! Mir als Entwickler kamen die klare Struktur und das fest definiertes Vorgehen sehr entgegen, sodass hinten raus auch viel Zeit eingespart werden konnte. Auch wurde der Druck, der am Ende eines großen Projektes herrscht, auf die einzelnen Sprints aufgeteilt, da in jedem Monat ein definiertes Ziel erreicht werden sollte.

Außerdem haben der kontinuierliche Wissensaustausch und die ständige Transparenz dafür gesorgt, das Know-how unter den Entwicklern aufgeteilt und ein Problem schnell erkannt werden konnte. Aber auch der Kunde hatte durch die monatlichen Präsentationen die Möglichkeit, frühzeitig einzugreifen, Optimierungsvorschläge und Anpassungswünsche zu äußern, aber auch das Präsentierte abzunicken. Agil und dynamisch konnten diese Wünsche berücksichtigt und umgesetzt werden, da eben nur im Monatsrhythmus gedacht wurde.

Newsletter Setzen Sie auf fundiertes Wissen aus allen Bereichen unserer Branche. Regelmäßig und stets aktuell.
2 Personen beraten am Computer
Kontakt Haben Sie Fragen oder wünschen weitere Informationen? Unsere Experten beraten Sie gerne.