Man kann nicht nur User Stories haben, irgendwie muss die Funktionalität des Programms dokumentiert werden. Bekommt man mit Scrum ein Lastenheft? Wenn ja, wird die Zeit für die Erstellung dieses Dokuments der Aufgabe zugewiesen?
Ein Beispiel wäre ein komplexer Arbeitsablauf.
Ein anderes Beispiel wäre ein neues Mitglied, das in das Team kommt.
Zu dieser Frage wird es noch viele gute Ideen geben. Meine persönliche Erfahrung hat mich das gelehrt:
1~ Das funktionierende Produkt ist selbst eine Form der Dokumentation: Wenn das Produkt akzeptiert wird, dann ist die Frage, was es unter bestimmten Bedingungen tun sollte, gleichbedeutend mit der Frage, was es unter diesen Bedingungen tatsächlich tut - loggen Sie sich ein und probieren Sie es aus, um Ihre Antwort zu erhalten.
2~ Die Tests, seien sie manuell oder automatisiert (oder eine Mischung), sind eine Form der Dokumentation. Sicherlich können Unit-Tests viel zu weit von der Fachsprache entfernt sein, die von den weniger technisch orientierten Teammitgliedern gesprochen wird (z. B. von den "Business Experts" oder den Kunden). Abnahmetests sind vielleicht eher eine Art "Mittelweg". Auf jeden Fall scheinen BDD-Tests die besten Chancen zu haben, eine allgegenwärtige Sprache zu entwickeln, die jeder verstehen kann (siehe in diesem Zusammenhang Gojkos Überbrückung der Kommunikationslücke ). Nichtsdestotrotz sind alle diese Formen von Tests eine Form der Dokumentation, die dazu verwendet werden kann, zu bestimmen, was das Produkt tun soll.
3~ Je nachdem, wo Ihr Projekt auf dem Spektrum liegt, kann Ihre Dokumentation (und im Allgemeinen alle Ihre zusätzlichen Artefakte) einen höheren oder niedrigeren Grad an Zeremonie erfordern. Kleinere Produkte, kleinere Teams, bei denen die Markteinführung von entscheidender Bedeutung ist, werden feststellen, dass eine sehr formale Dokumentation der Anforderungen im Vergleich zu ihrem Mehrwert viel zu viel kostet. Bei extrem großen Projekten, die sich über mehrere Teams und Jahre der Entwicklung erstrecken, sieht der ROI einer formalen Dokumentation dagegen ganz anders aus.
4~ In einer perfekten Welt bräuchten wir wahrscheinlich keine Anforderungen zu dokumentieren, außer in Form von funktionierendem Code (der im Elfenbeinturm auch selbsterklärend wäre) und Tests (hauptsächlich für Regressionstests und - am Rande - um die Entwicklung neuer Funktionen voranzutreiben). Die Frage der Anforderungsdokumentation ist also eine Frage danach, was der Unterschied zwischen der perfekten Welt/dem Elfenbeinturm und der realen Welt/den Gräben ist. Die Antwort ist natürlich von Fall zu Fall unterschiedlich, je nach Projekt und Team. Wir könnten z. B. sagen: "Alle Anforderungen werden in diesem Wiki festgehalten und mit größter Sorgfalt gepflegt usw. usw...", aber wenn das Team nicht mit Wikis vertraut ist und sich damit nicht auskennt, würde das nicht funktionieren.
5~ Letztlich sind die Betroffenen diejenigen, die Sie fragen sollten. Natürlich sollte das Thema in einer kollaborativen Art und Weise angegangen werden, da jeder im Team während des gesamten Projekts mit den Anforderungen interagieren muss, aber Sie müssen eine Form der Dokumentation finden, die den Bedürfnissen der Stakeholder entspricht.
Abgesehen davon habe ich hier einige Orte gesehen, an denen Anforderungen bei der Anwendung von Scrum dokumentiert wurden (warum habe ich das Gefühl, dass diesem Wort immer ein Sternchen folgen sollte?):
Und um ehrlich zu sein, kann ich nicht sagen, dass ein bestimmtes System eine durchgängig höhere Korrelation mit einem erfolgreichen Projekt aufweist als die anderen. Ich denke, wir haben in der Tat kein Patentrezept.
HTH, danke für den Denkanstoß!
Scrum sagt, dass Sie dokumentieren sollten, was Sie brauchen, wenn Sie es brauchen; es sagt nicht, dass Sie keine Dokumente haben sollten.
Wenn also ein Dokument entweder für das fertige Produkt (z.B. Hilfedokumentation) oder für die Erstellung des fertigen Produkts (z.B. Anforderungsdokumentation) benötigt wird, dann sollte es eine Dokumentationsaufgabe/Benutzergeschichte in Ihrem Product Backlog geben.
Dieser Aufgabe sollte dann eine angemessene Priorität zugewiesen werden.
Für die Dokumentation ist das der wichtigste Punkt;
Sie können nicht nur User Stories haben irgendwie muss die Funktionalität des des Programms dokumentiert werden muss. Haben Sie am Ende ein Lastenheft mit Scrum? Wenn ja, müssen Sie dann der Aufgabe Zeit zuweisen, um dies zu Aufgabe?
Warum kann man nicht einfach User Stories haben? Welchem Zweck dienen diese Spezifikationsdokumente? Welchen Wert hat die Investition in die Erstellung dieser Dokumente? Ist der Nutzen größer als die Kosten? Wenn nicht, ist dann der Zeitaufwand für die Erstellung und vor allem die Pflege dieser Dokumente nicht Verschwendung?
Ich weiß, dass ich mehr Fragen stelle, als dass ich Antworten gebe, aber ich denke, dass Scrum und andere agile Ansätze wie Lean Sie unter anderem dazu zwingen, Ihre derzeitigen Praktiken zu überprüfen und zu sehen, ob sie noch sinnvoll sind.
Wer wird diese Dokumente aktualisieren und pflegen, wenn die Funktion einmal eingeführt ist? In den meisten Unternehmen, in denen ich gearbeitet habe, war die Dokumentation spärlich, veraltet oder es wurde nur selten darauf verwiesen.
Warum nicht stattdessen ausführbare Tests oder BDD verwenden, damit die Dokumentation Teil des Codes wird und ausführbar ist? Zum Beispiel, siehe Ben Mabey's Vortrag über Gurken
Wenn aus irgendeinem Grund eine bestimmte Art von Dokument für die Einhaltung von Gesetzen erforderlich ist, können Sie es jederzeit zur Definition von "erledigt" hinzufügen. Ich habe jedoch festgestellt, dass in den meisten Fällen Stories und Tests als Dokumentation mehr als ausreichend sind.
Vielleicht habe ich die Frage völlig falsch verstanden, aber ich habe es so verstanden, dass der Auftraggeber mit der Diskrepanz zwischen Benutzergeschichten und Anforderungen unzufrieden war. Mit Recht, würde ich sagen.
Meiner Meinung nach beschreiben User Stories, wie ein Teil der Funktionalität dem Product Owner demonstriert werden soll. Die Sprache der Story kann so gewählt werden, dass sie vom Product Owner, aber vor allem von den Entwicklern verstanden werden kann. Sie können Geschichten haben, die Dinge beschreiben, die nicht einmal direkt vom Eigentümer benötigt werden, aber Aufschlüsselungen von Dingen sind, die es sind.
Anforderungen hingegen sind eine detaillierte Spezifikation in der Sprache der Domänenbenutzer darüber, was das System tun muss, um gültig zu sein. In vielen Fällen ist ein Anforderungsdokument nicht optional (z. B. bei Festpreisprojekten).
Was ich mache, ist eine Mischung aus beidem. Ich habe ein Anforderungsdokument und in den meisten meiner Scrum-Stories habe ich etwas in meinen Notizen, das diese Story mit einem oder mehreren Elementen der Anforderungen verknüpft. Es ist so einfach wie "Siehe FR-042 und FR-45" (FR für funktionale Anforderung zum Beispiel)
CodeJaeger ist eine Gemeinschaft für Programmierer, die täglich Hilfe erhalten..
Wir haben viele Inhalte, und Sie können auch Ihre eigenen Fragen stellen oder die Fragen anderer Leute lösen.
