Betrachten wir eine einfache Geschichte für einen Benutzerauthentifizierungsbildschirm:
Als Benutzer
möchte ich mich mit meinem Benutzernamen und Passwort anmelden können,
damit ich xyz machen kann.
Das sieht gut aus, aber alle Details dazu, was passieren soll, wenn das Passwort falsch ist, wie viele Wiederholungen zulässig sein sollten, Validierungen und eine Reihe anderer Dinge, die zu dieser Geschichte gehören sollten, fehlen.
Wo sollten all diese Informationen in einem agilen Scrum-Setup hinkommen? Handelt es sich um einen FRS (oder ein anderes gleichwertiges monolithisches Dokument, das Einzelheiten zu allen Funktionsspezifikationen enthält)? Wenn ja, da es Hunderte oder Tausende dieser winzigen Geschichten geben wird, wie sollten Verweise auf die entsprechenden FRS-Abschnitte miteinander synchronisiert werden? Wie kann man diesen Detaillierungsgrad in einer agilen Scrum-Welt am besten verwalten?
Sie haben im Grunde den Zweck von User Stories getroffen. Sie sehen, User Stories entstanden, als wir umfangreiche Anforderungsdokumente hatten, die alle Details enthielten, die das Entwicklerteam möglicherweise für die Entwicklung der Software benötigen könnte. Das Problem dabei ist, dass die Dokumentation dieser Details viel Zeit in Anspruch nimmt, und es stellt sich heraus, dass sie oft nicht das sind, was der Benutzer möchte (oder zumindest das Ziel verfehlt). Jetzt ist die ganze Zeit verschwendet. Stattdessen schreiben wir eine User Story, die uns gerade genug Informationen gibt, um mit der Person, die sie geschrieben hat, ins Gespräch zu kommen. Das Entwicklerteam kann Fragen stellen und seine Bedürfnisse besser verstehen und dann etwas entwickeln, das seinen Anforderungen entspricht. Sie werden ihre Notizen irgendwo schreiben und je nach Ihrer Anwendung kann es sogar sinnvoll sein, dass diese an einem ganz bestimmten Ort gespeichert werden. So, Der Zweck von User Stories bestand darin, von monolithischen Dokumenten wegzukommen und zu persönlichen Gesprächen überzugehen. Wenn Sie eine User Story mit Details in einem umfangreichen Anforderungsdokument verknüpfen, haben Sie den Wert von User Storys eliminiert.
Die kurze Antwort ist, dass Sie es nicht tun. Umfangreiche Planung im Voraus ist orthogonal zur agilen Entwicklung. Stattdessen sollten Sie sich auf iterative und inkrementelle Entwicklung mit engen Feedback-Schleifen konzentrieren, um sicherzustellen, dass Sie die richtigen Dinge entwickeln und Veränderungen während des gesamten Lebenszyklus des Projekts annehmen.
Das Erfüllen detaillierter oder umfangreicher Anforderungen zu Beginn eines Projekts ist ein agiles Anti-Pattern. Das Manifest für agile Softwareentwicklung wertet insbesondere Folgendes aus:
Funktionierende Software über umfassende Dokumentation[.]
Ebenso vermeidet die Scrum-Theorie ausdrücklich die Verwendung einer festen Vorausplanung:
Scrum verwendet einen iterativen, inkrementellen Ansatz, um die Vorhersagbarkeit zu optimieren und das Risiko zu kontrollieren.
Auch wenn Sie nichts davon abhält, User Storys oder andere Arten von Product Backlog Items mit funktionalen Anforderungen zu verknüpfen, ist dies oft ein „Projektgeruch“, den Sie festlegen, der Umfang, der idealerweise der bewegliche Teil des Eisernen Dreiecks in Scrum ist. Darüber hinaus ist es oft ein Hinweis darauf, dass Sie Implementierungsentscheidungen zu früh im Prozess treffen. Lean-Praktiken erfordern, dass Sie Architektur- und Designentscheidungen im letzten verantwortlichen Moment treffen , was fast nie ganz am Anfang eines Projekts ist, wenn normalerweise funktionale Anforderungsspezifikationen gesammelt werden.
Innerhalb des Scrum-Frameworks sollten Sie das Framework nutzen, um eine Just-in-Time-Planung mit der richtigen Granularitätsebene durchzuführen. Insbesondere:
Obwohl Scrum dies nicht erfordert, erfordern agile Praktiken im Allgemeinen die Integration von testgetriebenem Design oder verhaltensgetriebener Entwicklung (häufig in Zusammenarbeit mit Stakeholdern oder Kunden), um sicherzustellen, dass alle funktionalen Anforderungen im Umfang für die aktuelle Iteration klar definiert und testbar sind . Diese Art der „lebenden Dokumentation“ ist oft nützlicher, genauer, wartbarer und effektiver als typische funktionale Anforderungsdokumente.
Ich denke, ein Teil des Problems ist, dass dies:
Melden Sie sich mit meinem Benutzernamen und Passwort an
ist keine Voraussetzung. Es ist eine Designentscheidung, die sich als Anforderung tarnt. Die eigentliche Anforderung lautet etwa: "Als Benutzer muss ich mich (sicher und eindeutig) beim System authentifizieren, damit ich ..." Die Wahl von Benutzername und Passwort schließt sofort andere, weniger reibungslose Authentifizierungsmethoden aus. Sie sind bereits bei Active Directory/G Suite/Office 365/einem anderen OAuth-Anbieter angemeldet? Können wir das verwenden? Was ist mit Gesichtserkennung und Fingerabdruck? Ist das ausreichend?
Denken Sie daran, wenn Sie Ihre User Stories durchgehen. Sagen sie Ihnen, wie etwas getan werden sollte, anstatt was getan werden muss? Sehr oft ist das in Ordnung; Sie erweitern/klären frühere Designentscheidungen. Aber manchmal lohnt es sich, einen Schritt zurückzutreten und sich zu fragen, welches Problem sie wirklich lösen, und gibt es einen besseren Weg?
Wie von anderen gesagt, sollten Details im letzten verantwortlichen Moment geklärt werden, manchmal im Moment der Implementierung in enger Zusammenarbeit zwischen Entwicklern und zB Geschäftsleuten oder UX-Experten. Als Akzeptanzkriterien können jedoch bestimmte Informationen angegeben werden. Allgemeinere und sich wiederholende Kriterien können besser in die Definition von „Fertig“ des Teams (oder der Organisation) eingeordnet werden.
Für Akzeptanzkriterien sollten Sie sich vielleicht auch eine Syntax wie Gherkin ansehen – und vielleicht möchten Sie das Testen mit Dingen wie Cucumber als lebendige, wertschöpfendere Dokumentation und Basis für Regressionstests automatisieren.
„Wie viele Wiederholungen sollten erlaubt sein, Validierungen und ein Haufen anderer Dinge, die zu dieser Geschichte gehören sollten, fehlen. Wohin sollten all diese Informationen in einem agilen Scrum-Setup gehen?“
Deshalb gibt es Akzeptanzkriterien .
Aber es scheint mir, dass Sie ein anderes Problem haben: Wer hat Ihren FRS geschrieben? Warum haben Sie diese Investition getätigt, wenn Sie wussten, dass es sich um ein agiles Projekt handelt? Im agilen Team entscheidet über technische Details. Wenn Sie das agile Manifest sorgfältig lesen, werden Sie sehen, dass es Entwickler sind, die zur Revolution aufrufen.
Todd A. Jacobs