12Jacky
commented
4 months ago Benutzerdokumentation: Wir wollen das freilich nicht exzessiv betreiben, und auch nichts offensichtliches aufschreiben („Klicken Sie weiter, um weiter zu machen“). Aber was schon dokumentiert gehört: Welche Art von Benutzer:in soll Ihr System wie nutzen? Was muss ich als Nutzer:in (des Frontends, als Admin) beachten? Wo sind Einschränkungen des Systems, die man nicht sofort durch das UI vermuten würde? Daraus kann sich jeweils noch Anforderungen an die Benutzerschnittstelle ergeben, die Sie eventuell zeitlich ja noch umsetzen können. Einschränkungen sind okay, auch wenn die Software freilich robust sein soll. Entwicklerdokumentation: Architekturbeschreibung: Wie ist das System aufgebaut? Modulbeschreibungen: Was tun die einzelnen Komponenten/Module Inbetriebnahme: Wenn ich den Code aus Git ziehe, wie kriege ich das bei mir ans Laufen? Darf freilich Verweise auf Getting-Started-Guides der Frameworks enthalten, da brauchen Sie nix doppelt schreiben. Generell: Keine Romane, aber halt eben hinreichend umfangreich.
Weil's mir gerade auffällt: in der Anforderungsdoku haben fast alle Teams eine ganz wunderbare Struktur, mit Labels, Projekten usw. - aber schauen Sie mal die einzelnen Tickets an: Da sind viele Aufgaben/Todos, aber von der Formulierung her fast keine Anforderungen. Schauen Sie mal drüber, was von den Tickets tatsächliche Softwareanforderungen sind (sind ja zumeist verlabelt) und dass diese auch so formuliert sind im Titel des Tickets. Sie tun sich letztlich leichter bei Implementieren, wenn Sie zunächst Softwareanforderungen schreiben, weil diese tatsächlich qualitativ prüfbar sind. Bei einem Todo können Sie meist nur sagen "hab ich gemacht".
Diesen Freitag wiegesagt keine Veranstaltung, aber die dringende Empfehlung selbstständig ein Sprint Review + Planung zu machen.