Motivation

Im Mittelpunkt unseres agilen Software-Entwicklungsprozesses steht die regelmäßige Auslieferung von Produktversionen in kurzen Release-Zyklen unter Gewährleistung hoher Software-Qualität. Folgerichtig können wir unseren Kunden neue Produktfunktionalitäten schnell bereitstellen, flexibel auf Wünsche reagieren und die Risiken im Entwicklungsprozess minimieren. Um diese Ziele zu erreichen, setzen wir seit 2011 auf schlanke Konzeptionsphasen und auf ein inkrementelles Vorgehen gemäß Scrum.

Entwicklungsteams

Die GODYO Business Solutions AG umfasst drei Software-Entwicklungsteams mit einer Teamstärke von vier bis neun Personen. Um nah am Geschehen zu sein, sitzen die Teamleiter größtenteils beim Team. Dies intensiviert den Austausch zwischen Führungskraft und Mitarbeiter, die Führungskräfte agieren teilweise auch als Coach. Alle Teams entwickeln agil gemäß Scrum mit zeitlich parallelen 14-tägigen Sprintzyklen. An GODYO P4 arbeiten zwei Teams mit Schwerpunkt auf verschiedenen Architekturkomponenten Team A konzentriert sich vorrangig auf Geschäfts- und Schnittstellenlogik mittels PL/SQL im ORACLE-Datenbanksystem, während der Fokus von Team B auf Client-, Geschäfts-, und Schnittstellenlogik mittels Java und der GODYO P4 Sales App mit verschiedenen Web-Technologien liegt.

Scrum-Umsetzung

Die Pflege der Aufgabenliste (Product Backlog) verteilen wir bei GODYO P4 bewusst auf zwei eng zusammenarbeitende Product Owner, während Scrum hier eine zentrale Person vorsieht. Zudem verzichten wir auf einen dedizierten Scrum Master, seine Aufgaben werden überwiegend von Teamleitern übernommen. Im Vorfeld von Entwicklungssprints erfolgt die Schätzung der Aufgabengrößen gemäß den Scrum-Vorgaben durch die Teams im Rahmen von Schätzklausuren. Der Ablauf von Entwicklungssprints ist eng an das Scrum-Modell angelehnt. Jedes Team führt zu Beginn ein Planungsmeeting zur Vorstellung und Besprechung des Sprintumfangs durch. Es folgt ein iterativer Entwicklungsprozess, welcher durch ein „Daily Scrum“, einem täglich stattfindenden 15-minütigen Meeting zum gegenseitigen Informationsaustausch unterstützt wird. Es fördert kontinuierliches, gegenseitiges Feedback sowie die Transparenz über den Sprintfortschritt und ermöglicht frühzeitiges Ausräumen von Hindernissen.

Um in jedem Sprint eine stabile neue Version unseres Produkts zu veröffentlichen, durchlaufen Anpassungen und Fehlerkorrekturen eine mehrstufige Qualitätssicherung. Diese umfasst unter anderem folgende Prozesse:

• Manuelle Funktionstests und Abgleich mit der Aufgabenbeschreibung
• Erstellung automatischer Software-Tests und Sicherstellung ihrer Gültigkeit
• Gegenseitige teaminterne Funktions- und Quellcode-Kontrollen
• Vorstellung und Besprechung der Lösung im Rahmen des Sprint-Reviews vor Product Ownern, Consultants und Entwicklern
• Akzeptanztests durch zentrale Nutzer der Kunden

Jeder Sprint endet mit einer teaminternen Sprint-Retrospektive. Sie ermöglicht den Teams einen konstruktiven, vertrauensvollen und offenen Rückblick auf die Abläufe des vergangenen Sprints, um aus der Vergangenheit zu lernen und die Zusammenarbeit zu verbessern.

Teamvergleich

Wir verstehen Scrum als Rahmen und weichen an bestimmten Stellen bewusst von ihm ab. Deshalb realisieren die Entwicklungsteams die Umsetzung einzelner Abläufe unterschiedlich, um sie gezielt an die Herausforderungen der Software-Komponenten und die Entwicklungsmethoden anzupassen. So wird in beiden Teams eine Zeit zur Bearbeitung zeitkritischer Support-Aufgaben eingeplant, deren Anteil am Sprintumfang jedoch variiert. Zudem erfolgt in Team B die teaminterne Qualitätssicherung unmittelbar nach Beendigung einer Aufgabe. Bei Team A erfolgt indessen die Qualitätssicherung aller Sprintaufgaben zusammen nach der Entwicklungsphase, um einen umfassenden Integrationstest für die neue Produktversion zu realisieren.

Erfahren Sie mehr: