Abschlussprojekt und Review

Abschlussprojekt und Review

0:00 Zum Abschluss kommt der Teil, der im Seminar am meisten Mut verlangt: Sie führen Ihre App vor, und jemand anderes prüft sie. Der Nachweis, um den es dabei geht, ist nicht, dass Klarpfad läuft — das tut es seit dem dritten Tag. Es geht darum, ob die Entscheidungen dahinter erklärbar sind. Warum dieses Modul, warum dieser Speicher, warum diese Scopes. Genau das wird im Projektalltag von Ihnen verlangt, meistens von Menschen, die den Code nie sehen werden.

Abschlussprojekt und Review

0:28 Dieser letzte Abschnitt hat drei Teile. Zuerst nehmen Sie eine neue Anforderung auf und ordnen sie ein. Dann führen Sie Ihre Lösung vor — mit Fehlerfall, nicht nur mit Sonnenschein. Und zum Schluss prüfen Sie gegenseitig anhand einer gemeinsamen Checkliste und übergeben die offenen Punkte. Am Ende haben Sie nicht nur eine App, sondern eine Dokumentation Ihrer Entscheidungen — und eine Liste dessen, was noch offen ist.

Eine neue Anforderung aufnehmen

0:52 Beginnen wir mit der Fähigkeit, die Sie im Alltag am häufigsten brauchen werden: eine Anforderung einordnen, bevor Sie anfangen zu bauen. In einer Forge-App trifft jede Anforderung eine von drei Schichten: die Oberfläche, den Resolver oder das Datenmodell. Diese Einordnung entscheidet über Aufwand und Risiko — und sie lässt sich in fünf Minuten treffen, wenn man die Woche über aufgepasst hat.

1:16 Eine Modelländerung zieht eine Migration nach sich. Eine Anzeigeänderung nicht. Und ein neuer Scope zieht eine Zustimmung bei jedem Kunden nach sich. Wer das vorher sagt, gilt als verlässlich. Wer es hinterher merkt, als langsam. Vier Felder, und das vierte ist der Grund, warum ich Ihnen dieses Schaubild mitgebe. Oberfläche, Resolver und Datenmodell sind die offensichtlichen Schichten.

1:39 Die Berechtigung ist die vierte Dimension, die quer dazu liegt — sie kann bei jeder der drei anderen auftauchen und ist immer die mit den weitesten Folgen. Fragen Sie deshalb bei jeder neuen Anforderung zuerst: Braucht das einen neuen Scope? Ist die Antwort ja, verschiebt sich die Aufwandsschätzung nicht um Stunden, sondern um Wochen.

1:59 Fünf Schritte, die zusammen eine halbe Stunde dauern und einen Tag sparen. Erst den fachlichen Bedarf ohne Technik — dieselbe Übung wie am ersten Tag. Dann die Schicht bestimmen und begründen. Dann die Scope-Frage. Dann prüfbare Akzeptanzkriterien, so wie wir sie für generierten Code formuliert haben. Und zum Schluss die Nicht-Ziele. Dieser letzte Schritt ist der wirksamste gegen ein Phänomen, das jedes Projekt kennt: die Anforderung, die während der Umsetzung wächst.

2:28 Der erste Punkt ist der teuerste: Die Anforderung wird als Oberflächenwunsch aufgenommen und trifft in Wahrheit das Modell. „Zeig doch einfach noch das Datum dazu" — und das Datum existiert im Datenmodell nicht. Der zweite ist der, den Sie jetzt kennen: Ein neuer Scope fällt erst beim Upgrade auf. Und der dritte ist ein Formulierungsfehler mit Folgen — Akzeptanzkriterien, die die Umsetzung beschreiben statt das Ergebnis, lassen sich nicht abnehmen, sondern nur nachrechnen.

Die Lösung demonstrieren

2:55 Jetzt zur Vorführung — und zu der Frage, was eine gute von einer beruhigenden unterscheidet. Eine gute Vorführung zeigt den vollständigen Weg: Vorgang öffnen, Entscheidungen sehen, Eintrag erfassen, Berechtigungsfall auslösen, Fehler nachvollziehen. Der entscheidende Satz steht am Ende: Erst der Fehlerfall macht sichtbar, ob die App Zustände beherrscht oder nur den Erfolgsweg kennt.

3:18 Und genau deshalb ist er in dieser Vorführung Pflicht. In echten Abnahmen wird er gern ausgelassen — mit dem Ergebnis, dass der erste echte Fehler beim Kunden stattfindet, vor Publikum. Sechs Zeilen, und sie sind die Zusammenfassung der ganzen Woche. Ladezustand und Leerzustand vom zweiten Tag. Prüfung und Rückmeldung vom dritten.

3:39 Der doppelte Klick, der nur einen Eintrag erzeugt — ebenfalls Tag drei. Der Berechtigungsfall vom vierten. Der Fehler mit eigener Meldung, ebenfalls Tag vier. Und in der letzten Zeile das, worum es eigentlich geht: Modul, UI-Modell, Speicher, Scopes begründet. Die Fußzeile sagt es deutlich — nicht die Zahl der Funktionen zählt, sondern die Nachvollziehbarkeit der Entscheidungen.

4:04 Der erste Punkt ist menschlich und verbreitet: Vorgeführt wird der Erfolgsweg mit vorbereiteten Daten. Das beruhigt alle Anwesenden und beweist wenig. Der zweite ist eine Zeitfrage mit Folgen — die Begründung fällt weg, weil die Zeit in Funktionen geflossen ist. Und der dritte ist der feine Unterschied, auf den ich achten werde: Der Berechtigungsfall wird beschrieben statt ausgelöst. Beschreiben kann man alles.

4:29 Auslösen zeigt, ob es stimmt.

Fremdprüfung und offene Punkte

4:31 Und damit zum Review — dem Teil, in dem andere das finden, was Sie nicht mehr sehen können. Im Review prüft eine fremde Gruppe die App gegen eine gemeinsame Checkliste: Architektur, Bedienbarkeit, Tests, Scopes, Datenhaltung, Betrieb. Wichtig ist die Regel dazu: Befunde werden festgehalten, nicht sofort verteidigt. Das klingt nach einer Umgangsform und ist in Wahrheit eine Methode — sobald erklärt wird, endet das Finden. Verteidigen können Sie später, in Ruhe und schriftlich.

5:01 Am Ende steht die Liste dessen, was vor einer produktiven Nutzung noch zu klären ist. Sechs Blöcke, sechs Fragen — und jede stammt aus einem Tag dieser Woche. Architektur aus Tag eins. Oberfläche und Zustände aus Tag zwei. Sicherheit aus Tag vier, Daten aus Tag drei. Tests ebenfalls Tag vier, Betrieb aus Tag fünf. Worauf es ankommt: Diese Liste ist kurz genug, um sie tatsächlich zu benutzen.

5:27 Eine Checkliste mit vierzig Punkten wird einmal verwendet und dann nie wieder. Nehmen Sie diese sechs Zeilen mit ins eigene Projekt — sie passen auf jede Forge-App. Vier Gründe, und der erste ist der, den ich am liebsten weitergebe: Eine App ohne offene Punkte wurde meist nicht ehrlich geprüft. Benannte Risiken lassen sich einplanen, verschwiegene nicht. Die Liste ist zugleich die Übergabe an alle, die später daran arbeiten.

5:54 Und sie trennt bewusste Entscheidungen von übersehenen Lücken — das ist der Unterschied zwischen „wir haben das bewusst nicht gemacht" und „das hat niemand bemerkt". Im Zweifel entscheidet dieser Unterschied über das Vertrauen in Ihre Arbeit. Der erste Punkt ist der, den ich im Review immer wieder unterbreche: Befunde werden sofort erklärt statt notiert.

6:14 Der zweite ist eine Frage der Kultur — die Liste offener Punkte bleibt leer, weil sie wie Kritik wirkt. Dabei ist sie das Gegenteil: ein Zeichen, dass jemand genau hingesehen hat. Und der dritte ist der inhaltliche Klassiker: Geprüft wird die Oberfläche, weil sie sichtbar ist — nicht Scopes und Datenhaltung, wo die teuren Fehler sitzen.

Übung

6:35 Damit sind wir beim Abschlussprojekt. Eine letzte Anforderung, eine Vorführung, ein Review. Die Falkenmoos GmbH meldet eine letzte Anforderung: Jede Entscheidung soll eine Frist bekommen, und überfällige sollen im Panel hervorgehoben werden. Das ist mit Absicht eine Anforderung, die nach Oberfläche klingt und keine ist — die Frist muss ins Modell, die Überfälligkeit muss berechnet werden, und die Hervorhebung ist der kleinste Teil.

7:00 Danach führt jedes Team vor und lässt sich von einer anderen Gruppe prüfen. Drei Erfolgskriterien, und sie fassen die ganze Woche zusammen. Die Frist ist umgesetzt und geprüft — also mit einem Test, nicht nur im Browser gesehen. Die Vorführung zeigt Berechtigungs- und Fehlerfall. Und die offenen Punkte sind schriftlich übergeben.

7:20 Wer früh fertig ist, ergänzt einen Test für die Berechnung der Überfälligkeit — eine Berechnung mit Datum und Zeitzonen ist genau die Art Regel, die man testen will und nicht klicken. Die Reihenfolge ist bewusst gewählt: Modell, Resolver, Anzeige — von innen nach außen. Wer mit der Hervorhebung beginnt, baut sie zweimal.

7:40 Schritt drei ist der, den ich Ihnen besonders ans Herz lege: die Vorführung einmal proben. Nicht wegen des Auftritts, sondern weil dabei fast immer auffällt, dass Testdaten fehlen, mit denen sich der Fehlerfall zeigen lässt. Und Schritt fünf ist die Haltung, die ein Review erst wertvoll macht: entgegennehmen und übergeben, nicht verteidigen.

8:01 Drei Punkte zum Schluss, und der erste ist die Pointe der Übung: Die Frist landet nur in der Anzeige, das Modell kennt sie nicht — dann ist nach dem Neuladen alles weg. Der zweite ist der, der ohne Probe eintritt: Die Vorführung scheitert an fehlenden Testdaten. Und der dritte ist der, den Sie ab heute vermeiden können: Befunde werden diskutiert statt aufgeschrieben.

8:22 Damit sind wir am Ende der Woche — mit einer App, die läuft, und mit Begründungen, die tragen.