Elefanten sind keine Giraffen, und User Stories sind keine Anforderungen. Sie haben gemeinsame Merkmale und einen gemeinsamen Kontext, aber dies entspricht ihnen nicht. Viele glauben jedoch, dass User Stories eine Art neue Lektüre der sogenannten Softwareanforderungen sind - schließlich müssen Anforderungen an ein Projekt gestellt werden, oder? Also werde ich antworten - nein und wieder nein . Erstens sind dies keine Anforderungen, und zweitens sind Anforderungen nicht das, was wir wirklich brauchen. User Stories bieten in erster Linie die Möglichkeit, verschiedene Implementierungsoptionen zu sehen, damit Sie die sich bietenden Möglichkeiten nutzen können. Und die Anforderungen ... es ist, alles im Voraus zu lösen, damit Sie später darin stecken bleiben.
Hat es Sinn, einen solchen Artikel zu schreiben? Scheint das nicht offensichtlich? Nein, ich glaube, dass die häufigen Aussagen wie „Anforderungen im Rückstand“ signalisieren, dass das Paradigma des Denkens dasselbe bleibt, nur die Zeichen haben sich geändert. Das Anforderungsdokument wurde als Backlog bezeichnet, die Anforderungen selbst - User Stories, und jetzt sind wir "agil" ...
Ein weiteres Zeichen für ein mögliches Missverständnis ist die weit verbreitete Praxis, User Stories in der Datenbank mit der Zuweisung einer eindeutigen ID zu speichern. Es ist möglich, dass dies nur der Einfachheit halber geschieht, aber es ist möglich, dass dies das Ergebnis einer anhaltenden Tendenz ist, in Bezug auf Anforderungen zu denken.
Die Praxis, User Stories in einen Vertrag aufzunehmen, ist jedoch bereits ein 100% iges Zeichen dafür, dass User Stories als Anforderungen betrachtet werden. Das Problem hierbei ist, dass eine User Story per Definition nicht so eindeutig sein kann wie eine Anforderung, und dies entwertet den Vertrag. Natürlich können Anforderungen manchmal auch ziemlich frei interpretiert werden, aber die Technik, sie zu schreiben, impliziert zunächst die Beseitigung von Mehrdeutigkeiten, die nicht über User Stories gesagt werden können. Darüber hinaus sind Anforderungen widerstandsfähig gegen Änderungen, da sie in Projektverträgen enthalten sind. Um neue Anforderungen zu ändern oder hinzuzufügen, müssen sie durch das CCB geleitet werden . Mit anderen Worten, die Stakeholder müssen zuerst zustimmen und zustimmen. Weitere Einzelheiten zu Verträgen finden Sie weiter unten.
Was sind User Stories? Betrachten Sie sie als Planungswerkzeug. Mit Hilfe von User Stories priorisieren, bewerten und entscheiden wir, in welchem Sprint die entsprechende Funktionalität implementiert wird. Dies sind alles typische Merkmale eines Planungswerkzeugs. Versuchen Sie also nicht, sie in etwas anderes umzuwandeln.
Die Kraft von User Stories besteht darin, dass sie zum Dialog führen. Anstatt nur eine Spezifikation zu übernehmen und an Kollegen weiterzugeben, die zuerst von den Entwicklern und dann von den Testern interpretiert wird, beginnen wir eine Diskussion. Wir schließen Mitarbeiter mit unterschiedlichen Kommunikationsfähigkeiten ein. Und so - für jede neue Funktion.
Da die User Story als solche nicht viel Bedeutung hat, können wir sie nach der Implementierung der entsprechenden Funktionalität einfach verwerfen. Wenn Sie möchten, können Sie sorgfältig Statistiken über die Anzahl der verkauften Artikel führen. Dies ist jedoch durchaus möglich und begrenzt.
Es stellt sich heraus, dass wir keine Anforderungen brauchen? In der Tat ist dies nicht wahr. Schließlich gibt es auf die eine oder andere Weise Einschränkungen. Beispielsweise müssen medizinische Geräte den FDA-Vorschriften entsprechen . Nennen wir sie dann Einschränkungen!
Und doch beschreiben die Anforderungen das System im Detail. Vielleicht hat eine solche Beschreibung für uns einen gewissen Wert? Wie können wir beispielsweise feststellen, ob ein Verhalten des Systems ein Fehler ist oder nicht, wenn in der einen oder anderen Form keine formalen Anforderungen vorliegen? Die Technik "Spezifikation durch Beispiel" wird uns hier helfen. Daher wurde beschlossen, einige Funktionen zu implementieren. Sie schreiben Geschäftsregeln und eine Reihe von Beispielen so, dass sie: a) leicht zu lesen sind; b) realisierbar. Aus dieser Beschreibung sollte klar sein, was das System tun soll. Und auch, wenn aufgrund von Änderungen etwas schief geht - die Verletzung der Geschäftsregeln war die Ursache für diese Funktionsstörung.
Wie ich bereits geschrieben habe, sollte die Beschreibung des Fehlers einfach und klar sein. Fehler sind informationszerstörende Dinge und sie sind schlecht, unabhängig davon, ob wir eine Anforderungsbeschreibung haben, die einen bestimmten Fall abdeckt oder nicht.
Vertrag
(von Matthias Skarin)
Was werden wir also anstelle der Anforderungsspezifikation verwenden? Schließlich müssen wir verstehen, ob wir genau das implementiert haben, was benötigt wurde. Wir werden agile Verträge verwenden. Agile Verträge bieten die Möglichkeit, den Wald vor lauter Bäumen zu sehen. Sie ermöglichen es Ihnen, sich auf das Wesentliche des Projekts und die gemeinsame Erreichung des Ziels zu konzentrieren, dessen Umsetzung den Bedürfnissen der Benutzer gerecht wird.
Denken Sie daran, wenn Sie während des Projekts über den Vertrag nachdenken, um zu überprüfen, ob Ihr Partner gegen etwas verstoßen hat, bedeutet dies bereits, dass etwas schief geht. Der Vertrag muss Vertrauen zwischen den Parteien aufbauen, damit es möglich wird, über die Details hinauszugehen und sich nicht in ihnen festzumachen.
Zusammenfassung
- Trotz der Tatsache, dass sowohl der Elefant als auch die Giraffe vier Beine haben, sind sie verschiedene Tiere.
- User Stories sind keine Anforderungen, sondern ein Planungswerkzeug.
- Das, was den Anforderungen am nächsten kommt, ist die Spezifikation anhand eines Beispiels.