Wie kann ich mein Team davon überzeugen, dass eine Anforderungsspezifikation nicht erforderlich ist, wenn wir User Stories übernehmen?

9

Wir planen, User-Stories zu verwenden, um die Absicht der Stakeholder auf eine leichte Art und Weise zu erfassen, anstatt eine schwere SRS (Software Requirements Specifications). Es scheint jedoch, dass sie, obwohl sie den Wert von Geschichten verstehen, immer noch den Wunsch haben, die Geschichten in eine SRS-ähnliche Sprache mit allen Attributen, Prioritäten, Eingaben, Ausgaben, Quellen, Zielen usw. umzuwandeln.

User-Storys "eliminieren" zunächst die Notwendigkeit eines formalen SRS-ähnlichen Artefakts. Was bringt es also, ein SRS zu haben? Wie kann ich mein Team (das übrigens alle sehr qualifizierte CS-Mitarbeiter sind - sowohl in Bezug auf Ausbildung als auch in Bezug auf die Praxis) davon überzeugen, dass der SRS "eliminiert" wird, wenn wir User Stories zur Erfassung der funktionalen Anforderungen des Systems übernehmen? (NFRs usw. können ebenfalls erfasst werden, aber das ist nicht die Absicht der Frage).

Hier ist mein 'Workflow'-Argument: Erfassen Sie anfängliche Anforderungen als User-Storys und arbeiten Sie sie später zu Anwendungsfällen aus (die auf niedriger Ebene dokumentiert werden müssen, dh Interaktionen mit den UI-Prototypen / -Modellen beschreiben und ein zu liefernder Beitrag sind Einsatz). Gehen Sie also von User-Stories zu Use-Cases und nicht von User-Stories zu SRS zu Use-Cases.

Wie erfassen Sie derzeit alle User Stories an Ihrem Arbeitsplatz (wenn überhaupt) und wie schlagen Sie vor, dass ich das Fehlen von SRS in Gegenwart von User Stories begründe?

agile requirements user-story requirements-management PhD
quelle
es wird nicht an einem Tag passieren, gehen Sie einfach vor
Yusubov
Wenn Sie für einen Softwaredienstanbieter arbeiten, wird der SRS möglicherweise nicht für die Implementierung benötigt, sondern für das "Schuldspiel", wenn der Kunde die Kosten senken möchte oder die Argumente des Dienstanbieters, dass mehr Geld benötigt wird oder beide vor Gericht gehen.
k3b

Antworten:

14

Kleine Schritte. Schreiben Sie den SRS noch eine Weile weiter. Rufen Sie dann eine Besprechung an und besprechen Sie, ob sie noch einen Zweck erfüllen. Liest sie noch jemand? Ist die für sie aufgewendete Zeit gerechtfertigt? Gibt es einen weiteren Zwischenschritt, der leichter wäre?

Sie wissen nie, Sie könnten feststellen, dass Sie falsch liegen. Denken Sie an das Agile-Manifest, wir finden mehr Wert in "Arbeitssoftware über umfassende Dokumentation", aber in letzterem steckt immer noch Wert.

Ich vermute jedoch, dass Sie schnell feststellen werden, dass der Wunsch, weiterhin schwere Dokumente zu schreiben, nachlässt, wenn sie sehen, wie eng Anwendungsfälle und User Stories zusammenhängen.

pdr
quelle
2
@PhD: Du hast recht. Es ist fast ursprünglich. Und deshalb wirst du diesen Kampf nicht mit irgendeiner Logik gewinnen, nur mit Beweisen. Kleine Schritte.
pdr
2
Ich habe für Manager gearbeitet, die Veränderungen mit kleinen Schritten konfrontiert haben. Es war ihr Codewort für "Nur genug tun, um zu scheitern, damit ich sagen kann, dass ich Recht hatte". Dies ist kein Weg zum Erfolg, da es ein grundlegendes Unverständnis der neuen Methodik zeigt und ein Mangel an vollständigem Buy-in durch das Management, was für eine erfolgreiche Veränderung entscheidend ist. Das hört sich theoretisch gut an, aber in der Praxis ist es eine Ausrede, sich nicht zu ändern und den Sieg zu erringen, dass der neue Weg nicht funktioniert und der alte Weg. Auf diese Weise wurde die SRS verstärkt und die Geschichten werden als zusätzliche Arbeit gekennzeichnet, und Sie kehren dorthin zurück, wo Sie waren.
2
Meine Erfahrung ist nicht einzigartig, sondern über 22 Jahre in der Branche, von denen die meisten Beratung waren. Daher habe ich in der gleichen Zeit mit viel mehr Managern und Entscheidungsträgern als die meisten Menschen zusammengearbeitet. Mein Punkt ist, dass dieser Baby-Step- Ansatz ein Misserfolgsansatz ist. Nur das Engagement des oberen Managements für die Änderung und die Philosophie hinter der Änderung werden zu einer erfolgreichen Implementierung führen. Wenn seine Kollegen nicht überzeugt sind und sie weiterhin tun lassen, was sie wollen, werden sie nicht überzeugt. Das nährt nur, dass wir immer noch den alten Weg brauchen, und der neue Weg ist Zeitverschwendung.
1
@JarrodRoberson Ich möchte nur hinzufügen, dass meine Erfahrungen Ihre besser widerspiegeln. Es gibt zwei Arten von Menschen und somit zwei Arten von Managern, Konservative und Risikoträger. Konservative sind natürlich abgeneigt gegenüber Veränderungen und Risiken. Wenn sie ein Modell finden, das auch schlecht funktioniert, bleiben sie dabei. Wenn ihnen Veränderungen aufgezwungen oder aufgezwungen werden, sabotieren sie sie unbewusst, indem sie versuchen , kleine Schritte zu unternehmen . Aus diesem Grund habe ich nur dann echte agile Adoptionsarbeit gesehen, wenn sie von Risikoträgern geleitet wird.
maple_shaft
2
@maple_shaft: Der Trick besteht darin, sich weiter vorwärts zu bewegen. Wenn eine inkrementelle Änderung nicht funktioniert, machen Sie nicht unbedingt den gleichen Schritt zurück. Überlegen Sie, warum sie nicht funktioniert hat. Vielleicht verbringen Sie noch zu viel Zeit damit, ein jetzt sinnloses Dokument zu schreiben. Jetzt werde ich zugeben, dass es eines guten Managers bedarf, um so zu denken, und dass die meisten in ihre Komfortzone zurückkehren werden. Aus genau dem gleichen Grund bedeutet dies jedoch nicht, dass die einzige andere Option eine drastische Änderung ist. Ein schlechter Manager wird es verdorren.
pdr
6

Epen sind Platzhalter

In nahezu jeder agilen Methodik würde das Konzept von Epics so viel sein, wie Sie für eine Anforderungsspezifikation benötigen sollten. Platzhalter sind genau das, was Sie auf dieser Ebene benötigen. Diese Einträge werden ständig priorisiert. Weitere Details werden verschwendet, wenn die Anforderung für längere Zeit eine niedrige Priorität erhält oder nicht einmal implementiert wird. Die Dokumentation und Verwaltung der Dokumentation wäre reine Zeitverschwendung. YAGNI erstreckt sich sowohl auf Anforderungsaktivitäten als auch auf Codierungsaktivitäten.

Werkzeuge sind dein Freund!

Wenn Sie zum Sammeln und Verwalten der User Storys ein geeignetes Tool verwenden, können Sie daraus die Anforderungsspezifikation generieren. Eine Anforderungsspezifikation ist sowieso ein zeitliches Artefaktdokument , es ist kein lebendes Dokument, es ist eine Momentaufnahme der Anforderungen in der Zeit. Und ist nie mit der Realität synchron.

Artefakte automatisch generieren

User Stories, die aus einem geeigneten Tool exportiert werden können, sind zu jeder Zeit weitaus wertvoller als jedes statische Artefaktdokument. Persönlich bevorzuge ich Pivotal Tracker , um User Stories zu verfolgen. Ich habe sogar eine Reihe von MoinMoin-Plugins in Python geschrieben, um alle verschiedenen Stories und ihre Status im Wiki zu veröffentlichen (die detaillierte Entwicklernotizen und ähnliches zu den Storys enthielten). Live-Daten sind immer verfügbar besser als statische Daten.

Das Wiki wurde zu einem Live-Dokument aller Geschäfte / Anforderungen sowie deren Fertigstellungs- und Prioritätsstatus mit Details und Kommentaren sowie anderen Metadaten.

Viel besser als ein riesiges Word-Dokument in Sharepoint, das ständig per E-Mail verschickt und nie aktualisiert wird. Dies garantiert, dass jeder eine andere Version hat und nicht mit allen anderen synchron ist!

User Stories sind umfangreicher als Use Cases

Die Use Story ist viel wertvoller als ein Use Case, weil sie WARUM sagt .

Das User Story-Format: As a [ROLE] I [ACTIVITY] so that [WHY]ist viel aussagekräftiger als ähnliche Anwendungsfälle The System [shall/shall not/may/must] perform [action](bei denen Aktion ein Flussdiagramm ist).

Mit einer User Story haben Sie die WHO , die etwas tun möchte, Sie haben WAS sie tun möchten (was auf ein detaillierteres Diagramm / Dokument für komplexe Aufgaben verweisen kann) und Sie haben den wichtigsten Teil, WARUM sie diese Aktivität ausführen möchten.

Wenn Sie die erste haben, ist die zweite völlig redundant und bestenfalls nur Rauschen. Eine traditionelle formale Anforderungsspezifikation aus einer Wasserfallmethode hat in einer agilen Umgebung keinen Platz.

Schlussendlich

Wenn sich Ihr Management nicht zu Änderungen verpflichtet hat, werden Sie mit einer neuen Methodik keinen Erfolg haben. Ich habe für ein Unternehmen mit mehr als 100 Milliarden Dollar pro Jahr gearbeitet, sie haben keine kleinen Schritte unternommen , um zu Agile / SCRUM zu wechseln. Sie sagten nur, das gesamte Unternehmen bewegt sich dahin, hier ist die neue Art, Dinge zu tun, hier ist Wenn Ihr Training für den neuen Weg beginnt, finden Sie hier die neuen Tools, die wir verwenden werden. Hier ist das Datum, an dem wir beginnen, die Dinge auf diese Weise zu tun. Es hat für sie in weniger als einem Jahr funktioniert. Ich habe mit dem gleichen Erfolg daran gearbeitet, dies in kleineren Unternehmen umzusetzen.

Engagement

Baby-Step- Implementierungen sind unabhängig von der Änderung ein Rezept für einen Misserfolg. Es ist ein Codewort für das Management, dem sie stillschweigend nicht zustimmen und das Sie passiv aggressiv auf einen Misserfolg vorbereitet. Sie sagen, ich glaube nicht genug daran, um mich dazu zu verpflichten, also werde ich Sie gerade genug tun lassen, um zu scheitern / nicht erfolgreich zu sein . Auf diese Weise können sie sagen, dass sie es versucht haben und es nicht funktioniert hat und wie sie es geschafft haben ganz gut die ganze Zeit. Teilweises Engagement führt letztendlich zum Scheitern.

In Ihrem Fall glauben sie wahrscheinlich stillschweigend nicht an die User Stories, und nach einer Weile, wenn sie beides tun, werden sie behaupten, dass es die User Stories sind, die nutzlos sind und nicht die SRS, und werden versuchen, das Schreiben der User Stories zu beenden , was Sie nur rückwärts und nicht vorwärts führt.

kmote
quelle
Sie werden ziemlich überrascht sein, dass die User Stories von einem Tool verwaltet werden, das sie als Anforderungen exportieren kann (und tut). Es scheint jedoch die Sorge zu sein, die User-Storys in die SRS-Sprache von "Das System soll ..." usw. zu "übersetzen" und sie NICHT als User-Storys zu belassen.
PhD
1
Nun, wenn das Auflegen die Termanologie "soll / muss / darf" ist, spucken Sie wahrscheinlich mit diesen Leuten in den Wind. User Stories erzählen, WER / WAS und vor allem WARUM etwas getan werden muss, viel nützlicher als die statischen Anwendungsfälle, die in den meisten Fällen falscher und korrekter sind.
2
-1: Mit den meisten Antworten überhaupt nicht einverstanden zu sein, jedoch zu sagen, dass und SRS "Eine Anforderungsspezifikation ist sowieso ein zeitliches Artefaktdokument, es ist kein lebendes Dokument" ist, ist so falsch, dass ein beunruhigender Mangel an Verständnis zeigt, was Ein SRS ist für oder wie es verwendet wird, wenn es richtig gemacht wird - normalerweise nur in älteren Wasserfallmodell-Softwarehäusern heutzutage.
Mattnz
5
Ein SRS ist ein totes Dokument, sobald es veröffentlicht wird. Ich habe sie seit 1990 geschrieben. Sie sind wie ein Kriegsplan, sie überleben den ersten Kontakt nie. Und sie halten nie mit der tatsächlichen Implementierung Schritt, es sei denn, Sie haben ein engagiertes Team von Autoren, die das Ding ständig bearbeiten, und selbst dann ist es falsch, weil die ständige Veränderung und die Entwickler, die dem Dokument immer voraus sind, nicht immer Teilen Sie dem Dokumentbesitzer mit, was gerade passiert. Unternehmen verbringen Tausende von Stunden damit, solche Dinge zu schreiben, und die Dokumente werden in ein Regal gestellt und verrotten, während die Entwicklung beginnt.
3
@JarrodRoberson +1 für Sie. In der Tat hat mattnz auch Recht, dass der SRS ein lebendiges Dokument sein soll, aber dann nehmen Sie ein paar kritische Produktionsprobleme, die vom Kunden geändert werden müssen, während Sie an einer oder mehreren verzweigten Versionen der Codebasis arbeiten, die von falsch interpretiert werden Die Geschäftsanalysten, die Entwickler und die Qualitätssicherung ... was Ihnen übrig bleibt, ist ein Dokument, das derzeit keine echte Widerspiegelung des Systems darstellt, aber auch keine wirkliche Widerspiegelung der Benutzeranforderungen. User Stories werden wirklich von Unternehmen übernommen, die sich mehr mit dem Kunden als mit dem System befassen.
maple_shaft
0

Ich würde versuchen, Humor zu verwenden.

Beginnen Sie mit dem http://www.halfarsedagilemanifesto.org/

Sprechen Sie eine Weile darüber ( Ablenkung )
und darüber, was die darin enthaltenen Konflikte wirklich bedeuten ( offene Diskussion ).
Wenden Sie sich dann nach einer Weile an Ihre Organisation ( Pivot )
und prüfen Sie, ob SRS mit dem neuen Projektaufbau sinnvoll ist .

Dann würde ich (oder vielleicht in einem anderen Treffen) mit einer Diskussion über die Änderung des Ansatzes bezüglich: SRS abschließen und sehen, ob Sie mehr Konsens haben.

Am Ende des Tages sind Sie auch durch das Budget und die Bedienung der Geschäftsleute eingeschränkt, so dass es einen Punkt geben kann, an dem Sie etwas fester in dem sind, was verwendet wird, aber dies hängt wirklich von der Branche, der Unternehmensgröße, den organisatorischen Faktoren und vielen anderen ab andere solche Faktoren.

Michael Durrant
quelle
5
Sei sehr vorsichtig. Funktioniert nur, wenn Ihre Mitarbeiter sehr sicher sind und Sie ein gutes Verhältnis zu ihnen haben. Viele Menschen sind verärgert, wenn Sie ihnen mit Humor sagen, dass sie falsch und versteckt sind.
MarkJ
-1

Die Überzeugung von mgmt, sich vom SRS zu entfernen und User Stories zu verwenden, ist im Wesentlichen dasselbe wie die Überzeugung von mgmt, Agile zu übernehmen. Es gibt überzeugende Statistiken zu den Produktivitätsvorteilen von Agile. Ein Beispiel ist die Präsentation, die VersionOne 2013 auf einer Konferenz hielt. Zeigen Sie mgmt diese Branchendaten an, und wenn es sich um den Hörtyp handelt, haben Sie eine Chance.

Joe
quelle
1
Entschuldigung, das ist keine gute Antwort. Sie sagen "Statistiken anzeigen" und geben nicht einmal Links an.
Jan Doggen
und schreibe vollständige Wörter und Sätze ...
jwenting