Eine der großen Herausforderungen bei agiler Softwareentwicklung ist der Umgang mit Anforderungen. In der Theorie ist alles ganz einfach: die Anforderungen werden als UserStories definiert. Jede UserStory beschreibt ein Stück Software-Inkrement das auslieferbar ist und einen Kundennutzen erfüllt. Das Inkrement muss ein funktionierendes Stück Software sein, dass der Anwender “benutzen” kann. Abbildung 1 zeigt die Schematische Struktur in einer 3-Tier-Architektur.

Abbildung 1: Erstellen von Software in Inkrementen

Warum fällt es dann in der Praxis den meisten Entwicklern so schwer Inkremente für UserStories zu liefern? Schauen wir uns erst mal an, wie in den meisten Projekten Anforderungen in das “Backlog” gelangen.

In den meisten Projekten schreibt als erstes ein Mitarbeiter einer Fachabteilung ein “Lastenheft” (oder eine User Requirements Specification). Dieser Mitarbeiter ist in der Regel nicht geschult Anforderungen zu definieren. Er schaut also erst mal bei Google und sucht nach “Lastenheft” (oder URS / SRS). Dort findet er als erstes den Aufbau und damit die Unterteilung in funktionale und nichtfunktionale Anforderungen. Funktionale Anforderungen beschreiben, was die Software “tun soll” – nichtfunktionale, was die Software für Eigenschaften haben soll. Diese Unterteilung ist leider sehr “künstlich” und fällt den meisten Menschen (auch geübten Architekten) i.d.R. eher schwer. Deshalb bleibt es bei den nichtfunktionalen Anforderungen i.d.R. bei Sicherheit, Performance und Skalierbarkeit (siehe Abbildung 2).

Abbildung 2: Funktionale und nichtfunktionale Anforderungen

Außerdem schreiben solche Anwender die Anforderungen meistens schon viel zu technisch – aber dieses Thema sprengt den Rahmen des Artikels. Aus dem Lastenheft erstellt jetzt ein Dienstleister mit technischem Hintergrund ein Pflichtenheft, eine Feinspezifikation oder auch schon das Backlog. Egal welche Form – es werden die Anforderungen mit technischen Implementierungen angereichert. Die Gliederung richtet sich dabei nach dem Lastenheft (um nichts zu vergessen) oder nach einem logischen Aufbau (Grundfunktionalitäten, Datenstrukturen etc.). Meistens werden alle Pflichten als “funktionale” Anforderungen definiert. Das Ergebnis könnte wie in Abbildung 3 aussehen.

Abbildung 3: “Falsche” funktionale Anforderungen

Das Problem ist jetzt, wenn versucht wird diese Anforderungen agil umzusetzen. Was entwickle ich in der UserStory für Rollenkonzept? Was in der für Authentifizierung? Welche muss ich zuerst machen? Und Ruckzuck bin ich wieder bei der Wasserfallplanung für das Projekt…

Das Problem ist, dass der Kundennutzen völlig unter den Tisch gefallen ist. Interessiert den Kunden den ein Rollenkonzept? Absolut nicht! Das Rollenkonzept interessiert nur den Entwickler. Den Kunden interessiert mich zum Beispiel folgendes:

“Als Mitarbeiter in der Entwicklung
Möchte ich, dass nur Mitarbeiter mit einer Sicherheitsklassifizierung-A meine Forschungsberichte einsehen kann,
Da es für das Unternehmen fatal wäre, wenn die Dokumente in die Hände der Konkurrenz gelangen würden.”

Die ist eine UserStory mit einem klaren “Nutzen”. Bestimmte Dokumente dürfen nur von bestimmten Personen eingesehen werden. Natürlich bedingt das einer Art Rollenkonzept – aber die Gesamtheit spielt erst mal keine Rolle. Das gesamte Rollenkonzept wird also auch erst am Ende der Entwicklung fertig definiert sein.

Die Unterteilung in funktionale und nichtfunktionale Anforderungen scheint also im agilen Umfeld nicht nützlich. Es ist also Besser eine Unterteilung in Nutzen und Querschnittsfunktionen (Abbildung 4) vorzunehmen. Zu den Querschnittsfunktionen gehören:

• Alle nichtfunktionalen Anforderungen
• Alle technischen Konzepte (Logging, Authentifizierung…)
• Alle Basisfunktionalitäten (Datenstrukturen, Dateiformate…)

Abbildung 4: Nutzen und Querschnittsfunktionen

Was macht denn jetzt also eine UserStory aus?

1. Eine UserStory ist in der Sprache des Anwenders geschrieben. Technische Termini sind also ein starkes Indiz dafür, dass mit der UserStory etwas nicht stimmt.
2. Eine UserStory sollte kurz und prägnant formuliert sein.
3. Eine UserStory erzählt einen Anwendungsfall aus Sicht eines Anwenders. Die Rolle muss also eine Rolle der Unternehmung sein – nicht eine Rolle des Rollenkonzeptes der Anwendung. Die Rolle “Administrator” darf also genau genommen nur in Software für den IT-Betrieb vorkommen – nicht aber in einer Software für das Marketing. Da gibt es nämlich keine Administratoren.
4. Eine UserStory beschreibt einen Kundennutzen; d.h. einen Nutzen für das Unternehmen. Idealerweise lässt sich der Nutzen direkt in einen ROI umrechnen – das ist aber leider nur selten möglich. “Damit der Anwender Zeit spart” ist also durchaus ein echter Nutzen für fas Unternehmen.
5. Eine UserStory muss für sich implementiert werden können und darf keine Abhängigkeiten zu anderen UserStories haben.

Damit UserStories strukturiert werden können, kann man sie in Themen und Epen einteilen (Abbildung 5). Dies soll aber nicht dazu dienen, dass man eine Reihenfolge und damit funktionale Abhängigkeiten abbildet. Die Strukturierung soll dem Kunden helfen seine UserStories in einem Kontext zu begreifen. Für die Auswahl der UserStories sollten die Themen und Epen keine Rolle spielen – da sollten nur der Nutzen und das Risiko eine Rolle spielen.

 

Abbildung 5: Strukturierung von UserStories

Die Umsetzung von UserStories ist eh nicht leicht und bedarf – besonders am Anfang, wenn noch keine Plattform existiert – ein hohes Maß an Kreativität. Sind die UserStories aber falsch definiert, dann ist es fast unmöglich. Es ist also extrem wichtig, die UserStories sauber zu definieren und bei der Umsetzung einen starken Fokus auf den Nutzen für den Kunden zu legen. Dann kristallisieren sich die wichtigen Aspekte am einfachsten heraus und die Umsetzung eines “Inkrementes” geht einem leicht von der Hand.