Der LifeStyle Workflow – Agile Softwareentwicklung in der Praxis

Ein moderner IT-Dienstleister ist am Puls der Zeit, wenn er agile Softwareentwicklung lebt. Wenn diese agilen Methoden von Dienstleister und Kunde vollumfänglich in die Praxis umgesetzt werden, können große Mehrwerte für beide Seiten entstehen.

Durch die hohe Flexibilität ist der Verbesserungsprozess automatisch in den Software-Entwicklungsprozess eingebettet.
Ebenso wird durch die hohe Transparenz für den Kunden der Entwicklungsprozess greif- und steuerbar.

Wir bei LifeStyle haben mit der agilen Entwicklungsmethode Scrum nun schon einige Jahre Erfahrung.
Unseren Scrum Workflow möchten wir in diesem Artikel vorstellen:

Der sogenannte 'Sprint'

Der Sprint ist ein fest definierter Zeitraum. Innerhalb dieser Zeit soll eine bestimmte Anzahl von Aufgaben, auf die sich das LifeStyle-Team vor Sprintbeginn "committed", abgearbeitet werden. LifeStyle arbeitet in 2-wöchigen Sprints, welche immer in Kalenderwochen mit ungerader Nummer starten.

Die Sprint Planung

Das Commitment über die abzuarbeitenden Aufgaben findet in der so genannten Sprintplanung statt. Zu Beginn von Sprint-Woche 1 erfolgt diese zusammen mit dem Kunden und dem Entwickler-Team.
Voraussetzung für eine Sprintplanung ist, dass der Kunde die abzuarbeitenden Aufgaben in Form von Tickets angelegt hat. In diesem müssen Rangfolge und die exakten Anforderungen dokumentiert, sowie die Freigabe zur Entwicklung erteilt sein. Die Auswahl der zu bearbeitenden Tickets für diesen Sprint erfolgt anhand der Priorisierung.
Im Sprint werden ca. 40% der Entwicklerkapazitäten als Puffer freigelassen, da Handlungsfähigkeit für operative Aufgaben des Tagesgeschäfts und Meetings gewährleistet werden muss.
Nach der Sprintplanung wird der Sprint gestartet.

Die Sprint Retrospektive

Am Ende der zweiten Sprint-Woche erfolgt die Retrospektive. Gemeinsam mit dem Kunden werden die letzten beiden Wochen reflektiert. Ziel hierbei ist das frühzeitige Erkennen von Optimierungsbedarf, sowie das gemeinsame Erarbeiten von Verbesserungsmöglichkeiten für die genannten Unstimmigkeiten. Ebenso wird die Kundenzufriedenheit abgefragt und auf einer Skala von 1-5 dokumentiert, wobei 1 für ‚sehr zufrieden‘ und 5 für ‚sehr unzufrieden‘ steht.
Neben der Retrospektive mit dem Kunden findet auch eine Team-interne Retrospektive statt, in der das gleiche Vorgehen mit dem Entwickler-Team und mit dem Product Owner zu Lösungsansätzen führen soll.

Das New Release

Jede Woche wird ein neues Release erstellt. Es werden alle Tickets in das Release aufgenommen, die in der Vorwoche vom Entwickler-Team bearbeitet und vom Kunden abgenommen wurden. Das zusammengestellte Release wird abschließend im Rahmen einer Qualitätskontrolle auf den Staging-Systemen* geprüft.

Das Deployment Release

Jede Woche wird ein neues Release live deployed. Dieses enthält alle Anforderungen, welche vom Entwickler-Team umgesetzt und vom Kunden abgenommen wurden.

Das Estimation Meeting

Jede Woche findet ein Estimation-Meeting statt. Neue Tickets, die der Kunde zwischenzeitlich erstellt hat, werden geschätzt. Im Vorfeld werden die Anforderungen der einzelnen Tickets im Team besprochen und gegebenenfalls Fragen notiert, welche der Product Owner anschließend mit dem Kunden klärt.
Im Estimation-Meeting einigt sich das Team dann über die benötigten Aufwände für die Umsetzung jedes Tickets. Am Ende des Estimation Meetings werden die geschätzten Tickets zurück an den Kunden gegeben. Anhand der Schätzungen kann der Kunde die Tickets im Backlog priorisieren.

Sprint Review

Das Review-Meeting findet jede Woche zusammen mit dem Kunden statt. Jeder Entwickler stellt seine finalisierten Tickets im Detail dem Kunden vor. Ist der Kunde mit der Umsetzung zufrieden, wird das Ticket entsprechend gekennzeichnet, und kann in der folgenden Woche in das neue Release aufgenommen werden. Größere Projekte werden dem Kunden zusätzlich auf einem gesonderten Testsystem zu einem vollumfänglichen Review zur Verfügung gestellt.
Hat der Kunde bezüglich der vorgestellten Features Änderungswünsche werden diese in einem neuen Ticket festgehalten. Diese laufen in den gewohnten Scrum-Rhythmus mit ein.

*bei Staging-Systemen handelt es sich um Systeme, auf denen das neue Release zum Testen bereitgestellt wird, wenige Tage bevor es live deployed wird. Besonderheit an diesen Systemen ist, dass die Live-Datenbanken angebunden sind. D.h. man kann den neuesten Stand der Software im Zusammenspiel mit Produktivdaten testen. Hierbei muss darauf geachtet werden, dass auch schreibende Prozesse auf die Live-Datenbanken zugreifen.

Wollen Sie mehr über individuelle Softwareentwicklung und unsere Arbeitsweise erfahren? Dann nehmen Sie noch heute Kontakt zu uns auf und lassen Sie sich unverbindlich beraten.