Good Practices

„Fertig" heißt: nachweisbar fertig — nicht „läuft bei mir".

Bevor ihr eine Aufgabe startet, einigt euch, woran man erkennt, dass sie erledigt ist. Erst wenn diese Punkte überprüfbar erfüllt sind, ist sie fertig. Das verhindert das halbe „eigentlich passt's schon", das später teuer wird.

So in LOOMSchreibt jeder Story klare Akzeptanz-Kriterien. Eine Story wird erst im Showcase woven — wenn ihr zeigt, dass die Kriterien wirklich erfüllt sind.

Das Warum aufschreiben — euer künftiges Ich dankt es euch.

In drei Monaten weiß niemand mehr, warum ihr Datenbank X statt Y genommen habt. Haltet Entscheidungen fest, die euch festlegen: worum ging's, welche Optionen, wofür habt ihr euch entschieden — und warum. Das ist kein Bürokram, das ist eure Defensio in Rohform.

So in LOOMWerft einen Beacon (Typ decision). Das Projekt-Gedächtnis bewahrt das Warum dauerhaft.

Beobachtungen festhalten, bevor sie verfliegen.

Die beste Idee und das fieseste Risiko fallen euch mitten in der Arbeit ein — und sind zehn Minuten später weg. Senkt die Hürde: ein, zwei Sätze genügen. Kein Schätzen, kein Verantwortlicher, keine Form. Hauptsache, es ist festgehalten.

So in LOOMWerft einen Flock — jederzeit. Flocks sammeln sich laufend und sind die Grundlage fürs nächste Casting.

Der ehrliche Rückblick — auch das, was schieflief.

Ein Projekt wird nicht besser, indem man nur nach vorne hetzt. Haltet am Cycle-Ende kurz inne: Was lief gut, was hakte, was nehmt ihr mit? Gerade die Fehler sind wertvoll — wenn ihr sie benennt, wiederholt ihr sie nicht.

So in LOOMDas Loomback am Cycle-Ende. Schreibt die Erkenntnisse als Beacon (Typ learnings) — die machen eure Defensio stark.

Lesbarkeit ist eine Anforderung, kein Geschmack.

Euren Code lesen eure Teammates — und ihr selbst in drei Monaten. Cleverer Einzeiler, den keiner versteht? Kein Lob, sondern ein Problem. Schreibt so, dass jemand aus dem Team es in 30 Sekunden versteht. Lieber zwei klare Schritte als ein genialer.

So in LOOMGilt fürs Tool selbst genauso (LOOM wird von Schülern gepflegt). Wenn ihr eine Stelle nicht sofort versteht, ist sie zu clever — nicht ihr zu langsam.

Einigt euch auf euer Vokabular — und haltet es durch.

Wenn die eine „Modul" sagt, der andere „Komponente" und ein Dritter „Teil" meint, redet ihr aneinander vorbei — im Code, in den Docs, in der Defensio. Legt eure Begriffe fest und nutzt sie überall gleich. Das kostet anfangs Disziplin und spart später Verwirrung.

So in LOOMLOOM macht es vor: Story statt Ticket, Cycle statt Sprint, woven statt done — konsequent überall. Wählt für euer Projekt eure eigenen Begriffe genauso bewusst.