Schon seid geraumer Zeit werden vieler Orts User Stories verwendet, um die Anforderungen an ein Produkt mit der Perspektive des Anwenders zu beschreiben. Sie dienen unter Anderem dazu bei den Projektbeteiligten wie Projektleiter, Designern oder Entwicklern mehr Aufmerksamkeit auf den Anwender und den konkreten Mehrwert für diesen zu legen. Daneben gibt es jedoch auch Aufgaben, die dem Nutzer keinen direkten Mehrwert geben oder für die es keine Motivation von Seiten des Nutzers gibt. Ein größeres Refactoring macht manchmal durchaus Sinn, damit die Wartbarkeit der Anwendung gesteigert wird. Dem Nutzer bringt sie jedoch keinen Mehrwert. User Stories in der Form von „Als Anwender möchte ich, dass die Softwarekomponente FileLoader refaktoriert wird, damit die Anwendung besser wartbar ist.“ sind schlichtweg gelogen. Der Anwender will das nicht, denn er kennt die Komponente nicht einmal. Auch die Bereitstellung von Funktionalitäten, die erst die Realisierung normaler User Stories ermöglichen, müssen möglich sein. Vielleicht ist die Refaktorierung notwendig um ein neues Feature überhaupt implementieren zu können. Wie aber kann man das Konzept der Story auch in diesen Situationen nutzen zu können?
Ein Hauptaspekt von User Stories ist, dass ein Mensch in einer Rolle eine Anforderung aus einer Motivation heraus mitbringt. Dies hat den Vorteil, dass, durch die zur User Story gehörende Diskussion, weitere Lösungen und Betrachtungsweisen gefunden werden können. Alle an der Diskussion Beteiligten können sich in die Rolle versetzen und versuchen den Mehrwert der Story nachzuvollziehen. Dies funktioniert auch, wenn es sich bei der Rolle nicht um einen User sondern um einen Entwickler handelt.
Beispiel 1: Als Entwickler möchte ich eine hohe Testabdeckung meines zu überarbeitenden Code haben, damit mir Fehler durch meine Weiterentwicklung früher auffallen.
In dem Beispiel 1 wird die Wartbarkeit gesteigert und damit ein strategischer Mehrwert der Anwendung erzeugt. Davon hat der Anwender nicht direkt etwas, auch wenn er langfristig eine stabilere Software bekommen dürfte.
Beispiel 2: Als Entwickler möchte ich die aktuelle Version von jQuery nutzen können, um von einer höheren Performance und wenigeren Bugs aus der alten Version profitieren zu können.
Bei Beispiel 2 wird eine Systemkomponente ausgetauscht, wodurch der technologische Stand aktualisiert wird. Dem Nutzer entspringt auch hier kein direkter Mehrwert, jedoch werden dadurch neue Entwicklungen möglich, von denen Nutzer anschließend Nutzen ziehen können.
Beispiel 3: Als Entwickler möchte ich auf eine Datenbankabstraktionsschicht zurückgreifen können, die die Datenbank soweit abstrahiert, dass ich mit verschiedenen Datenbanken arbeiten kann ohne mich um Anpassungen kümmern zu müssen.
Im letzten Beispiel wird vielleicht neben MySQL bald auch Oracle unterstützt; ein direkter Nutzen für den Anwender entsteht jedoch nicht unbedingt. Als Anwender einer Webanwendung würde ihm das wahrscheinlich nicht einmal auffallen.
Letztlich lassen sich die ganzen Rollen von Entwicklern zu Designer über Supporter bis hin zum Anwender zu der Menge der Stakeholder zusammen fassen. Dadurch sind alle vom Projekt oder Produkt Betroffenen abgedeckt. Es erscheint sinnvoll, das Konzept und Verständnis von User Stories zu Stakeholder Stories zu erweitern, wobei der Begriff Story wahrscheinlich schon ausreicht um genug Charakterisierung in diese Art der Anforderungsdokumentation zu bringen. Es geht also darum die Vorteile von User Stories auch für technische Aufgaben oder organisatorischen Aufwand zu verwenden.
0 Kommentare