Joe: „Bright club“ videos gucken lohnt sich. (10-min stand up comedy zu akademischen Themen)
-
Funktioniert gut im Wiki (Froh nimmt Confluence und lässt von dem direkt ne PDF generieren. Funktioniert gut.) (Anmerkung: Normalerweise generieren wir KEINE PDFs, die Stakeholder haben Zugriff auf das Wiki. –Froh)
Kontextabgrenzung ist wichtig: „Wir machen NICHT: Billing“
Superwertvoll: Entwurfsentscheidungen. Bei Froh auch eine einzelne Wiki-Seite.
Kann Soll Vision, Trends, Business-Entscheidungen etc enthalten
Mann kann auch Dinge erst mal offen lassen, und ausfüllen, wenn sich das klärt.
-
Sponsor: Klar machen, auf wessen Mist das Projekt gewachsen ist.
Meta / Frage von Martin: Wie kriegt man aus Confluence so ein schönes PDF Dokument – speziell mit so guten Nummerierungen – heraus?
ARC42 Templates gibts auch für „Wenn Ihr nicht vermeiden könnt, UML Tools zu nutzen“:
Froh Buchempfehlung: Scott Ambler: The Object Primer - Agie Model Driven Development - UML und Agile Entwicklung: Wie setze ich UML richtig ein? Nicht so genau nehmen, Tools: Whiteboard + Photoapparat
Froh ist über dessen gute UML Dokumentation drauf gekommen
ARC42 fragt viele Dinge ab, die man früher oder später wissen will, aber evtl. selber vergisst rechtzeitig in Erfahrung zu bringen (Bsp: „Legal Constraints“, gibt es zu erfüllende Standards?)
Das Dokument muss leben – Inaktuelle Dokumentation ist schlimmer als zu wenig detaillierte. Deswegen lieber kürzer, dafür aktueller! (Anmerkung: Wichtig: Nicht mehr aktuelle Sachen löschen! –Froh)
Requirements: Klare Ansagen statt schwammiger Formulierungen: „Level A“, „Level B“, „not supported“ platforms / devices / browsers etc pp
„Requirements missing“ quasi als To-Do Liste, wenn fehlende Req's schon bekannt.
Randbedingungen („System Scope and Context“
„Ein bissel“ hat ARC42 auch eine zeitliche Reihenfolge bzw. funktionale Abhängigkeit – Typischerweise wird man bei der Arbeit mit dem Template die „vordere Hälfte“ vor der „hinteren Hälfte“ ausfüllen, und das Dokument iterativ füllen.
Es geht darum, „gemeinsames Verständnis“ herzustellen – d.h. das Dokument klärt, was Begriffe bedeuten. Das heißt insbesondere, dass jeder im Team das Dokument verstehen können muss!
Je komplexer die Konzepte, desto weniger kann man präsentieren
„5 +/- 2 Regel“ (Arbeitsgedächtnis der Menschen) (Früher hieß das mal 7 +/- 2, aber das ist .OLD)
Nichtfunktionale Requirements sind nicht leicht zu dokumentieren: Vage Ideen wie „es läuft 24/7“ sind in den Teamgehirnen verankert, aber schriftlich nicht immer leicht festzuhalten. Problem: Requirements müssen hart sein, sollten von extern kommen.