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.
Ich denke, dass Sie hier nach verschiedenen Dingen fragen. Wenn Sie ein neues Teammitglied aufnehmen, dann sollte die Dokumentation für das System auf dessen Rolle im Team als Teil des Einführungsprozesses ausgerichtet sein.
Wenn Sie über die Dokumentation der Systemfunktionalität sprechen: In unserer Organisation dokumentieren unsere Schulungsteams die Funktionalität als Teil der Freigabe. Sie werden (als Beteiligte) während des Sprint Review (Demo) einbezogen und erhalten dann eine Schulungsumgebung mit der neuen Funktionalität, um die Schulungsunterlagen vor der Freigabe vorzubereiten.
Wenn Sie über die Bereitstellung von Dokumentation für die Nachvollziehbarkeit sprechen, kann Ihr Rückstand mit den richtigen Prozessen und Kontrollen als solche dienen.
Jedes dieser verschiedenen Elemente erfordert Planung und bewusste Prozessentwicklung, um effektiv zu funktionieren und die Bedürfnisse des Teams zu erfüllen. Wir haben jeden dieser Punkte in unsere Retrospektiven aufgenommen, als ein Problem erkannt wurde, und dann unsere Prozesse im Laufe der Zeit entwickelt.
Zusätzlich zu dem, was James Kolpack gesagt hat, sollte die User Story Map auch nach Abschluss des Projekts bestehen bleiben, da auch sie eine Form der Dokumentation ist. Ich glaube, wir planen, sie in irgendeiner Weise in ein Dokument umzuwandeln, das in unserem Wiki lebt, wenn alles gesagt und getan ist.
Die Idee ist, dass dieses Dokument für diejenigen nützlich ist, die das System in Zukunft warten oder verbessern müssen, weil sie die Perspektive der Benutzer kennen.
Ich stimme Todd größtenteils zu, aber es gab Zeiten, in denen es zu den Aufgaben meines Teams gehörte, Dokumentationen zu erstellen: Die Dokumentation war die User Story selbst unsere PO gebeten, geliefert zu werden.
In diesen Fällen haben wir die folgenden Leitlinien befolgt:
Meiner Erfahrung nach erleichtert dies das Verfassen von Dokumenten und ermöglicht eine Art Test (man bittet jemanden, typischerweise den PO, das Dokument zu lesen und zu sagen, ob es angesichts des Ziels in Ordnung ist).
Sie schreiben Dokumentationen, um Ihr System zu validieren. User Stories dienen demselben Zweck, wenn sie korrekt in einem Format geschrieben sind, das die Interaktion der Benutzer mit dem System widerspiegelt. Ich empfehle die Verwendung von BDD und das Schreiben von Stories in der Gherkin-Syntax. Letztendlich werden Ihre Szenarien zu Akzeptanzkriterien, die bei der Validierung helfen, ob das System korrekt funktioniert oder nicht.
Wir haben ein Dokumentationsteam, das die "Gebrauchsanweisung" für unser Produkt erstellt. Das Handbuch ist um die Hauptfunktionen des Produkts und die Aufgaben, die der Benutzer mit diesen Funktionen ausführen kann, herum aufgebaut.
In jedem Sprint arbeiten Scrum-Teams an User Stories, die den Produktmerkmalen Funktionen hinzufügen.
Nach der Sprintplanung trifft sich das Doku-Team mit dem Scrum-Team und bespricht, welche User Stories in diesem Sprint entwickelt werden sollen. Das Docs-Team beginnt dann mit der Verbesserung der Bedienungsanleitung, indem es die ersten Dokumente schreibt. Während des Sprints verfolgt das Doku-Team den Fortschritt der User Stories und kann das Produkt nutzen, wenn es in Testumgebungen eingesetzt wird. Am Ende des Sprints stellt das Doku-Team die aktualisierte Bedienungsanleitung fertig und fügt letzte Screenshots usw. hinzu.
Die Gebrauchsanweisung wird in jedem Sprint als Teil der Veröffentlichung ausgeliefert.
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.
