Agilität ist Flexibilität mit festen Prinzipien
Die Entwicklung anspruchsvoller, individueller E-Commerce-Lösungen erfordert nicht nur die nötige fachliche Kompetenz, sondern auch Methoden, die geeignet sind, unterschiedliche Prozesse und Abläufe innerhalb eines Projektteams möglichst effizient zu koordinieren. Insbesondere bei umfangreichen und komplexen Softwareprojekten ist eine Vorgehensweise nach einem linearen Modell (bspw. dem Wasserfallmodell) ungeeignet, da sie nur sehr bedingt auf veränderte Anforderungen oder unerwartete Herausforderungen reagieren kann.
Im Gegensatz dazu ist die agile Softwareentwicklung grundsätzlich durch ein iteratives Vorgehen gekennzeichnet, bei dem Anforderungsänderungen eher die Regel sind und kein Problem darstellen. Das Projekt wird dazu in viele einzelne Arbeitsschritte unterteilt, die nach und nach abgearbeitet und evaluiert werden. Auf diese Weise werden schon in einer frühen Projektphase konkrete Zwischenergebnisse erzeugt, auf deren Grundlage die Projektanforderungen angepasst und verfeinert werden können.
Agile Projekte folgen (mehr oder weniger strikt) den zwölf Prinzipien der agilen Softwareentwicklung und sind den Werten verpflichtet, die im Agilen Manifest niedergelegt sind. Zentrale Aspekte und Forderungen sind dabei funktionierende Software und Flexibilität in Hinblick auf veränderte Anforderungen sowie ausgeprägte Interaktion und Kooperation zwischen den Beteiligten. Indem die Kund*innen als Product Owner in den Entwicklungsprozess eingebunden werden, um diesen immer wieder Zwischenergebnisse präsentiert zu können, kann das Kundenfeedback in die Entwicklung einfließen, sodass das Produkt im Sinne der Auftraggeber*innen optimiert werden kann. Besonderer Wert wird außerdem auf Effektivität, Effizienz, Schnelligkeit und Qualität gelegt.
Um einen effizienten Projektablauf zu gewährleisten, bedient sich die agile Softwareentwicklung verschiedener Methoden und Prozesse, die bestimmte Regeln und Rollen festlegen. Zu den bekanntesten dieser Methoden im Projektmanagement und in der Produktentwicklung bzw. der konkreten programmiererischen Umsetzung von Softwareprojekten zählen Kanban und Scrum.
Scrum – Agil im Gedränge
Zu den wichtigsten agilen Methoden der Softwareentwicklung zählt Scrum. Der Name ist dem Rugbysport entlehnt und bezeichnet ursprünglich die Spielsituation des angeordneten Gedränges, mit dem nach einer Spielunterbrechung das Spiel neu gestartet wird.
Bei Scrum handelt es sich um ein Rahmenwerk, das besonders gut für die Organisation von Projektteams geeignet ist. Im Kern sieht es nur wenige Regeln vor und bietet viel Raum für eine konkrete methodische Umsetzung und Ausgestaltung. Grundsätzlich geht es dabei darum, umfangreiche Projekte oder digitale Produkte transparent, inkrementell und iterativ voranzutreiben und umzusetzen. Der Entwicklungsprozess wird dazu in kurze Arbeitsschritte, sogenannte Sprints unterteilt, an deren Ende jeweils ein vorher definiertes, nutzbares Zwischenergebnis oder Inkrement steht. Das kann beispielsweise eine bestimmte Produktfunktionalität sein. Ein Sprint-Zyklus dauert zwischen einer und vier Wochen. Die Methode verzichtet auf ausführliche Lasten- und Pflichtenhefte und orientiert sich stattdessen an gewünschten Eigenschaften der Software und Anforderung des Kunden, die in einem Product Backlog (Grob-Lastenheft) aufgelistet, gegebenenfalls ergänzt und nach und nach in kurzen Intervallen abgearbeitet werden.
Das Scrum-Team
Entsprechend der Prinzipien der agilen Softwareentwicklung sind Scrum-Teams so aufgebaut, dass gute Kommunikation und Kooperation gewährleistet sind, sodass letztlich schnell gute Ergebnisse erzielt werden können. Dazu sind in Scrum drei Rollen vorgesehen: Der Product Owner, das Entwicklungsteam und der Scrum Master. Jede dieser Rollen nimmt innerhalb des Scrum-Teams bestimmte Funktionen wahr, um zum Gelingen des Projekts beizutragen.
Die Aufgabe des Product Owners (PO) ist es, das Produkt zu gestalten und zu definieren. Er ist dafür verantwortlich, die Eigenschaften des Produkts festzulegen, zu priorisieren und am Ende der einzelnen Sprints zu bewerten, welche Eigenschaften umgesetzt wurden. Er fungiert als Schnittstelle zwischen dem Entwicklungsteam und den Auftraggeber*innen bzw. den Stakeholdern. Der Product Owner muss darauf achten, dass die gewünschten Produkteigenschaften, die Kosten und die Zeit in einem angemessen Verhältnis zueinander und zum Ziel des Projekts stehen. Er legt fest, welche Eigenschaften in einem Zyklus umgesetzt werden sollen. Als zentrales Dokument, um Produkteigenschaften und Anforderungen festzuhalten, dient das Product Backlog, das der PO im Laufe des Projekts ergänzt, ordnet und aktualisiert.
Für die Entwicklung des Produkts und die Umsetzung der Produkteigenschaften, die im Backlog festgelegt sind, ist das Entwicklungsteam zuständig. Entwicklungsteams arbeiten in Scrum möglichst einständig. Sie organisieren sich selbst und entscheiden auch selbst, wie sie die geforderten Produkteigenschaften umsetzen. Dazu werden in der Sprint-Planung die Backlog-Einträge, die in einem Sprint bearbeitet werden sollen, durch das Team in kleinere Arbeitsschritte aufgeteilt, die im Sprint-Backlog festgehalten werden. Aufgabe des Entwicklungsteams ist es auch, den Arbeitsaufwand einzuschätzen der nötig ist, die einzelnen Punkte des Produkt Backlogs umzusetzen und in der Umsetzung die Qualität zu sichern. In Scrum bestehen Entwicklungsteams aus drei bis neun Personen. Das Team soll dabei einerseits groß genug sein, um eine interdisziplinäre und heterogene Besetzung zu ermöglichen, andererseits muss es klein genug sein, um sicherzustellen, dass eine möglichst einfache Kommunikation und Koordination gewährleistet ist.
Die dritte Rolle ist die des Scrum Masters. Seine Aufgabe besteht einerseits darin, die Scrum-Regeln einzuführen und auf deren Einhaltung zu achten. Andererseits ist der Scrum Master als vermittelnde Instanz und Coach dafür zuständig, das Team zu unterstützen, Probleme und Störungen auszuräumen, die die Arbeit des Teams belasten und wenn nötig die Kommunikation zwischen Entwicklungsteam und PO zu moderieren.
Ereignisse in Scrum
Als Ereignisse werden bei Scrum Teammeetings oder Besprechungen bezeichnet, die der Planung, Organisation und Revision des Arbeitsablaufs bzw. des Scrum-Prozesses dienen.
Ereignisse folgen festen zeitlichen Regeln. Das Scrum-Framework sieht vier verschiedene Ereignisse vor: Das Sprint Planning, das Daily Scrum, das Sprint Review und die Sprint-Retrospektive.
Im Sprint Planning wird festgelegt, welche Ziele im kommenden Sprint-Zyklus erreicht werden sollen. Die umzusetzenden Produkteigenschaften werden vom Product Owner im Product Backlog, dem Grob-Lastenheft, ihrer Priorität nach geordnet und dem Entwicklungsteam vorgestellt. In einem zweiten Schritt plant das Entwicklungsteam, wie die einzelnen Ziele umgesetzt werden sollen. Diese Detailplanung wird im Sprint Backlog niedergelegt. Das Sprint Planning sollte pro Sprint-Woche nicht mehr als zwei Stunden beanspruchen.
Beim Daily Scrum handelt es sich um eine tägliche Besprechung des Entwicklungsteams von 15 Minuten Länge, in der sich das Team über den Projektfortschritt austauscht. Dieses Treffen dient dem Austausch und der Identifikation von etwaigen Problemen, nicht aber der Problemlösung. Wenn nötig, wird dazu ein separater Termin vereinbart.
Sprint Review und Sprint-Retrospektive stehen jeweils am Ende eines Sprints. Während es im Sprint Review darum geht das Ergebnis des Sprints zu überprüfen und zu validieren, konzentriert sich das Team in der Sprint-Retrospektive darauf, die eigene Arbeitsweise zu hinterfragen und gegebenenfalls Verbesserungsmaßnahmen zu entwickeln. Für die Retrospektive sind 45 Minuten pro Sprint-Woche, für das Review eine Stunde vorgesehen. Bei einem Sprint von zwei Wochen Dauer sollte das Review also nicht mehr als 90 Minuten in Anspruch nehmen.
Artefakte in Scrum
Wie bereits angedeutet bildet das Product Backlog die Grundlage des Entwicklungsprozesses. Es listet sämtliche Anforderungen auf, die an das zu entwickelnde Produkt gestellt werden und priorisiert die einzelnen Produkteigenschaften. Das Product Backlog darf dabei aber nicht als starres Korsett für die Produktentwicklung verstanden werden. Vielmehr ist es durch das Product Backlog Refinement einer fortlaufenden Revision durch PO und Entwicklungsteam unterworfen und wird ständig verändert und angepasst. Da bei der Produktentwicklung die Bedürfnisse und Anforderungen von Kund*innen und Usern im Fokus stehen, werden sie im Product Backlog möglichst aus der Perspektive der Anwender*innen formuliert. Dabei können beispielsweise User Stories helfen. Wichtig ist außerdem, dass die einzelnen Entwicklungsschritte dem Kriterium der Nützlichkeit entsprechen, dass der mit ihnen verbundene Aufwand einschätzbar und überschaubar ist, und dass das Ergebnis nach objektiven Kriterien getestet werden kann.
Während im Product Backlog alle Eigenschaften festgehalten werden, die im Rahmen des Scrum-Prozesses fertiggestellt werden sollen, enthält das Sprint Backlog nur diejenigen zu entwickelnden Produkteigenschaften, die für einen konkreten Sprint von ein bis vier Wochen Länge ausgewählt wurden. Im Sprint Backlog werden dazu die verschiedenen Aufgaben bzw. Ziele des Zyklus, konkretisiert und aufgelistet, die zur Erfüllung des Sprint-Ziels zu erledigen sind.
Am Ende jedes Sprints steht ein Product Increment. Dabei handelt es sich um das Ergebnis des Sprints im Sinne der Summe aller erledigter Aufgaben. Wichtig ist, dass das Product Increment nutzbar und nach den gemeinsam festgelegten Kriterien des Teams abgeschlossen ist. Als Ergebnis eines Sprint-Zyklus sollte also eine neue, funktionierende Version der Software zur Verfügung stehen.
Vorteile Agiler Softwareentwicklung für Ihr Projekt
Bei der Entwicklung von Softwareprojekten haben agile Methoden gegenüber linearen Methoden drei wesentliche Vorteile: Sie liefern in kurzer Zeit erste Ergebnisse, bieten die Flexibilität schnell auf veränderte Anforderungen zu reagieren und die größtmögliche Transparenz sowohl im Hinblick auf den Prozess als auch in Hinblick auf die Kosten. Für Ihr E-Commerce-Projekt bedeutet das, dass Sie damit rechnen können, schneller eine erste funktionierende Software zur Verfügung zu haben, auf deren Grundlage Sie testen und Ihr Projekt weiter vorantreiben können. Da agile Projekte in Sprints schrittweise entwickelt werden, sind Sie jederzeit im Bilde und können gegebenenfalls Ihre Anforderungen anpassen, um ein besseres Ergebnis zu erzielen. Gleichzeitig sind auch die Projektkosten jederzeit überschaubar und transparent.
Wenn Sie jetzt neugierig geworden sind, sprechen Sie uns gerne an!
