UNSERE ARBEITSWEISE

Neue Anforderungen an unsere Software 360^e werden in Workshops erarbeitet, die unser Projekt-Team gemeinsam mit unseren Neukunden durchführt. Hintergrund kann zum Beispiel eine besondere Produktpalette mit speziellen Anforderungen an den Kundenservice oder Versand und somit auch an 360^e sein. Weitere Anforderungen erreichen uns direkt von bestehenden Kunden, die kontinuierlich die Software mit uns weiterentwickeln.

Die Anforderungen werden als User Story formuliert. Durch die Formulierung in der Form „Als [Nutzer] möchte ich [Funktionalität]…, um [Nutzen]… zu erreichen“ wird deutlich, wer aus welchem Grund eine fachliche Anforderung an die Software stellt. Präzisiert wird die Anforderung durch die Formulierung der Akzeptanzkriterien. Die Stories schneiden wir so, dass durch die Umsetzung ein zusätzliches Teil lauffähiger Software entsteht, das einen entsprechenden Geschäftsnutzen erbringt.

Als Produktverantwortlicher stellt unser Product Owner dem Entwicklungsteam die User Stories vor. Nach fachlicher Klärung nimmt das Entwicklungsteam im Estimation Meeting eine Komplexitätsschätzung der Stories in Story Points vor.

Die Stories werden in unserem Backlog gesammelt und vom Product Owner in Abstimmung mit den Stakeholdern priorisiert. Stakeholder sind unsere Kunden, unser Kundenservice als Vertreter der Bestandskunden und das Projekt-Team als Fürsprecher der laufenden Neukundenprojekte.

Die Umsetzung der User Stories erfolgt im Rahmen eines Sprints, einem Vorgang mit festgelegter Dauer, die bei e-velopment genau zwei Wochen beträgt.

Zum Start eines neuen Sprints werden die am höchsten priorisierten Stories in das Sprint Backlog übernommen. Im Sprint Planning werden diese Stories vom Entwicklungsteam besprochen und es werden gemeinsam die Aufgaben festgelegt, die zur Umsetzung der Stories erforderlich sind. Das Entwicklungsteam legt mit dem Forecast den Umfang der Stories fest, der in dem Sprint umgesetzt werden soll.

Die Weiterentwicklung der Software erfolgt durch die Bearbeitung der Stories im Sprint. Die Übersicht über alle Stories, die im aktuellen Sprint bearbeitet werden, findet sich auf dem Scrumboard des jeweiligen Entwicklungsteams. Im Laufe des Sprints werden die Aufgaben der Stories umgesetzt, der Arbeitsfortschritt wird am SCRUM-Board visualisiert. Täglich zur selben Zeit findet sich das SCRUM-Team zum Daily zusammen. Hier erfolgt die Kommunikation über den Arbeitsfortschritt. Drei Fragen werden von jedem Teilnehmer beantwortet:

• was habe ich gestern erreicht?
• was will ich heute erreichen?
• was behindert mich?

So fokussiert sich das Team auf das Erreichen der Ziele, auftretende Hindernisse werden benannt. Diese Hindernisse zu beseitigen bzw. das Team dazu zu befähigen, ist eine der zentralen Aufgaben des Scrum Masters. Unser Scrum Master unterstützt das Entwicklungsteam bei der Selbstorganisation, sowie dem Erkennen und Lösen von Konflikten. Er stellt sicher, dass Scrum verstanden und umgesetzt wird, und dass die Praktiken und Regeln eingehalten werden.

Das Ergebnis eines Sprints ist ein neues Release der Software 360^e Am Ende des Sprints setzen sich die Scrum Teams inkl. der Product Owner zusammen, um sich und den anderen Beteiligten die Ergebnisse im Rahmen des Reviews vorzustellen. Ergänzend zum neuen Release erhalten unsere Kunden die Release Notes, in denen wir die neuen Funktionen der Software vorstellen.

Nach dem Review findet zum Anschluss des Sprints die Retrospektive statt. Dabei handelt es sich um ein Teamtreffen, in dem es darum geht, aus der Vergangenheit zu lernen. In einem Rückblick wird bewertet, was gut und was schlecht gelaufen ist. Es werden die Ursachen erörtert und Maßnahmen zur Verbesserung abgestimmt.

Nach jedem Sprint beginnt wieder die Vorbereitung auf den nächsten Sprint, und der Prozess bei e-velopment wird wieder von neuem gestartet.