Ich möchte über eine geschäftliche Anforderung des Kunden sprechen. Die Anforderung besteht darin, dem Benutzer die Auswahl einer großen Datenmenge zu ermöglichen. Lassen Sie mich versuchen, es an einem Beispiel zu erklären. Als Portfoliomanager sollte ich in der Lage sein, eine Liste von Modellen aus der Liste auszuwählen, damit ich ein Portfolio erstellen kann.
Hier können über 20000 Modelle auf dem Markt sein. Die Anwendung wird also blockiert, wenn wir dem Benutzer erlauben, beim Erstellen eines Portfolios alle Modelle auszuwählen. Der Kunde verwendet möglicherweise nicht mehr als 10 Modelle, wenn er ein Portfolio in einem realen Szenario erstellt. Es besteht jedoch die Anforderung, alle im System verfügbaren Modelle auszuwählen. Wie soll ich mit diesem Szenario umgehen? Haben Sie alternative Möglichkeiten, um diese Anforderung zu erfüllen?
Ihre aktuelle User Story lautet:
Als Portfoliomanager
sollte ich in der Lage sein, eine Liste von Modellen aus der Liste auszuwählen,
damit ich ein Portfolio erstellen kann.
Einerseits definiert diese Geschichte nicht die Notwendigkeit, alle Modelle auszuwählen, sondern nur „eine Liste“ davon. Wie viele sie auswählen können, bleibt in diesem Fall ein Implementierungsdetail, das zwischen dem Entwicklungsteam und den Endbenutzern ausgehandelt werden sollte. Die Funktion kann dann im Laufe der Zeit verbessert oder verfeinert werden, wenn sich die Anforderungen ändern.
Wenn andererseits die Auswahl aller Modelle eine funktionale Anforderung für das Produkt ist, müssen Ihre Geschichten möglicherweise neu geschrieben werden, um die tatsächlichen Bedürfnisse des Benutzers und die nicht funktionalen Anforderungen zu erfassen, die dies dem aktuellen System auferlegt. Obwohl ich keine Möglichkeit habe, Ihren tatsächlichen Anwendungsfall aus der ursprünglichen Frage zu extrapolieren, betrachten Sie das folgende Beispiel:
Als Portfoliomanager
möchte ich mehr als 2.000 Modelle auf einmal auswählen können,
damit ich komplexe Datenanalysen für exportierte Daten durchführen kann.
Dies ist eine nützlichere Geschichte, da sie ein genaueres Gefühl für die Größe der Auswahl bietet, die der Benutzer wünscht. Es verbessert auch das Original, indem es einen Kontext für die Geschichte bereitstellt, sodass das Team den Aufwand zur Erfüllung des Bedarfs genauer planen und abschätzen kann. Es bietet auch eine Grundlage für die Zusammenarbeit mit Stakeholdern, da es möglicherweise angemessene Kompromisse gibt, die entweder im Anwendungsfall oder in der Implementierung der Funktion eingegangen werden können.
Sobald Sie sicher sind, dass Sie die richtige Geschichte aus der Perspektive des Portfoliomanagers haben, benötigen Sie möglicherweise einige zusätzliche Geschichten, die die technische oder administrative Perspektive erfassen. Dies können funktionale oder nicht funktionale Anforderungen sein, stellen aber in jedem Fall Merkmale des Produkts dar, die wie alle anderen verwaltet werden sollten. Angenommen, dies ist beispielsweise eine Webschnittstelle zu einer typischen Datenbank:
Als Site-Administrator
möchte ich Benutzern ermöglichen, alle Modelle im Datensatz ohne große Leistungseinbußen
zu exportieren , damit komplexe Analysen aus der Anwendung selbst ausgelagert werden können.
Indem Sie ein Thema um diese verwandten Stories herum bilden, können Sie iterativ an den funktionalen und nicht funktionalen Anforderungen über mehr als einen Sprint arbeiten, während Sie die Stories klein und nach INVEST-Kriterien verhandelbar halten .
Am wichtigsten ist, dass Sie es dem Entwicklungsteam ermöglichen, Annahmen zu validieren (z. B. muss ein Benutzer wirklich mehr als 2.000 Modelle innerhalb einer Web-Benutzeroberfläche auswählen?) oder alternative Implementierungen anbieten , indem Sie den richtigen Detaillierungsgrad darüber erfassen, was die Benutzer des Produkts wirklich wollen und warum (z. B. Datenexporte), die einem Laien nicht unbedingt einfallen würden.
Denken Sie immer daran, dass User Stories Gesprächsplatzhalter sind, keine Spezifikationen. Schreiben Sie Benutzergeschichten, um die wesentliche Perspektive und den Kontext jeder Geschichte zu erfassen, und setzen Sie dann der Kreativität des Entwicklungsteams freien Lauf, um an den Implementierungsdetails mitzuarbeiten , damit Sie den Lösungsraum nicht überbeschränken.
Das ist die „geheime Zutat“, die agile Frameworks so effektiv macht: ein aufgeschlossener, kooperativer Ansatz für Crowdsourcing-Lösungen; Optimierung für nicht erledigte Arbeit; und Suche nach der einfachsten Lösung, die den unmittelbaren Bedarf erfüllt , wobei zukünftige Verfeinerungen der Zukunft überlassen bleiben.
Jithin Antony