Wie soll ein Post-It ausreichen, um eine Anforderung zu beschreiben?

Vielleicht fragst du dich manchmal, wie eine User Story auf ein Post-It passen soll. Wie eine ganze Anforderung auf so eine winzige Karte passen soll. In diesem Video möchte ich dir einen Gedankenanstoß geben. Vielleicht ist es gar nicht Sinn und Zweck, eine Anforderung auf einem Post-It zu dokumentieren. Vielleicht ist der Sinn lediglich, dich zu erinnern. Genau wie die kleinen Zettelchen an oder unter deinem Monitor.

Transkript des Videos (automatisch erzeugt, bitte entschuldige mögliche Fehler)

Hallo! Eine Frage, die ich immer mal wieder gestellt bekomme, ist: "Wie kann eigentlich ein Post-it ausreichen, um eine Anforderung zu beschreiben?" Naja, und die einfache Antwort ist: "Gar nicht."

Die lange Antwort ist dann irgendwie doch ein bisschen länger und ein bisschen komplexer. Deswegen würde ich da gerne mal ein bisschen ausholen. Wo kommt dieses Thema "Post-It" oder "Karte" eigentlich her? Na ja, üblicherweise so in der agilen Vorgehensweise, in der agilen Softwareentwicklung, da schreibt man seine User Stories auf Post-its. Sofern man jetzt nicht ein Tool wie Jira oder wie auch immer nutzt, sondern wirklich physisch in einem Raum ist, nutzt man halt sehr gerne Post-its, um seine User Stories da drauf zu schreiben. Und es gibt auch so einen... Ich glaube Aliteral nennt sich das... dieses Triple-C für Card, Conversation und Confirmation und auch da haben wir wieder die Card, die Karte, also wieder dieses Thema: ja, es müsste eigentlich ausreichen, alles auf einer Karte zu dokumentieren. Also da kommt so ein bisschen das Thema Karte oder Post-it her.

So jetzt, jetzt kommt's aber. In diesem Triple C, das zweite C steht nämlich für Konversation oder auch Gespräch, Diskussion, Unterhaltung. Und die Karte ist nur der Aufhänger für das eigentliche Gespräch. Das ist das Entscheidende. Die Karte an sich ist so ein bisschen, wie soll ich sagen, wert... naja wertlos will ich nicht sagen. Aber die Karte an sich ist keine Anforderung und es ist auch gar nicht Sinn und Zweck, eine komplette Anforderung auf einer Karte zu dokumentieren. Die Karte ist so ein bisschen die Erinnerung: "Hey, wir wollen uns mal über dieses Thema unterhalten!" Und dann kommt das eigentliche Gespräch, die Konversation, Conversation, und zwar mit dem gesamten Team.

Und in diesem Gespräch entwickelt ihr gemeinsam die Anforderungen. Ihr besprecht die User Story. Ihr hinterfragt das Ziel. Ihr entwickelt Lösungsideen, wie man dieses Ziel erreichen kann. Ihr verwerft Lösungsideen. Ihr stellt fest, dass ihr noch irgendetwas klären müsst. Ihr geht in die nächste Iteration. Und so weiter und so fort. Das kann also auch durchaus mehr als ein Gespräch sein. Und nirgendwo steht geschrieben, dass man die Ergebnisse eines solchen Gesprächs nicht auch irgendwo dokumentieren kann. Du kannst da sehr wohl eine Dokumentation erstellen, ob du das jetzt auf einem Notizblock machst oder ob du das elektronisch machst mit OneNote oder wie auch immer, oder ob du dafür ein Tool nutzt wie Jira oder Trello, das ist vollkommen dir überlassen, aber selbstverständlich kannst du - oder kann auch irgendjemand anderes im Team - sich Notizen machen zu dem, was ihr besprochen habt. Was die Ergebnisse sind. Was die offenen Punkte sind. Natürlich ist diese Dokumentation möglich und aus meiner Sicht auch sehr sinnvoll. Also am Ende dieses Gesprächs mit deinem Team hast du sowohl die Karte als auch mehr. Sei es nun mehr Wissen in den Köpfen oder mehr Dokumentation oder wie auch immer. Aber du hast beides nach diesem Gespräch.

Jetzt fragst du vielleicht: "Naja, okay, aber sind wir da nicht wieder bei Wasserfall?" Naja, aus meiner Sicht nicht ganz, denn es gibt einen gravierenden Unterschied. Beim Wasserfall Modell definiert üblicherweise eine Person die Anforderung. Die schreibt detailliert runter, was jetzt eigentlich wie zu passieren hat. Das ist eine Spezifikation. Und diese Spezifikation wird dann genommen und dem Nächsten - dann gerne halt ein Entwickler oder ein technischer Architekt - in die Hand gedrückt. So sinngemäß: "Hier, du, bitte umsetzen, hör auf zu denken, sondern nur noch umsetzen." Und in dem Fall der agilen Vorgehensweise und mit der Karte, mit der User Story, startest du nur mit einem Gerüst, nur mit diesem einen Satz der User Story. Und das ist dann nicht eine Person, die eine Spezifikation erstellt, sondern im Team entwickelt ihr die Anforderung. Im Team detailliert ihr die Anforderungen. Im Team findet ihr gemeinsam Lösungen, wie ihr diese User Story umsetzen könnt.

Das heißt, der große Unterschied ist: Im Wasserfall Modell - ich sage es mal ein bisschen, ein bisschen drastisch - denkt einer, und die anderen arbeiten stumpf ab. Und in der agilen Vorgehensweise denken alle, und anschließend setzen auch alle - oder fast alle - um. Ja, das ist so ein bisschen der riesengroße Unterschied "einer" versus "das ganze Team".

Und eine Sache, die ich immer wieder erlebe: Wenn man nur genug schlaue Leute zusammen in einen Raum einsperrt, dann kommt am Ende immer was Gutes bei raus und meistens ist das, was nach so einem Gespräch mit vielen schlauen Leuten rauskommt, auch besser als all das, was ich mir irgendwie vorher zusammengereimt habe. Kann natürlich daran liegen, dass ich ein bisschen blöd bin. Aber vielleicht hast du ja auch eine ähnliche Erfahrung gemacht. Wenn du mit vielen schlauen Leuten zusammen bist, kommt am Ende meistens was richtig richtig Gutes bei raus. Das ist genau das Ziel von Karte und Konversation.

Ja, wie ist denn deine Sichtweise auf dieses Thema? Wie dokumentierst du deine Anforderungen? Ich bin einfach mal neugierig, was du davon hältst. Insofern teil gerne deine Sichtweise, teile gerne deine Erfahrungen.

In jedem Fall denk aber bitte immer daran, Das Leben ist zu kurz, um in beschissenen Projekten zu arbeiten. Bis bald.