Software-Dokumentation: User Story mitten aus dem Leben
- bhoffmann
- 26. März
- 3 Min. Lesezeit
Die Story eines Romans, die schreiben Autor oder Autorin. Die Story in einer Softwarelösung schreiben die Nutzer.
Interne Software-Dokumentationen erstellen Entwickler, um ihr Wissen weiterzureichen, Daten zu ordnen oder Software zu installieren. Die externe Dokumentation, das Handbuch folgt anderen Regeln. Hier dreht sich alles um die Kommunikation mit den Nutzern. Wie ich es als Technische Redakteurin praktiziere: bündige Anleitung, klare Sprache.
Als Erstes, ob Gerät oder Software, muss ich den Nutzer oder die Anwenderin gut kennen. Eine ersprießliche Quelle im Betrieb sind etwa der Produktmanager, die Kundenbetreuerin oder der Installateur. Oder Sie fragen gleich den Kunden selbst, rücken einer Auswahl von Nutzern mit einem Fragebogen auf die Pelle. Am besten bei ihm oder ihr vor Ort. Habe ich schon gemacht. Mit good vibes. – Nutzer berichten gerne aus der Praxis, von ihrer Sachkenntnis, üben in der Regel konstruktive Kritik. Freuen sich über die Aufmerksamkeit.
Immer an den Nutzer, die Anwenderin denken
Bei allem: Denken Sie nicht zu ‚technisch‘ mit Ihren Lösungen. Behalten Sie die Wünsche und Ziele der User im Blick. Checken Sie Funktionen daraufhin, wie die Nutzerziele zu erreichen sind.
Und: Wägen Sie ab, wie viel Informationen die Anwender benötigen.
Es kann zu wenig Information sein, wenn zur Bedienung Fachwissen vonnöten ist.
Es kann zu viel sein, wenn zum Gebrauch allein das Äußere genügt. (Um einen Kaffee maschinell zu kochen, brauche ich keine technischen Kenntnisse, noch nicht mal zum Lenken eines Autos.)
Easy: Alles auf eine Formel gebracht
Das alles findet in einer agilen Umgebung statt. Darüber möchte ich mich hier nicht auslassen. Bestimmt kennen Sie sich da besser aus.
Doch nun zur User Story in der Software-Dokumentation – endlich: Die gewonnenen Erkenntnisse über Kunde, Nutzerin werden in eine Formel komprimiert. Die lautet in etwa:
‚Als [Persona] erwarte ich [Softwareziel], um [Ergebnis] zu erreichen.‘
Oder: ‚Als (Rolle) möchte ich (Funktion), damit (Nutzen).‘
(Habe ich den unten angeführten Websites entnommen, bestimmt gibt es weitere Varianten.)
User Story: Software-Dokumentation in die Praxis bringen
Umgesetzt in die Praxis kann es dann etwa heißen:
‚Als Einkäufer möchte ich meine Fehlkäufe erfassen, damit ich mehr Kontrolle darüber habe‘.
‚Als Manager möchte ich die Fortschritte im Verkauf erfassen, um Erfolge und Pleiten besser berichten zu können.‘
‚Als Bloggerin möchte ich gerne unterrichtet werden, wenn ein Blogartikel zu lang wird, damit ich meine Leser besser ansprechen kann.‘
Erst mal das Wesentliche, dann kommen die Feinheiten
Zudem gibt es einige Anforderungen an gute User Storys, das Stichwort lautet INVEST-Prinzip. Habe die Essenz rausgezogen:
Independent (unabhängig): Die User Storys müssen unabhängig voneinander funktionieren.
Negotiable (verhandelbar): Erst mal wird das Wesentliche der User Story festgelegt. In der weiteren Ausarbeitung werden die Details besprochen und ergänzt.
Valuable (wertvoll): Der Mehrwert für den Kunden muss offensichtlich sein.
Estimable (schätzbar): Der Arbeitsaufwand sollte einschätzbar sein, was nicht so einfach ist. Erscheint die Story als zu ‚episch‘, also zu umfangreich, kann sie in kleinere Portionen (Storys) unterteilt werden.
Small (klein): Die User Storys sollten innerhalb eines Sprints (agiles Arbeiten!), also in einer vordefinierten Zeit abgeschlossen werden.
Testable (Testbar): Kriterien sollten festgelegt sein, mit denen die (erfolgreiche) Umsetzung überprüft werden kann.
Software-Entwickler und Technische Redakteurin in einem Boot
Hier müsste sich IT-Wissen und sprachliches Know-how treffen. Ich bin Redakteurin. Sie sind Entwickler, Entwicklerin? – Dann lassen Sie uns reden und gemeinsam lässige User Storys schreiben: hoffmann@technikverstndlich.de / +49 177 316 35 74.
Quellen:
Comments