Claus Kolb

IT Projektmanagement


Auf meinem Blog berichte ich regelmäßig von meinen Erfahrungen aus Kundenprojekten. Folgen Sie mir auf Twitter, um über neue Artikel informiert zu werden.

SAP-Entwicklung nach Scrum: Parallele Änderungen

Oktober 1, 2014Claus Kolb0 Kommentare

Foto: „opensource.com – Improving the speed and quality of research via shared algorithm implementations“ von Meredith Atwater für opensource.com ist lizensiert unter CC BY-SA 2.0

In meinem letzten Projekt habe ich als Scrum Master in einem SAP-Entwicklungsprojekt gearbeitet. Sowohl das Team als auch der Konzern, in dem das Projekt durchgeführt wurde, hatten keine Erfahrung mit Scrum in SAP-Entwicklungsprojekten, so dass wir gleichzeitig Scrum zu Beginn des Projekts eingeführt haben. Dabei waren von Anfang an die Besonderheiten des SAP-Systems zu berücksichtigen. Als ehemaliger Java-Softwareentwickler hatte ich bisher nur wenige Berührungspunkte mit dem SAP-System.

Das SAP-System ist nicht nur eine fertige ERP-Software, die durch Customizing an die eigenen Bedürfnisse angepasst werden kann. Vielmehr ist es auch eine Entwicklungsumgebung, mit der individuelle Erweiterungen programmiert werden können. Die Änderungen wurden durch Änderungsaufträge zusammengefasst, dessen Aufgaben den Entwicklern im Projekt zugeordnet wurden. Solche Änderungsaufträge werden i.d.R. nur einem Projekt zugeordnet, so dass eine parallele Bearbeitung derselben Objekte durch mehrere Projekte nicht möglich ist. Während bspw. in Java-Projekten eine parallele Änderung von Klassen i.d.R. kein Problem darstellt, ist dies mit SAP nicht ohne weiteres möglich. Je nachdem, wie „gefragt“ die im jeweiligen Projekt zu bearbeitenden SAP-Objekte sind, ergeben sich verschiedene Fälle.

Keine Parallelität

In diesem Fall stehen sämtliche SAP-Objekte exklusiv dem Projekt zur Verfügung. Dies ist z. B. bei kompletten Neuentwicklungen der Fall. Da keine parallele Entwicklung stattfindet, gibt es auch keine Auswirkung auf die Vorgehensweise nach Scrum.

Wenig Parallelität

Einige SAP-Objekte werden in diesem Fall auch von anderen Projekten benötigt. Es handelt sich aber um eine überschaubare Anzahl. In diese Kategorie ist das o.g. Projekt gefallen. Dort sind die Epics und User Stories auf Basis eines Grobkonzeptes geschrieben worden, das vor dem Projekt erstellt wurde. Dadurch war es möglich, die Epics und User Stories (fast) vollständig bereits zu Beginn des Projektes zu identifizieren. Das Development Team hat eine grobe technische Analyse der User Storys durchgeführt, um zu bestimmen, welche SAP-Objekte durch welche Epics und User Storys benötigt werden.

Auf dieser Basis haben wir einen Sprint- und Releaseplan erstellt, der für die einzelnen Sprints die benötigten SAP-Objekte erkennen lässt. Diese Anforderungen an die Objektverfügbarkeit haben wir mit den anderen Projekten abgestimmt, damit wir nicht durch parallele Änderungen behindert werden. Nur unter gleichzeitiger Berücksichtigung der benötigten Objekte und der Priorisierung der Epics und User Stories konnten wir sinnvolle Ausbaustufen für den Releaseplan definieren.­­

Zusammengefasst haben wir einen langen Sprint 0 (auch Inception Phase genannt) am Anfang des Projekts ausgeführt, um unsere Anforderungen hinsichtlich der Objektverfügbarkeit mit anderen Projekten zu synchronisieren. Auch während der Projektausführung mussten wir bei der Sprintplanung die Objektverfügbarkeit berücksichtigen und haben in Bezug auf die kritischen Objekte versucht, die Änderungen in wenigen Sprints zusammenzufassen. Dadurch sinkt leider die Flexibilität, SAP-Objekte immer wieder zu ändern und die Funktionalität anzupassen.

Massive Parallelität

In diesem Fall benötigen mehrere Projekte dieselben Objekte über längere Zeiträume und/oder in mehreren Sprints, die nicht zusammenhängen. Eine projektübergreifende Synchronisierung der Objektverfügbarkeit ist i.d.R. nicht mehr möglich bzw. führt zu massiven gegenseitigen Behinderungen. Eine einfache (und unbefriedigende) Lösung besteht darin, die Projekte nacheinander durchzuführen. Eine weitere Möglichkeit ist es, nur in der Realisierungsphase agil nach Scrum zu arbeiten und die Konzeptionsphase vorweg zu machen. In dieser Phase können durch ein iteratives Vorgehen und eine Berücksichtigung des Nutzens der einzelnen Funktionen auch bereits agile Ideen genutzt werden, um nicht alles detailliert vorweg spezifizieren zu müssen.

Die interessanteste und weitreichendste Möglichkeit besteht darin, die Realisierungsarbeiten nicht mehr von Projektteams durchführen zu lassen. Vielmehr werden feste, cross-funktionale Scrum-Teams gebildet, die fest für einzelne Geschäftsprozesse und für die den Prozessen zugeordneten SAP-Objekte zuständig sind. Sämtliche Änderungen an einem SAP-Objekt werden nur von einem einzigen Team durchgeführt, so dass keine parallele Bearbeitung mehr stattfinden kann. Das Projekt selbst wird darauf reduziert, als koordinierende Klammer um parallele Änderungen durch mehrere dieser Teams in unterschiedlichen Bereichen des SAP-Systems zu dienen. Oder Projekte werden ganz abgeschafft und regelmäßig herauszubringende Releases bilden die koordinierende Klammer zur Zusammenstellung sinnvoller, integrierter Funktionsstände.

Die Tatsache, dass SAP-Objekte nur von genau einem Änderungsauftrag bearbeitet werden können, verleitet unabhängig von der Vorgehensweise in Multi-Projektumgebungen dazu, vermehrt neue Objekte anzulegen.

Dies ist der Auftakt einer Serie von Blogartikeln sein, die sich mit den Besonderheiten der Vorgehensweise nach Scrum in SAP-Entwicklungsprojekten befasst. Stay tuned for more!


Eine Antwort eingeben