Die effiziente und fehlerarme Entwicklung komplexer Software-Systeme stellt für Unternehmen eine große Herausforderung dar. In der Praxis hat sich gezeigt, dass die Ursache des Scheiterns von Software-Projekten in vielen Fällen eine ungenügende Anforderungsdefinition ist.
Anforderungen definieren
Anforderungen, die in der Planungsphase nicht hinreichend spezifiziert wurden, führen in der Roll-out-Phase oftmals zu ungeplanten Aufwänden in Form von Nacharbeit und auf der Benutzerseite zu Unzufriedenheit bis hin zur Ablehnung des neuen Systems. Aus dieser Erkenntnis heraus hat sich zur Steuerung von Software-Vorhaben eine Management-Methode entwickelt, die als Requirements Management oder Anforderungsmanagement bezeichnet wird. Diese Methode umfasst dabei die Anforderungserhebung und Anforderungsdefinition, sowie Maßnahmen zur Steuerung, Kontrolle und Verwaltung von Anforderungen, also Risikomanagement, Änderungsmanagement und Umsetzungsmanagement.
Anforderungen als User Stories
Ziel des Anforderungsmanagement ist es letztendlich, ein gemeinsames Verständnis über ein zu entwickelndes System zwischen allen Beteiligten zu erreichen. Eine Anforderung selbst ist dabei eine Aussage über eine zu erfüllende Eigenschaft oder zu erbringende Leistung eines Produktes, Systems oder Prozesses. In der agilen Software-Entwicklung werden Anforderungen als User Stories abgebildet. Diese beschreiben ein Stück gewünschte Funktionalität aus Sicht des Benutzers in ein bis zwei Sätzen. Die Formulierung erfolgt dabei in Alltagssprache und hat noch keinen technischen Hintergrund. Neben der Beschreibung an sich hat eine User Story auch Abnahmekriterien, anhand derer im Test festgestellt werden kann, ob die Anforderung durch den Entwickler vollständig und fehlerfrei umgesetzt wurde.
Aufwand schätzen
Für jede User Story gibt es eine Aufwandsschätzung. Dabei orientieren sich die Entwickler an bereits implementierten Anforderungen und setzen den Aufwand der zu schätzende User Story dazu in Beziehung. Aus dem tatsächlichen Aufwand der bereits umgesetzten Anforderung und dem dazu relativen Aufwand der zu schätzenden User Story erhält man dann den geschätzten absoluten Aufwand. Die Gesamtheit aller User Stories bildet das Product Backlog. Die User Story wird zur Implementierung in einzelne Entwicklungs-Tasks aufgeteilt, in denen auf technischer Basis detailliert beschrieben ist, wie die neue Funktionalität umzusetzen ist.
Entwicklungsplanung auf der Basis von Sprints
In der agilen Software-Entwicklung erfolgt die zeitliche Entwicklungsplanung auf Basis von Sprints, wobei ein Sprint normalerweise den Zeitraum eines Monats umfasst und ein definiertes Beginn- und Enddatum besitzt. Aus der Anzahl der verfügbaren Entwicklerressourcen und der Aufwandsschätzungen der User Stories lässt sich eine Planung der umzusetzenden Funktionalitäten innerhalb eines Sprints vornehmen. War die Aufwandsschätzung zu großzügig, können am Ende des Sprints noch User Stories aus dem Backlog in die aktuelle Entwicklung übernommen werden. Falls die Schätzung zu optimistisch war, werden User Stories, die bis zum Sprintende zeitlich nicht mehr umgesetzt werden können, wieder ins Product Backlog verschoben. Dadurch wird gewährleistet, dass zum Sprintende eine funktionsfähige Version vorliegt, deren Funktionsumfang allerdings von der ursprünglichen Planung abweichen kann.
Vom Status Backlog zur Implementierung
User Stories sind daher in sich abgeschlossene Produkt-Features und haben im Idealfall keine unmittelbaren Abhängigkeiten untereinander. In der CRM-Produktentwicklung bei itdesign werden User Stories in CAS genesisWorld über einen eigenen Datensatz-Typ Anforderung abgebildet, die zugehörige Bearbeitungsmaske wurde über das CAS genesisWorld-Modul Form Designer gestaltet. Die User Stories werden vom Produktmanagement formuliert und im System gepflegt. Von den Anforderungen gibt es eine bewertete 1:n-Verknüpfung mit Aufgaben, den Entwicklungs-Tasks. Die User Stories sowie die zugehörigen Aufgaben haben anfangs den Status Backlog. Um eine User Story dem aktuellen Entwicklungs-Sprint, der in CAS genesisWorld als Vorgang abgebildet ist, zuzuordnen, wird eine bewertete Verknüpfung von der Anforderung zum Sprint gesetzt und die Entwicklungs-Aufgaben primär mit dem Sprint verknüpft, der Status ändert sich dabei auf Implementierung. Hat der Entwickler die Aufgaben zu einer User Story umgesetzt, wird der geänderte Code in der Quellcode-Verwaltung gespeichert, eine neue Build-Version erstellt und in CAS genesisWorld eine Verknüpfung der Aufgaben mit der Revisions-Nummer des Quellcode-Standes angelegt. Die umgesetzten Entwicklungs-Aufgaben erhalten automatisch den Status Testing. Nach erfolgreichem Test werden die Aufgaben auf Erledigt gesetzt und die Anforderung erhält den Status Implementiert.
Durchgängige Transparenz
Diese Vorgehensweise gewährleistet eine durchgängige Transparenz von der fachlichen Anforderung (User Story), über die technische Spezifikation (Entwicklungs-Aufgabe) bis hin zur zugehörigen Änderung im Quellcode. Das heißt, in CAS genesisWorld ist für jeden Beteiligten einfach nachvollziehbar, wer wann welche Anforderung spezifiziert hat, wann diese durch wen in welchem Build umgesetzt und getestet wurde, welche Änderungen im Quellcode dazu erforderlich waren und in welcher Version die Anforderung letztlich freigegeben wurde.
