Agile Software­entwicklung

In einer User Story beschreiben wir das Verhalten der zu entwi­ckelnden Software und wie sich ihr Nutzen für den Anwender maximieren lässt. Dabei berück­sich­tigen wir alle relevanten Facetten an Funktio­na­li­täten und Inter­ak­ti­ons­mög­lich­keiten zwischen Anwender und Software. Um im späteren Entwick­lungs­prozess die Software schritt­weise produ­zieren zu können, bilden wir sogenannte »Slices«, also Funkti­ons­gruppen, die für sich betrachtet einen Mehrwert für den Anwender darstellen und nachein­ander imple­men­tiert werden können.

Aus dieser Spezi­fi­kation erstellen wir die Use Cases, die einzelne Funkti­ons­bau­steine der Software aus Sicht des Anwenders beschreiben: »Wer« macht »was« mit der Software und »warum«. Da wir eng mit dem fachlich verant­wort­lichen »Product Owner« (der Kunde bzw. sein Stell­ver­treter bei uns im Unter­nehmen) zusam­men­ar­beiten, können wir dabei auch wesent­liche Akzep­tanz­kri­terien und Kontext­in­for­ma­tionen einbe­ziehen. Die Use Cases bilden eine Art Puzzle, dessen Summe den kompletten Geschäfts­vorfall in einer Software abbildet.

Bei Scrum, einem Vorge­hens­modell für agile Software­entwicklung, wird in zweiwö­chigen Inter­vallen (»Sprints«) entwi­ckelt. Vor Beginn eines jeden Sprints benennt und priori­siert der Product Owner, also der Kunde bzw. der Projekt­ma­nager, als sein Stell­ver­treter bei uns im Unter­nehmen, die zur Entwicklung anste­henden Aufgaben (»User Stories«), die dann von allen Entwicklern genauer geplant werden.
Da der Product Owner für gewöhnlich weder mit Scrum noch mit der Technik vertraut ist, assis­tiert sein Stell­ver­treter im Tages­ge­schäft. Bei der Schätzung der User Stories ist die Anwesenheit des Kunden jedoch wesentlich.
Als agiles und flexibles Vorgehen gerät Scrum in einen gewissen Konflikt mit einem linearen, wasser­fall­ar­tigen Modell in Form von Grob- und Feinkon­zepten. Mit Blick auf Kalku­lation und Angebot stehen wir hierbei in der kaufmän­ni­schen Sorgfalts­pflicht. Deshalb leben wir die Sprints als personell-zeitlichen und quali­tativ-quanti­ta­tiven Rahmen; die mögliche Richtungs­än­derung, wie sie das »Agile Manifest« vorsieht, stellen wir bei uns in den Hinter­grund.

Aufgaben während der Entwicklung

• Zerlegen der User Stories in Tickets in der Reihen­folge, die das Konzept vorsieht
• Schätzen der konkreten Aufwände für die Bearbeitung der einzelnen Tickets
• Erstellung, Bespre­chung und Vertei­digung techni­scher Konzepte
• Entwicklung, Review, QA der Tickets
• Vorstellung der Sprint-Ergeb­nisse an den Kunden
• Dokumen­tation der Arbeits­er­geb­nisse

Unsere Projekt­ma­na­ge­rInnen sind dafür verant­wortlich, Ihr Projekt standar­di­siert in allen techni­schen Systemen aufzu­setzen, im Verlauf zu steuern, gegebe­nen­falls zu eskalieren und fortwährend zu dokumen­tieren. Dabei gibt das projekt­spe­zi­fisch ausge­wählte Projekt­ma­nagement-Framework die Art und Weise vor, wie Ablauf und Steuerung erfolgen und welche Artefakte zum Einsatz gebracht werden. Im Fall von Scrum sind das typischer­weise Daily Standup, Backlog-Grooming, Sprint Planning, Sprint Review sowie Retro­spektive.
Zudem setzen wir ein Projekt­con­trolling ein. Dabei fokus­sieren wir schwer­punkt­mäßig die Prüfung von Soll/Ist relevanter Kennzahlen wie Fortschritt und Budget sowie ungelöste Heraus­for­de­rungen im Projekt­verlauf.

Aufgaben beim Projekt­ma­nagement und Controlling

• Steuerung des agilen Software­ent­wick­lungs­pro­zesses mit Scrum
• Ansprech­partner für den Kunden im Tages­ge­schäft
• Koordi­nieren aller Projekt­be­tei­ligten
• Kontrolle des Entwick­lungs­fort­schritts und der dafür benötigten Zeit

Um Qualität sicher­zu­stellen, braucht es eine konti­nu­ier­liche Messung. Mit etablierten Metriken können wir die Qualität des Quell­codes jederzeit objektiv bestimmen und schnell auf Verän­de­rungen reagieren.
Bei Geschäfts­logik und anderen wichtigen Funktio­na­li­täten sind wir in der Lage, automa­ti­sierte Unit-Tests zu erstellen und auszu­führen. Durch sie lassen sich die Funkti­ons­fä­higkeit und Korrektheit des Produkts prüfen.
In jedem Scrum-Team gibt es einen Mitar­beiter, der auf Quali­täts­si­cherung spezia­li­siert ist. Er kontrol­liert die entwi­ckelte Software funktional und optisch anhand der definierten Akzep­tanz­kri­terien sowie die Einhaltung der verein­barten Code Styles und die Auswertung der Metriken.

Aufgaben der Quali­täts­si­cherung

• Prüfung jedes Tickets gegen die Definition of Done
• Sicher­stellen der Testab­de­ckung und Schreiben von automa­ti­sierten Tests
• Definition und Ausführen von Test-Suites
• Definition, Entwicklung und Ausführung automa­ti­sierter End-2-End-Tests
• Definition und Abarbeiten manueller Testpläne