Agile Methode zur Implementierung von Softwaresystemen
Agile Manifesto
Die Annahme, dass man das Ergebnis eines komplexen Projekts vorab genau beschreiben kann, hat sich in all den Jahren der Anwendung als schlicht und einfach falsch herausgestellt. Deshalb scheitern auch heute noch viele Projekte zur Einführung von komplexen Systemen, wie PIM, MDM oder GDSN.
Aus diesem Grunde etablieren sich agile Methoden zur Implementierung von Softwaresystemen seit Jahren immer mehr.
Die agile Implementierung eines Softwaresystems hat den Vorteil, dass Business und Technik eng zusammenarbeiten, Ergebnisse schnell in einem festen Rhythmus ausgeliefert und vom Business getestet werden können und somit jederzeit die Projektplanung angepasst und nachjustiert werden kann.
Unsere Berater sind nicht nur geschult im Einsatz von agilen Methoden, sondern sie bringen eine langjährige Erfahrung bei der Umsetzung der agilen Prinzipien mit:
Agile Methode zur Implementierung von Softwaresystemen
Die Annahme, dass man das Ergebnis eines komplexen Projekts vorab genau beschreiben kann, hat sich in all den Jahren der Anwendung als schlicht und einfach falsch herausgestellt. Deshalb scheitern auch heute noch viele Projekte zur Einführung von komplexen Systemen, wie PIM, MDM oder GDSN.
Aus diesem Grunde etablieren sich agile Methoden zur Implementierung von Softwaresystemen seit Jahren immer mehr.
Die agile Implementierung eines Softwaresystems hat den Vorteil, dass Business und Technik eng zusammenarbeiten, Ergebnisse schnell in einem festen Rhythmus ausgeliefert und vom Business getestet werden können und somit jederzeit die Projektplanung angepasst und nachjustiert werden kann.
Unsere Berater sind nicht nur geschult im Einsatz von agilen Methoden, sondern sie bringen eine langjährige Erfahrung bei der Umsetzung der agilen Prinzipien mit:
Agile Manifesto
User Story Map – der Überblick über das große Ganze
Agiles Vorgehen heißt nicht ungeplantes Vorgehen. Ganz im Gegenteil. Um den Überblick über das große Ganze zu behalten, setzen wir in unseren Projekten die ‚User Story Map‘ ein.
In dieser wird beschrieben, was die Nutzer mit dem System grundsätzlich machen sollen (‚User Activities‘) und welche Aufgaben (‚User Tasks‘) die Nutzer hierfür ausführen müssen. Wie sie diese ausführen werden, wird dann in den ‚User Stories‘ beschrieben und diese wiederum werden dann den zu liefernden System-Releases zugeordnet.
Für die Entwicklung werden die ‚User Stories‘ wiederum in Entwickler-Aufgaben heruntergebrochen, in das sogenannte ‚Backlog‘ aufgenommen und die Umsetzung im Rahmen des von uns favorisierten SCRUM-Entwicklungsprozesses in Sprints geplant.
User Story Map – der Überblick über das große Ganze
Agiles Vorgehen heißt nicht ungeplantes Vorgehen. Ganz im Gegenteil. Um den Überblick über das große Ganze zu behalten, setzen wir in unseren Projekten die ‚User Story Map‘ ein.
In dieser wird beschrieben, was die Nutzer mit dem System grundsätzlich machen sollen (‚User Activities‘) und welche Aufgaben (‚User Tasks‘) die Nutzer hierfür ausführen müssen. Wie sie diese ausführen werden, wird dann in den ‚User Stories‘ beschrieben und diese wiederum werden dann den zu liefernden System-Releases zugeordnet.
Für die Entwicklung werden die ‚User Stories‘ wiederum in Entwickler-Aufgaben heruntergebrochen, in das sogenannte ‚Backlog‘ aufgenommen und die Umsetzung im Rahmen des von uns favorisierten SCRUM-Entwicklungsprozesses in Sprints geplant.
SCRUM – Sprint für Sprint zum Erfolg
Alle Entwicklungsaufgaben bzw. Anforderungen, die zu einem Zeitpunkt bekannt sind, stehen im Product Backlog.
In einem ‚Sprint-Planning‘, das üblicherweise alle 2 Wochen stattfindet, priorisiert der Product Owner die Anforderungen, die für den nächsten Sprint anstehen und plant diese gemeinsam mit dem Entwickler-Team.
In der Sprint-Planung werden die priorisierten Anforderungen geklärt und der Umsetzungsaufwand geschätzt.
Während des Sprints gibt es ein tägliches ‚Daily Scrum‘ in dem Product Owner und Entwickler Team sich über mögliche Fragen und Probleme austauschen und gemeinsam nach möglichen Lösungen suchen.
Am Ende des 2-Wochen-Sprints gibt es ein ‚Sprint Review Meeting‘. In diesem stellt das Entwickler Team die Ergebnisse vor und der Product Owner nimmt das Produktinkrement ab.
In der anschließenden ‚Sprint Retrospektive‘ reflektiert das gesamte Team darüber, was gut und was schlecht im Sprint funktioniert hat und was es möglicherweise zu verbessern gilt.
SCRUM – Sprint für Sprint zum Erfolg
Alle Entwicklungsaufgaben bzw. Anforderungen, die zu einem Zeitpunkt bekannt sind, stehen im Product Backlog.
In einem ‚Sprint-Planning‘, das üblicherweise alle 2 Wochen stattfindet, priorisiert der Product Owner die Anforderungen, die für den nächsten Sprint anstehen und plant diese gemeinsam mit dem Entwickler-Team.
In der Sprint-Planung werden die priorisierten Anforderungen geklärt und der Umsetzungsaufwand geschätzt.
Während des Sprints gibt es ein tägliches ‚Daily Scrum‘ in dem Product Owner und Entwickler Team sich über mögliche Fragen und Probleme austauschen und gemeinsam nach möglichen Lösungen suchen.
Am Ende des 2-Wochen-Sprints gibt es ein ‚Sprint Review Meeting‘. In diesem stellt das Entwickler Team die Ergebnisse vor und der Product Owner nimmt das Produktinkrement ab.
In der anschließenden ‚Sprint Retrospektive‘ reflektiert das gesamte Team darüber, was gut und was schlecht im Sprint funktioniert hat und was es möglicherweise zu verbessern gilt.
Profitieren Sie von unserer Erfahrung
Sprechen Sie uns an – egal in welcher Projektphase Sie sich aktuell befinden. Wir unterstützen Sie gerne mit unserer Erfahrung.