Damit meine ich nicht, dass man morgens bei 09:00 Uhr beim
Kaffee sitzen sich denkt, warum bin ich eigentlich hier, nein,
sondern warum diese User Story Coding Buddies Dein Podcast rund
um Softwareentwicklung und aktueller Tech News.
Herzlich Willkommen. Ein herzliches Hallo zum Coding
Buddies Podcast. Ich hoffe es geht dir gut, liebe
Zuhörerin, lieber Zuhörer und du kannst der neuen Folge ganz
entspannt lauschen und damit begrüße ich natürlich auch den
Tino, der hier nicht fehlen darf.
Tino Moin Moin Fabi, Was geht ab, was geht ab?
Ja ich würde sagen es ist Weihnachtszeit, ich habe Urlaub
mir geht's gut, was soll man dazu noch sagen?
Klingt perfekt? Auf jeden Fall.
Ja, die Weihnachtszeit ist auch schon ziemlich fortgeschritten.
Ja, wir sind ja schon fast durch, damit eigentlich schon so
gut wie fertig mit dem Gröbsten, das ist gut, kann mich jetzt
einfach nur zurücklehnen, ja dann lehn dich zurück, wir haben
ein spannendes Thema heute mache ich ist auch mehr so ein
lockerer Talk würde ich sagen, ist jetzt kein technischer Talk,
aber trotzdem ein sehr wichtiges Thema und.
Das coole dabei ist, das Thema stammt nicht von uns, sondern es
wurde vorgeschlagen beziehungsweise sich aus der
Community gewünscht, denn wir haben vor einer Weile eine
Nachricht bekommen, von der Veronika, vielen Dank dafür noch
mal, denn sie hat gesagt, dass unser Podcast bei ihr jetzt
mittlerweile ein fester Bestandteil ist und wir coole
Insights geben. Also Veronika, vielen, vielen
Dank dafür, dieses wunderbare Feedback und du hattest dir
gewünscht, weil wir das vor. Jahren also nicht, aber vor
einer Weile in einer Folge mal angerissen hatten.
Und zwar das Thema User Stories, dass wir da quasi einfach mal n
bisschen näher drauf eingehen, wie wir das ganze betrachten,
was gute User Stories sind, was so Duschen don't sind und das
würde ich halt sehr gerne heute mit dir besprechen, das heißt
wir gehen auch wieder so n bisschen in die agile Welt rein.
Oh yeah, da können wir ja auch schon mittlerweile Bände
erzählen. Also was meinst du, wollen wir
das so machen, dann würde ich sagen starten wir da auch
einfach direkt rein finde ich gut finde ich gut lass uns das
war würde ich sehr gerne versuchen so folgende Fragen so
n bisschen ich hab mir mal überlegt was für fragen wir denn
mit dieser Folge quasi beantworten könnten und als
erstes natürlich warum überhaupt user Stories was sind User
Stories auch noch mal kurz und warum sind sie so wichtig?
Das ist ja eigentlich so die Kernfrage.
Warum werden sie verwendet? Warum sind wir auch der Meinung,
dass es gut ist, mit User Stories zu arbeiten, um das
einfach n bisschen ja herauszukristallisieren und dann
vor allem, was sind so häufig Probleme die uns begegnet sind,
die wir selbst versuchen zu vermeiden, weil man sollte denn
natürlich auch versuchen, diese Probleme zu vermeiden.
Und was ich sehr cool finde würde, und das gibt auch einen
selbst, immer noch mal so einen erleuchtenden Moment, dass wir
uns überlegen, was könnten so Tipps sein für Entwickler oder
auch Pos, also wie man bessere User Stories schreiben könnte,
dass wir das am Ende noch behandeln.
Ja, und natürlich immer auch unsere eigenen Erfahrungen mit
einbringen. Ich habe, da du ja auch schon
einiges erlebt, sowohl Gutes als auch vielleicht nichts ganz so
gutes und. Dass man da einfach noch mal
vielleicht aus dem Nähkästchen plaudert.
Ich hör mal kurz mein Nähkästchen.
Hol mal und ich würd sagen, jetzt geht es dann auch los.
Also fabi, erzähl doch mal. Was sind User Stories aus deiner
Sicht allgemein? Ja.
Definiere es mal. User Stories ist im Endeffekt
so, also so würde ich das beschreiben.
Also ist ne die Sicht des Endanwenders über die
Anforderung. Und das Ganze in Form einer
Beschreibung und sozusagen. Also du hast jetzt eine
Anforderung, also eine Art Feature oder ein Teil Feature
und das wird beschrieben über eine bestimmte Art und Weise aus
Sicht des Endnutzers und ich finde da ist es auf jeden Fall
sehr, sehr wichtig und den Tipp möchte ich auch gleich am Anfang
geben, damit es auch jeder hört. Hier geht es um eine fachliche
Beschreibung und nicht um eine technische Beschreibung.
Ja, ein sehr wichtiger Punkt. Ich finde es auch gut, dass du
direkt sagst, aus Sicht des Endnutzers oder Endanwenders,
wie du es gerade gesagt hast, weil das ist nämlich der
entscheidende Punkt dabei, dass du halt den Fokus auf den
Endanwender legst und es aus also durch seine Brille auf das
Produkt guckst, wie man so schön sagt.
Und auch diese Beschreibung dahinter sorgt ja dafür, oder?
Das Ziel ist ja wirklich Klarheit zu schaffen, was am
Ende wirklich programmiert werden muss und.
Oder soll und vor allem warum. Deswegen haben wir ja quasi
schon gesagt, warum sind sie so wichtig, weil also es soll darin
definiert werden, warum machen wir das Ganze hier eigentlich,
und das, da gibt es ja nichts Besseres, als es aus Sicht des
Endanwenders zu betrachten, genau weil da muss das warum ja
drin sein. Ich finde, im Ziel ist es auch
immer gut, wenn man sich vor Augen hält, dass man sagt, OK,
welcher Wert. Oder welcher Value wird mit
dieser User Story geschaffen? Also wenn du am Ende dieser User
Story, wenn du sie dir durchgelesen hast, dir denkst,
weiß nicht, am Ende passiert jetzt irgendwie, aber eigentlich
nicht wirklich was oder du kannst das eigentlich irgendwie
gar nicht richtig verwenden, das was da beschrieben ist.
Also du hast halt diesen Nutzen für den User am Ende nicht, dann
ist es eigentlich nicht wirklich das also das Ziel wurde da nicht
richtig erfüllt mit dieser User Story.
Deswegen in dieses, dieses Klarheit schaffen.
Worum geht es, welchen, welcher wert wird geschaffen und warum?
Wie du meintest wird dieser Wert geschaffen, ne ja genau, und
warum sollte man jetzt nicht einfach Anforderungen auflisten,
kann ja jetzt auch so die erste Frage sein.
Ja ist ja cool das aus Sicht des Users zu betrachten aber so
gerade in der Vergangenheit in in der alten Welt, da wurden
einfach Anforderungen definiert. Und wir haben ja, wie gesagt,
einen wichtigen Punkt dabei schon genannt, dass halt die
Kundenzentrierung sehr entscheidend ist.
Stell den Kunden in den Fokus um einfach auch ne bessere
Entwicklung zu ermöglichen am Ende.
Ich finde aus persönlicher Sicht und ich denke da stimmst du mir
auch zu user Stories sind auch einfach viel leichter zu
verstehen, wenn ich so an meine frühere Zeit denke, so in meinen
ersten Berufsjahren habe ich auch oft nach.
Ist ja auch ne Weile schon her. Nach strikten Anforderungen
entwickelt und wenn du aber so ne Anforderung erstmal 5000 mal
durchlesen musst um überhaupt zu verstehen wo in welche Richtung
das geht, wie das überhaupt in das Produkt einzahlt und am Ende
trotzdem noch super viel Variabilität da drin ist, weil
es einfach gar nicht ausführlich genug beschrieben ist, dann
schafft das kein gutes Verständnis und vor allem
schafft es kein gutes Verständnis und das ist n
wichtiger Punkt über das gesamte Team.
Ja, also du liest es dir jetzt mehrfach durch.
Du versuchst das Verständnis aufzubauen und bist vielleicht
in der Lage, das umsetzen zu können.
Wenn jetzt aber n Kollege von dir das übernehmen soll, muss er
sich genauso wieder reinfressen gedanklich.
Ja. Also es ist halt schwierig, das
auch quasi aufs Team denn so auszubreiten aus meiner Sicht.
Und wenn ich jetzt ne gut geschriebene User Story hab, die
nicht technisch ist, weil du das ja wirklich explizit am Anfang
schon erwähnt hast, ja. Ist es halt viel schneller zu
verstehen. Was soll jetzt eigentlich
gemacht werden oder was ist das Ziel, wie du so schön gesagt
hast. Ja ja das find ich, kannst du
tausendmal schneller erreichen mit User Stories.
Ich find das, was du gerade beschrieben hast.
Ich kenn das. Das ist auch so n so ne richtige
absolute Bad Practice ist so was ich auf jeden Fall auch schon
erlebt hab. Es wird eine user Story
geschrieben, wo eigentlich nur eine E Mail rein kopiert wird,
wo jemand irgendwie mal so einen vagen Wunsch geäußert hat über
irgendwas und dann wird diese Mail einfach in diese user Story
rein kopiert und dann wird gesagt so okay und jetzt go und
du denkst dir so okay warte mal. Also es gibt keinerlei
Absprachen irgendwie über ein Feature, das ist einfach jetzt
eine Art Mail in eine User Story gequetscht und.
Das ist alles andere als klar, weil klar, jeder hat vielleicht
eine unterschiedliche Interpretation, eine
unterschiedliche Interpretationsspielraum, den
man irgendwo reingeben kann, aber genau deshalb ist es ja so
wichtig, möglichst diesen Interpretationsspielraum
einzuschränken, um zu sagen, es ist nicht so, dass zum Beispiel
Person a sich das durchliest und irgendwie eine Vorstellung hat,
Person B sich das vorliest, auch irgendeine Vorstellung davon hat
und beide Vorstellungen komplett unterschiedlich sind.
Weil dann hast du irgendwann das den Effekt, dass zum Beispiel,
also dass es nicht egal ist, welcher welches Teammember
sozusagen sich diesen diese user Story schnappt und bearbeitet,
sondern es ist hat n unglaublichen Impact, weil so
viel Interpretationsspielraum da ist, dass man einfach entweder
dies, das oder jenes machen könnte und am Ende kommst du ja
an den Punkt, dass du dann das irgendwann abgeschlossen hast
und n Teammitglied dir sagt, so war das doch gar nicht gemeint,
oder? Und dann kommt sozusagen der
Stakeholder, der das sozusagen ne vorgeschlagen hat oder
eingebracht hat. Diese User Story und sich denkt,
na ja, also nee, so nicht, aber so wie du sagst auch nicht.
Also das find ich jetzt blöd, also weißt du, das ist ja,
deswegen ist es halt wichtig auch ne gewisse Struktur in
diese User Stories reinzubringen und auch noch mal zu dem Punkt
technisch ne. Ich habe das auch schon erlebt,
dass zum Beispiel User Stories versucht wurde, das was gemacht
werden soll, sehr, sehr technisch zu beschreiben und ich
finde und das ich finde, ich finde das ist so ein unglaublich
wichtiger Punkt, der auch nicht in die User Story reingehört,
weil angenommen du sagst zum Beispiel okay ich habe eine
Anwendung und möchte jetzt eine Authentication da reinpacken,
also irgendwie du hast ein User Management System und möchtest
sagen. User X kann sich jetzt anmelden,
ne als Beispiel, dann willst du ja sagen OK ne user Story könnte
ich verpack das jetzt einfach nur mal ganz wörtlich mit einem
großen Interpretationsspielraum, aber dass du sagst du hast eine
Anmeldemaske und wenn du in diese Anmeldemaske deinen
Usernamen und dein Passwort eingibst und es stimmt, dann
kommst du ins System rein, wenn es nicht stimmt kriegst du eine
Nachricht, stimmt nicht. So, das ist ja ne sehr sehr
fachliche Beschreibung. Davon sollte man natürlich noch
in einer gewissen Struktur abbilden, das ganze aber um es
zu verstehen, weißt du ja dann in diesem Moment, OK, alles
cool, das ist erstmal. Du weißt was passieren soll,
aber was genau wie sozusagen technisch under the Hood diese
Authentifizierung funktioniert, was da für ne.
Für eine Kommunikation stattfindet, wie das gespeichert
wird, wie das verschlüsselt wird und so weiter das sind ja
wichtige Punkte, die überhaupt nichts darin zu tun haben.
Aber du könntest ja rein theoretisch diese user Story so
schreiben, dass du sagst, verwende bitte
authentifizierungsverfahren XY, das und das und dann denke ich
mir so, das kommt ja normalerweise, kommt ja so eine
user Story nicht von einem Entwickler oder einer
Entwicklerin, also. Kann diese Person ja gar nicht
diese Entscheidung treffen. Darüber also diese Expertise
einbringen, weil das ist ja Part des Entwicklerteams ne und
deswegen lange Rede kurzer Sinn, fachliche Anforderungen kommen
in die User Story und die technischen Details werden dann
vom Entwicklerteam geklärt. Ja, macht ja auch Sinn.
Also wie gesagt, wir haben ja gesagt, der Fokus soll auf die
Sicht des Endanwenders sein und der Endanwender.
Dem ist reichlich egal, was für n Authentifizierungsverfahren
dahinter steht. Er möchte in deiner Maske seine
Login Daten eingeben und dann zu seinem Dashboard bei
beispielsweise weitergeleitet werden, weil er geht ja davon
aus wenn ich die richtigen Daten eingebe komm ich da auch hin ne
und das ist ja so wirklich die User Story da am Ende und ich
find auch wichtig, dass du sagst es muss so n so n festen Aufbau
geben und da gibt es auch verschiedene Schreibweisen.
Viele, also einige, haben sich davon auch wirklich so gut
durchgesetzt, dass man sagen kann, das ist schon Standard,
irgendwo, jedenfalls aus meiner Sicht, so verwende ich es gerne,
beispielsweise, dass man immer erstmal sagt, ich als User oder
meine Benutzerrolle ne, also du kannst ja auch mehrere Rollen
haben, es kann ja mehrere Endanwender geben.
So ne Art aber zum Beispiel. Genauso personas, dass du sagen
kannst, mein ich als User jetzt als wirklich Endanwender.
Ich möchte, geht ja auch. Ja genau das wär jetzt so ne
andere Rolle, aber jetzt gehen wir jetzt noch mal von dem User
aus, dann sagst du halt ich als User möchte quasi mich einloggen
auf dieser Seite um dann das ist so der Nutzen dann am Ende warum
will ich das machen um auf mein persönliches Dashboard zu
kommen? Dann kannst du sagen, damit habe
ich abgedeckt. Wer also benutzerrolle User, was
ist mein Ziel ne also ich möchte mit meinen Daten mich einloggen,
das ist mein Ziel und warum will ich das machen, das ist halt das
warum, damit ich in meinen persönlichen Bereich komme so
und das ist erstmal so ne grundlegende Formulierungsart
wenn die sich etabliert auch in einem Team kannst du sowas
unfassbar schnell lesen und du brauchst nicht viele Sätze, du
brauchst halt keinen riesen Text.
Ne. Genau, ich mein das, das kann
man noch sehr gut erweitern, so wie wir es auch machen.
Da würd ich aber später drauf noch mal eingehen.
Also das wär jetzt so quasi die User Story als Szenario
beschrieben, worum geht es, warum möchte der User das machen
ich. Find das auch gut, dass du
sagst, OK ne, also diese diese, diese diese als diese Rolle
einnehmen. Ne ja, also aus Sicht dieser
Story. Und dann noch das, was du
meintest, dass ich auf mein Dashboard komme.
Das ist ja im Endeffekt der dieser Value, dieser wert, was
ich meinte, ne das am Anfang war wichtig, genau und das.
Warum denn einfach? Genau.
Warum will ich das überhaupt genau?
Und damit hast du ja schon mal ganz klar abgesteckt und ich
finde diese diese Art, dass du sagst, ich als User dieser
Anwendung oder ich als Admin dieser Anwendung oder was auch
immer ne. Damit kannst du dich ja, wenn du
dann irgendwie irgendwann muss man diese user Story ja auch
abnehmen. Das heißt, die User Story wird
erstellt, die User Story geht ans Developer Developer Team,
dann wird sie bearbeitet und irgendwer muss ja im Normalfall
die Person, die das sozusagen gestellt hat beziehungsweise als
Proxy sozusagen der Po diese User Story irgendwie abnehmen
und sagen okay passt es oder passt das nicht und genau an der
Stelle ist es ja dann auch gut sich.
Einmal, wenn du aus der entwickelnden Sicht guckst und
sagst okay was, was soll hier eigentlich passieren?
Okay ich versetze mich jetzt mal in die Lage, ich bin der User,
so weißt du und so kannst du das dann lesen und dann halt auch
das Ganze dann sozusagen betrachten, bearbeiten und
genauso kannst du auch irgendwann sagen okay ich bin
jetzt der Po und möchte das jetzt zum Beispiel abnehmen und
sagen ist diese user Story richtig umgesetzt, dann kannst
du ja genauso wieder sagen okay. Ich gucke jetzt mal durch und
sage jetzt mal, ich bin jetzt der User und möchte mich jetzt
zum Beispiel anmelden, um auf mein Dashboard zu kommen.
So und wenn ich jetzt aber sage, ich gebe jetzt meinen Usernamen
und mein Passwort ein und man kommt dann und du weißt, du hast
dein richtiges Passwort eingegeben und du kommst nicht
dahin, dann kannst du halt nur sagen okay sorry, die User Story
ist nicht richtig umgesetzt, wenn es aber funktioniert und du
aber vielleicht bei einem falschen Passwort oder falschen
Usernamen falsche Kombination. Irgendwie eine Nachricht
bekommst. Sorry, aber Username oder
Passwort ist falsch, dann weißt du OK, einerseits entweder ich
komme rein mit den richtigen Credentials oder mit den
Falschen komme ich nicht rein, das heißt du kannst dich gut
reinversetzen, diese Story abnehmen und gucken ob der Wert
auch wirklich geschaffen wurde und das ist dann halt perfekt
und ich finde da kommen wir auch an einen ganz interessanten
Punkt, weil wie also wie kann man denn jetzt zum Beispiel
gucken, dass man eben. Dass diese User Story auch
umgesetzt wurde und da gibt es ja so die ich sag mal diesen
diesen Begriff akzeptanzkriterien so ne ja,
also im Prinzip akzeptanzkriterien sind dafür da
um klare Bedingungen zu schaffen, wann denn diese Story
fertig ist, also wann es ist ja als Entwickler wichtig zu wissen
wann. Bin ich mit der Story fertig?
Wann habe ich meine Arbeit getan, was muss alles umgesetzt
werden und sobald Spielraum in der Beschreibung kommt,
reinkommt, also dass jeder ein anderes Verständnis davon hat,
dann können so eine Stories halt in so unendliche gehen gefühlt
und manchmal tun sie es auch, also weil ja nee, ich hätte
jetzt gedacht, das und das muss da rein, ja okay dann machen wir
das noch rein ja aber ich verstehe das so und so, wir
müssten das und das noch machen. Ja, OK, dann bauen wir das auch
noch ein. So und dann ist es so ne Never
ending Story und da kommen halt akzeptanzkriterien.
Ins Spiel User Story. Ja ha, ha ha.
Und da kommen halt diese Kriterien ins Spiel, weil sie
helfen ganz klar zu definieren, was muss getan werden, damit
dieser Value geschaffen wird am Ende und.
Du hast es auch jetzt schon angerissen.
Es ist halt auch super hilfreich um das Ganze zu Reviewen am
Ende, also quasi wenn einer das abnimmt, diese Story, dieses
Ticket, dann hat er auch klare Kriterien, was muss ich denn
machen um zu sehen ob alles funktioniert?
Nehmen wir noch mal dein Beispiel mit dem Einloggen.
Ja okay ich nehme meine Credentials so, ich gebe das da
ein Username Passwort was war denn username fabi 1234 ne?
Passwort 1234 drück Login, drück Login ah ja hier mein
persönlicher Bereich funktioniert so und ich bin
sogar mit meinem User drin. Ich hab nicht irgendeinen
anderen gerade weißt du funktioniert alles so ausloggen
ja jetzt mach ich fabi 1234 und gib ein anderes Passwort ein Ah
ja geht nicht, dann war mein richtiges Passwort fabi 1324
geht auch nicht ja gut okay. Das waren so die Kriterien.
Funktioniert Ticket abgeschlossen, also user Story
erfüllt genau und das kann man ja auch als nicht technische
Person, sogar als nicht, nicht mal als Person, die super
vertraut mit allem ist. Also die wirklich jedes Detail
kennt, das sind ja so Kriterien, da kannst du sagen Ey auch
Person xy, magst du das vielleicht mal testen?
Genau, weil es ist ja eine wie eine Art Fahrplan, nach der du
dich durchhangeln kannst, um zu gucken, ob der Wert der in
dieser User Story beschrieben ist, auch wirklich vorhanden
ist. Nach der Implementierung genau,
und das ist halt einfach unglaublich wertvoll und ich
finde es unglaublich gut, dass du sagst, es braucht kein, wenn
du eine User Story gut schreibst, braucht es kein
technisches Verständnis um zu verifizieren, dass es
funktioniert, dass der Wert geschaffen wurde und.
Ja, genau. Das heißt, du hast diese
Akzeptanzkriterien. Du hast vorher den den den
Rahmen geschaffen, mit der anderen Struktur, also ich als
Rolle, dann hast du diese 2 Sachen und das ist in meinen
Augen der Frame, den ich mit einer User Story schaffen
möchte, das heißt ich ich definiere aus welcher Sicht
möchte ich was machen und warum und dann definiere ich mit Hilfe
von Akzeptanzkriterien wie das Ganze.
Als erfüllt gilt sozusagen genau also bei Akzeptanzkriterien gibt
es ja tatsächlich mehrere Möglichkeiten, das irgendwie
darzulegen. Also du kannst ja zum Beispiel
sowas machen wie Definition of dann beziehungsweise so ne Art
Liste, wo du so tasklisten genau sowas in die Richtung und
verschiedenste Möglichkeiten. Die man da irgendwie nutzen kann
und eine, die wir ja ganz besonders gerne nutzen, ist die
sogenannte gerkin Schreibweise. Da geht es ja wirklich darum um
um also kurz gesagt, du hast so ne Art given, so ne Art wenn und
so ne Art, wenn ne Given ist im Endeffekt der Ausgangszustand
ein einer Story oder der Kontext in dem wir uns gerade bewegen,
das bedeutet also in dem Beispiel was wir vorhin hatten,
dass man sagt, OK, ich als User bin sozusagen nicht
authentifiziert auf meiner Seite.
Irgendwie so was als Beispiel so, das ist erstmal so der Frame
so das ist das Given. Also erstmal du weißt ja ich als
User und dann brauchst du nicht mehr sagen, ich als User kannst
du noch sagen given ich bin auf der Startseite so was als
Beispiel, dann gehst du weiter und sagst okay wenn das ist dann
das auslösende Ereignis oder diese Aktion die getätigt wird,
das ist im Endeffekt ich gebe mein also wenn ich meine mein
Username und Passwort korrekt eingebe.
So und dann, wenn das ist sozusagen dann das erwartende
Ereignis oder das Verhalten, also wenn ich quasi auf den
Knopf sign in drücke, dann erwarte ich halt im Endeffekt
auch, dass ich eingeloggt bin auf meinem Dashboard, dass ich
mein Dashboard sehe, also einmal noch mal kurz zusammengefasst
given ich bin auf der Startseite, wenn ich meinen
Username und Passwort korrekt eingebe und auf sign in drücke
dann. Dann also dann bin ich auf
meinem Dashboard in meinem user Bereich, was auch immer und das
ist kann man sich natürlich hinstellen und sagen okay das
ist jetzt ein Akzeptanzkriterium es hindert eigentlich daran noch
ein zweites Akzeptanzkriterium zu nehmen und zu sagen okay wenn
ich auf der Startseite bin und ich gebe zum Beispiel meinen
richtigen Usernamen ein, aber ein falsches Passwort und ich
drücke auf sign in, dann kriege ich eine Fehlermeldung genauso
andersrum. Wenn ich halt eben dann meinen
falschen Username und richtiges Passwort theoretisch eingebe.
Ne, also man kann das auch in 3 User, also in 3
akzeptanzkriterien gliedern. Du hast vielleicht das gleiche
Given, aber es macht die Sache nicht nicht schlimm an der
Sache, also an dieser Stelle ne. Also ich würde jetzt zum
Beispiel nicht mich hinstellen und sagen, ja, du hast doch
dreimal das gleiche Given, also kannst du das optimieren, so das
sind 3 Akzeptanzkriterien schreibst sie genauso runter und
dann kann man das auch. Sage ich jetzt mal autark
abarbeiten. Ja, und wenn du halt immer die
gleiche Schreibweise verwendest, wirst du über die Erfahrung
hinweg also umso länger du damit arbeitest, sie auch immer
schneller lesen und verstehen können, weil du halt genau
weißt, in der Zeile steht jetzt die Bedingungen sozusagen oder
die, nee sage ich mal die Grundlage dann, was mache ich
und was erwarte ich dann sozusagen.
Also es ist halt genau das, was du beschrieben hast.
Und das ganze, du hast es in deinen Sätzen eingebaut, ist
aber von von der Schreibweise her auch völlig in Ordnung, dass
Du mit End arbeitest um einfach auch Verknüpfung zu schaffen
beispielsweise. Given der Teil.
Ich bin auf der Startseite und bin auch ein registrierter
Nutzer, könnte man dann zum Beispiel machen, weil du hast ja
theoretisch auch das Akzeptanzkriterium jemand der
nicht registriert ist, sollte nicht willkürlich irgendwas
eingeben können um sich einzuloggen und auf irgendeinen
Dashboard zu kommen, beispielsweise nur mal jetzt als
Beispiel, dass du Verknüpfung schaffen kannst, was auch gang
und gäbe ist. Genau du musst halt gucken, dass
es nicht ausartet, das ist halt sag ich mal given.
Bedingung A und Bedingung B und Bedingung C und Bedingung D und
so weiter bis z Ich warte kurz, da kann dir das gedanklich
weitermachen, weil das spricht schon wieder, dafür.
Ist das wirklich ein Akzeptanzkriterium oder was für
ne Abhängigkeiten sind da gerade bitte drin?
Das lädt schon wieder ein das Ganze noch mal zu durchdenken,
aber so 12 NS kannst du da machen, warum nicht?
Das liest sich ja trotzdem noch schnell und schafft halt auch
diesen Rahmen für diese Akzeptanz.
Um das schnell zu verstehen. Im Endeffekt greift ja da so
eine goldene Regel, dass du sagst, du brauchst genug Details
um halt eben mit der Story sozusagen zu starten, aber nicht
zu viel, dass es total überladen ist, dass du dir eigentlich
wieder eine Art Pseudocode aufbaust, wo du dann ewige
Verschachtelung drin hast. Und das ist n sehr wichtiger
Punkt, dass du sagen kannst, es sind genug Details um zu
starten, weil wir gehen jetzt mal davon aus, wir sind halt in
einem agilen in sag ich mal in einem agilen Umfeld und da gibt
es ja auch zum Beispiel nach Scrum Termine wie Refinements,
das heißt, sollte da vielleicht in Zukunft bei diesem Ticket
doch noch was unklar sein? Genau dafür sind ja auch
Refinements da am Ende ne. Also das Ziel ist ja nicht zu
sagen, ich schreib das Ticket so voll, da ist kein.
Kein Platz mehr, kein Finger breit, mehr Luft an Spielraum
sozusagen, sondern es ist so gesehen klar, was gemacht werden
muss. Und es ist aber auch
wahrscheinlich, dass im Laufe der Arbeit man sich denkt, so,
ja, warte mal. Aber den Fall haben wir jetzt
gar nicht berücksichtigt, und das ist völlig OK, weil dafür
gibt es auch refinance, dann gehst du halt noch mal ins Team
oder in Huddle, also du musst, musst ja auch nicht auf n
refinance Termin warten, aber du kannst es ja einfach
nachträglich diskutieren und das Ticket auch noch anpassen.
Definitiv. So kannst du auch eine
Akzeptanzkriterium hinzufügen. Alles ganz Stress.
Und was auf jeden Fall zum Beispiel, ich finde dein
Beispiel gerade ganz cool, dass du gesagt hast, ich als
registrierter Nutzer, zum Beispiel, dass du dann halt
sozusagen diesen Frame schaffst und sagst, du kannst dich
logischerweise nur anmelden, wenn du auch registriert bist.
Und wenn man jetzt vielleicht auf die Idee kommt und sagt, Na
gut, dann erweitere ich diese Story, die da heißt, user, was
weiß ich. Sign in and sign sign oder so
ne. Also dass du dich registrierst,
also die sozusagen Registrierungen und nennen wir
es mal User Management und du willst jetzt eine Story
schreiben wo du drin sagst so wenn ich nicht authentifiziert
bin und dann muss ich quasi meine E Mail oder meinen
Usernamen und mein Passwort eingeben und bin dann
registriert und wenn ich aber registriert bin, dann kann ich
quasi mit meinem kann ich meinen Usernamen und mein Passwort
eingeben und dann komme ich rein so ja.
Wenn man jetzt auf die Idee kommt und sagt, gut klar, dann
erweitere ich meine Akzeptanz, Kriterien, dann gibt es an der
Stelle halt eben auch wie gesagt den Kontext, weil an dieser
Stelle kann man sich hinstellen und sagen, warte mal, wir, wir
schaffen ja hier 2 Werte, also 2 values an dieser Stelle einmal
die Registrierung und einmal den Login, das sind ja 2 einzelne
Dinge, die unabhängig voneinander.
Funktionieren können. Also können Sie auch unabhängig
in 2 verschiedene User Stories rein.
Ganz genau. So, und das ist halt auch ein
wichtiger Punkt, den man an der Stelle berücksichtigen sollte,
weil wie gesagt, man sollte darauf achten bei einer User
Story möglichst kleine Pakete zu schnüren, die in sich
funktionieren. Die halt diesen Wert schaffen,
aber trotzdem irgendwo autark abhandelbar sind.
Finde ich ist ein super Beispiel oder?
Beziehungsweise ein sehr sehr guter Hinweis an der Stelle eine
Sache noch bevor wir mal so quasi die Formalitäten
abschließen. Wir haben ja gesagt in so einer
User Story sollte das ganze nicht technisch betrachtet
werden, sondern aus fachlicher Sicht absolut richtig.
Ich finde Ausnahmen bestätigen die Regel und nur deswegen noch
mal ganz kurz als Anmerkung. Wenn man jetzt die User Story so
aufbaut, wie wir es gerade zum Beispiel vorschlagen oder was
auch so gängig ist, wir auch verwenden, dass ich sage, ich
baue mir dieses Szenario auf mit dieser Nutzerrolle und was
möchte er warum machen der Nutzer oder die Nutzerin dann
die Akzeptanzkriterien, dann kann ich, wenn es wirklich
notwendig ist und nicht standardmäßig, deswegen
optional. Gibt es Anmerkungen zu dieser
Story? Irgendwas Wichtiges, zum
Beispiel auch UIUX, mäßiges oder irgendeine technische
Abhängigkeit? Doch also also doch ne
technische Abhängigkeit so rum, dann kann ich unten natürlich
noch optional Anmerkungen hinschreiben, auch von von
Entwickler zu Entwickler beispielsweise, das ist
vollkommen legitim, sollte aber halt nicht diese goldene Regel.
Du hast so schön goldene Regel genannt.
Super, wenn ich jetzt auch verletzen, dass ich die komplett
überlade, dass ich da einfach alles reinknalle und noch e
Mails in Anhang packe und Diskussion und n Chatverlauf
noch rein weißt du das sollte es halt nicht verletzen.
Wenn es aber wirklich aus Erfahrung oder aus der Sicht
eines Entwicklers beispielsweise sehr wichtig ist, das da
anzumerken, dann kann ich da unten natürlich sowas auch
reinschreiben, wenn es dem Entwickler, der das später oder
Entwicklerin die das später bearbeitet hilft.
Um nicht vielleicht in eine Falle zu tappen, in der
Entwicklung oder so. Dann lieber reinschreiben
deswegen. Also es gibt für mich gedanklich
immer noch so einen optionalen Blog, den ich nicht oft
verwende, aber es kann sein, dass es angebracht.
Ist also ich finde ein kleines Beispiel was was mir jetzt so
spontan einfällt wäre, man entwickelt irgendwas und es
werden vielleicht innerhalb dieser user Stories vielleicht
du weißt eigentlich, das ist eine Sache, die.
Zwar rein theoretisch sehr technisch ist, aber du weißt
jetzt schon, du kommst nicht drum herum, dass zum Beispiel
irgendwie n file generiert wird oder irgendwas, was da hinterher
irgendwie raus ploppt und du sagst so OK, es wäre nicht cool,
wenn das jetzt beispielsweise irgendwie im Git repository
landet, also kann man in die Note zum Beispiel schreiben, ja
denkt man dran, dass man da dieses File oder dieses, was da
irgendwie generiert wird, dass das auf die Git ignore kommt,
weil ansonsten kommen wir das permanent immer mit rein, so ne
also. Weiß nicht, vielleicht gibt es
auch noch bessere Beispiele, dass es mir spontan geht, aber
das ist genau so eine Kleinigkeit, was ja technisch
ist. Das ist ja dem Endanwender egal,
wie das Repository verwaltet ist, aber das kann den
Entwicklern halt helfen. Es kann halt auch sein, dass du
sagst, Hey, das ist das die und die User Story klingt erstmal
trivial, aber mir ist jetzt schon klar, dass wir in
irgendeiner Schnittstelle ein Breaking Change haben, das
heißt, dass wirklich Sachen. Migriert werden müssen oder
whatever wenn du sowas reinschreibst, dass du einfach
schon so ne so ne so ne awareness schaffst, sag ich mal
ne, dass alles schon mal darauf, also dass allen bewusst ist.
Ey, das wird hier an der Stelle, müssen wir da und da aufpassen,
dann ist das n guter Hinweis auch in so einer Story.
Aber ich mein oder ein? Ticket genau.
Also wenn man jetzt zum Beispiel gerade zuhört und sich denkt,
ja, Moment, aber warte mal, also wir reden davon, dass jetzt zum
Beispiel Entwicklerinnen und Entwicklerin nicht diese Story
schreibt, weil das nicht die Aufgabe von Entwickler oder
Entwicklerin ist, sondern zum Beispiel Aufgabe von PO, diese
Stories zu schreiben, dann könnte man sich ja fragen, wie
soll jetzt der PO eventuell irgendwie diese technischen, das
technische Wissen haben, vielleicht hat er sie, hat er es
aber vielleicht auch nicht. An der Stelle würde ich jetzt
noch mal kurz anmerken, wie du meintest, man ist im Refinement,
man redet darüber, man definiert dieses Ticket ja und sagt Okay
Pass auf, darüber sprechen wir, wir schaffen ein einheitliches
Verständnis über dieses Ticket, dann wird das auch noch
geschätzt. Thema schätzen hatten wir eine
Folge, hört da gerne mal rein liebe zürerin lieber Zürer an
dieser Stelle. Kann man ja zum Beispiel an den
Punkt kommen, dass man sagt, ja ne Breaking Changes, da müssen
wir auf jeden Fall drauf achten und dann kann man ja zusammen in
diesem Termin, in diesem, in dieser Zusammenkunft einfach mal
kurz Notes drunter schreiben oder vielleicht auch n Kommentar
drunter packen, je nachdem wie das System mit dem man arbeitet
aufgebaut ist. Aber das kann man ja an der
Stelle machen, ne? Ja, sehr guter Hinweis, weil
genau das ist der der Punkt, wo man denn sagen kann, OK nee, das
definieren wir da jetzt noch mit rein oder hinterlegen das da.
Weil es wirklich auch mehr Wert schafft, um es schneller
entwickeln zu können oder Fehler zu vermeiden.
Ganz klar ja. Guter Hinweis, ganz klar ist so
n refinement Thema sehr oft oder auch aus eigener Erfahrung kommt
sowas denn eher in n Refinement dazu?
Ja, ja, jetzt. Haben wir ja viel Formales
besprochen, wie wir sie aufbauen würden, was auch so gängig ist.
Also die haben uns das ja nicht selbst ausgedacht, sondern.
Es gibt dieses Format, sage ich mal, user Stories so zu
schreiben und wir haben es ausprobiert.
Wir verwenden es und für Gute, Wir haben es für gute Befunde
und nutzen es deswegen auch, aber lass uns noch mal so ein
bisschen differenzieren, was wirklich jetzt also zu Take Home
message mäßig was so Best practices sind und was eine gute
User Story ist. Und da würde ich noch mal.
Sehr allgemein anfangen bevor wir so zu richtig spezifischen
Do's and Don's kommen okay dann möchte ich dann warte, da möchte
ich noch mal den ersten direkt bringen.
User Stories haben Fachlichkeiten beschrieben und
keine technischen Details. Ja das ganz oben ganz oben, weil
das ist mit Schrift, das ist mir wirklich wichtig, weil der
Herzensangst, da habe ich auf jeden Fall auch schon einige
Erfahrungen gemacht, dass das nicht so gehandhabt wird und
dann? Kommst du auf einmal in
Diskussionen mit Leuten, die technisch vielleicht wirklich
gar nichts damit zu tun haben beziehungsweise aber auch
wirklich auch nicht die Verantwortung technisch dafür
übernehmen müssen? Und dann denke ich mir mal,
wieso sollte jemand, der nicht die Verantwortung über die
technische Seite hat, auf einmal vorgeben wollen, wie es
technisch umzusetzen ist? So, da muss man halt auch
wirklich die Verantwortlichkeiten an der
Stelle lassen, wo sie sind und das Entwicklerteam wurde dafür
eingestellt um die Software zu entwickeln, also Expertise.
Technisch softwareentwicklungsteam.
Ja, sehr gut, wirklich. Wie gesagt in Leuchtschrift
oben, das ist, das scheint ja sehr wichtig zu sein, ist es
auch wirklich und da habe ich auch sehr schlechte Erfahrungen
mit gemacht, gerade so aus der Zeit der typischen Anforderungen
von früher so Lastenhefte, aber die Punkte, die wir also gefühlt
eigentlich schon. Meine ich alle, die wir jetzt
angesprochen haben, kann man für alle Theorie Fans jetzt unter
den Zuhörerinnen und Zuhörern kann man in ein Modell kippen
oder wurde auch mal als Modell definiert.
So typisch wieder ein Wort mit Abkürzung was du verwenden
kannst um dir das zu merken. So eine Eselsbrücke nennt man
das Glaube ich Eselsbrücke und zwar das Invest Schema oder
Modell so Invest. Da haben wir am Anfang ein I.
Und das steht für Independent, und das ist genau der Punkt, den
Du am Anfang oder relativ in der Mitte ist.
Schon n bisschen her jetzt genannt hattest.
Und zwar trenn doch Registrierung von einloggen, das
sind doch 2 User Stories und das hast du ja auch gut beschrieben
und genau das ist es auch, was mit unter Independent steht.
Sie können einzeln stehend und alleine umgesetzt werden, also
sie sind in sich beschrieben und autark und man kann sich diese
Story nehmen und sie so wie sie ist umsetzen.
Ja, und das ist n sehr wichtiger Punkt.
Wenn du nämlich das nicht schaffst und du hast Dependency
zwischen diesen ganzen User Stories, dann wird es richtig
wild. Welche wirst du als erstes
abarbeiten? Du fängst eine an erwarte hier
komm ich nicht weiter, ich muss ja jetzt erstmal die andere user
Story machen und dann baust du dir so ein Netz an Verwirrtheit
auf. Man muss halt dazu, man muss
halt dazu sagen, also. Unabhängig umzusetzen sind beide
definitiv und darum geht es ja vor allem.
Das heißt, du hast du Blockst mit der einen Story nicht die
Entwicklung der anderen Story wichtiger Punkt, klar kann man
an der Stelle sagen, wenn du die Login Story abgeschlossen
hättest und jetzt zum Beispiel unabhängig Po rein fachlich
überprüfen möchte ob man sich anmelden kann, dann geht das
natürlich nur mit der Registrierung, also mit
vorheriger Registrierung. Ne rein theoretisch, das heißt
die Abnahme kann sonst erstmal nicht erfolgen, aber auch da
kann man sich natürlich behilflich sein, ne und in zum
Beispiel einer Test Stage sagen oder einer Development Stage wie
man sie nennen mag, dass man halt irgendwie auch schon Test
User anlegt wo man sagt Login funktioniert damit ne.
Also guter guter Einwand, ich wollte es nur mal sagen, weil
man kann sich natürlich sofort hinstellen und sagen ja, aber
Login geht ohne Registrierung nicht.
Ist ja auch, also. Man kann ja auch das nicht immer
vermeiden. Es geht ja jetzt darum, was sind
gute User Stories, also was ist mein Ziel, wie ich Sie aufsetzen
möchte und natürlich hast du auch blocker, dass zum Beispiel
User Story B niemals ohne User Story a funktionieren kann beim
Endanwender und da kann man sich dann halt mit geschaffenen
Umgebungen quasi helfen, wie du es gerade so schön gesagt hast,
um doch das autark entwickeln zu können, ist nicht so, dass es
nicht geht, genau. So genau dann.
Was haben wir als Nächstes das n ne go to go, das ist ein
komisches Wort, ja ich bin da, weil es gibt so Wörter da da na
ja, aber es war halbwegs richtig und zwar Details sind klärbar
aber nicht in Stein gemeißelt und das ist auch n Punkt den wir
angesprochen haben, das ist ein lebendes.
Wie soll ich sagen, also eine User Story lebt, sie entwickelt
sich weiter, sie kann auch mal umdefiniert werden, es gibt
Refinance, das heißt es ist nicht in Stein gemeißelt wo wir
wieder Thema Lastenheft sind oder so ey hier das machst du
jetzt und in 3 Monaten komm ich wieder und dann läuft dies alles
klar weißt du also das ist halt auch n wichtiger Punkt den man
einfach von vom Mindset her mit sich tragen sollte ja vor allem
was ich auch oft erlebt habe, in diesem Punkt ist, dass du
natürlich ne. Idee hast die von einem
Stakeholder kommt und dann heißt es ich würde gerne oder in
dieser Anwendung wollen wir gerne das und das haben okay wie
wollt ihr das haben so und so okay du fängst anders zu
entwickeln und merkst wir haben hier ein Edge Case das
funktioniert nicht ganz hundertprozentig so wir müssen
vielleicht einen Kompromiss machen und dann ist genau der
Punkt. Es ist nicht in Stein gemeißelt,
sondern man muss natürlich dann noch mal, vielleicht unter
Umständen, in den Austausch gehen.
Im optimalen Fall logischerweise beim Refinement, bei der
Besprechung dabei, dass man das so schon auf dem Schirm hat,
aber Ausnahme steht ihnen ja, wie gesagt, die Regeln.
Es kann sein, dass du halt mal an den Punkt kommst, wo du
sagst, ich hab schon angefangen zu entwickeln und jetzt fällt
mir das erst auf, kommt ab und an mal vor und da ist es
natürlich sehr wichtig, dass es eben nicht in Stein gemeißelt
ist, sondern dass man sagen kann, OK, wir haben Spielraum.
Weil ansonsten wir bringen die sonst einfach ja absolut, dann
haben wir. INV also valuable.
Das hatten wir auch schon mehrfach.
Genau das muss halt n Mehrwert geben, das ist das ganz große
Ziel dahinter, da braucht man nichts weiter zu sagen
eigentlich. Dieser sogenannte User.
Value genau das E für Astonable das ist im Prinzip, dass der
Aufwand auch Schätzbar ist. Und da kommen auch die.
Genau diese Schreibweise, für mich persönlich immer ins Spiel,
wenn ich diese givenwhere than Schreibweise hab, hab ich schon
viel klareres Verständnis über die Akzeptanzkriterien und wie
am Ende dieses Feature in der Software aussehen soll,
inklusive des Szenarios wer möchte was machen und warum und
das hilft um auch so Aufwände einfach besser schätzen zu
können um überhaupt erstmal n. Gefühl für diese User Story zu
kriegen. Und deswegen hilft diese
Schreibweise quasi, um eine gute User Story und diesem Modell
gerecht zu werden. Quasi eine gute User Story zu
schreiben. Also ich finde, dass ich so von
kurz, kurz und knapp der Ablauf, es gibt diese User Story mit den
Akzeptanzkriterien und die werden kurz besprochen, jeder
Entwickler, jede Entwicklerin hört das es fängt an zu rattern,
man geht gedanklich in den Code, wie setzt sich es um, was muss
ich machen, welche Sachen fasse ich an, das geht eigentlich bei
mir immer sofort los und dann ist kriegst du eigentlich
relativ gut so zusammengefasst. OK, jetzt kann ich das ungefähr
schätzen, dass du halt auch irgendwie, dass du so weit an
diesem Thema dran bist, dass du auch damit arbeiten kannst und
sagen kannst, ja, ich glaube ungefähr so Schätzung XY ne,
also was nicht schätzbar wäre wäre zu sagen ich möchte ne
Anwendung für die das und das macht was schätzt du?
Denke. So, ja was soll ich da?
Schätzen und gefühlt kriegt man manchmal so ne Titel.
Ja, also wohlgemerkt an der Stelle, dass es nicht um
zeitliche Schätzung, sondern Komplexität geht.
Also da helfen halt diese Akzeptanzkriterien, um überhaupt
mal die Komplexität dieser User Story abschätzen zu.
Können. Genau so.
Dann haben wir noch die Buchstaben S und T bei Invest.
Die letzten meinen S steht für Small, das ist denke ich auch
hin hinblicklich unserer goldenen Regel.
Ich find goldene Regel super klasse, dass du es so genannt
hast. Dass man halt sagt, OK, es muss
halt auch umsetzbar sein, beispielsweise innerhalb eines
Sprints. Also es darf jetzt nicht so ne
Never ending Story werden, kleiner Anzug, kleiner Anzug,
kleiner Anzug, wenn n Sprint 4 Wochen dauert, dann ist es nicht
gut irgend ne user Story zu haben, die auch wirklich 4
Wochen dauert. Also ich sag mal so, ich
persönlich bin bisher mal gut gefahren, wenn man es wirklich
hinkriegt zu sagen ein bis 3 Tage.
Wenn das so umfasst, wenn das das umfasst, eine Story, dann
ist es eine gute Story. Ja, da kommen wir in ganz andere
Bereiche jetzt, weil ein Sprint sollte in meinen Augen keine 4
Wochen dauern, aber da gibt es auch Leute, die haben andere
Meinungen, sehe ich ja, es ist halt immer, es ist halt immer
eine Frage wie lange ist dieser Sprint, es sollte sagen wir mal
so, es sollte definitiv nicht. Über ne Sprintlänge gehen die
wir für gut finden. Ein bis 2 Wochen sagen wir mal 2
Wochen, jetzt dann auf keinen Fall, dass es über 2 Wochen
geht, das 1 bis 3 Tage was du meinst gehe ich mit weil es den
anderen Punkten wieder in die Karten spielt, zum Beispiel
schätzbarkeit du kannst Sachen aus meiner Sicht nicht schätzen,
wenn du schon bei 23 Wochen Aufwand bist, dann kann dann
wird es halt viel zu ungenau. Das Ding ist außerdem bist du da
wieder bei Zeit am Ende? Egal.
Das hatten wir alles schon mal besprochen.
Liebe Zuhörer, liebe Zuhörer, was ich eigentlich nur meine
ist, es kommt ja gerne mal zu dem Punkt, dass man sich dann
also vielleicht denkt sich jetzt irgendjemand was ein Tag, ne
Story niemals gar auf gar keinen Fall, das kann nicht
funktionieren, so okay lass mal sacken, probier doch einfach mal
zu sagen, was müsste man tun damit es geht und nicht zu
sagen. Nö, geht nicht.
Das ist das ist Bullshit, das ist Blasphemie, also also
sozusagen einfach mal kurz zu den die Perspektive zu wechseln,
auch wenn man vielleicht dann am Ende dazu kommt, so, es wird
wirklich schwierig, OK, aber man hat zumindest mal seinen seine
Gedanken, seinen Gedanken in Anstoß gegeben, in die
vielleicht in die richtige Richtung.
Ja. Und ja, dann der letzte
Buchstabe noch zum Abschluss testable ja, die klaren
Akzeptanzkriterien helfen natürlich, um beispielsweise das
Ticket abzunehmen oder zu reviewen, dass man sagt, OK, ich
probier jetzt dieses Szenario durch die funktionieren.
OK, es ist für mich getestet. Ich hab dieses Feature
ausprobiert, es funktioniert und damit ist die User Story dann
auch abgeschlossen. Testable ist übrigens n richtig
guter Punkt, weil du kannst wenn du sagst ey ich hab hier zum
Beispiel n Akzeptanzkriterium mit diesem Given ran zen.
Kannst du rein theoretisch ein Akzeptanz Kriterium in einen
Test in deiner Software in einen automatisierten Test gießen um
zu sagen ich nehme jetzt das, packe das in einen Test und dann
hast du 2 Sachen abgedeckt? Erstens hast du ein Test dafür
für dein Akzeptanzkriterium automatisiert in der Pipeline
laufen irgendwann hoffentlich Punkt 1.2 was auch super geil
ist. Ist, dass du am Ende auch
wirklich eigentlich in deinen Tests lesen kannst.
Was soll denn die Anwendung können?
Weil du ja eigentlich jedes Akzeptanzkriterium irgendwo
abgebildet hast in deinen Tests Code Dokumentation für
Entwicklerebene. Ja, absolut.
Also das hilft dir natürlich auch überhaupt, deine Tests
dementsprechend gut zu gestalten.
Ja. Ja, da würde ich sagen, das war
so das Invest Modell was noch mal kurz und knapp
zusammenfasst, was wir so hier ausführlich besprochen haben.
Zu den Best Practices würde ich auch noch mal ganz kurz
zusammenfassen, was aus unserer Sicht jetzt so Do's and Don't
sind, also Do's auf jeden Fall Personas nutzen um die Sicht des
Endbenutzers zu verstehen wie du anfangs meintest ich als Nutzer
der Seite, ich als Admin. Und so weiter.
Es muss immer gemessen werden. Was ist der Erfolg dieser Story,
also was ist der Mehrwert und was muss erledigt werden, damit
dieser Mehrwert eintritt, ist für mich so ein ganz wichtiger
Punkt ist warum, warum mache ich das hier eigentlich und damit
meine ich nicht, dass man morgens bei 09:00 Uhr beim
Kaffee sitzen sich denkt, warum bin ich eigentlich hier, nein,
sondern warum diese User? Story.
Dann hatten wir noch den Punkt, den wir aus eigener Erfahrung
kennen, dass Refinance da einfach auch reinspielen und
wichtig sind, regelmäßig zu refinen, weil Tickets leben,
also Tickets, also user Stories, die Leben.
Sie können sich ändern, es kann in der Entwicklung können noch
Sachen auffallen, dass zum Beispiel Akzeptanzkriterien
nicht bedacht wurden, man kann nicht immer alle Fälle gerade so
Edge Cases nicht im Kopf haben und deswegen so User Stories
leben und können Refined werden Feedback auch ne ganz wichtige
Sache. Das haben wir jetzt so indirekt
besprochen, auch durch Refinement zum Beispiel, oder
also angenommen, der PO schreibt dir jetzt dieses Ticket und er
macht es wirklich gut, dann erwartet er ja trotzdem auch so
Feedback, beispielsweise vom vom Entwickler in die Richtung oder
auch Richtung Stakeholder wieder hey hier die User Stories
umgesetzt und so weiter da sind wir dann in der Feedbackkultur.
Auch Edge würde ich noch Edge Cases.
Zurückspiegeln ist auch gut, weil dann.
Bildet vielleicht auch sozusagen die Seite der Stakeholder auch n
Verständnis dafür zu sagen oder NN Gespür dafür zu sagen, OK
Moment, warte mal, wir hatten jetzt in der Vergangenheit immer
mal so n paar Edgecases, das sollten wir in Zukunft auch
gucken, dass wir vielleicht sowas auch mit ins ganz.
Genau ziehen ne genau und das Zurückzuspiegeln hast du recht,
ist ne ist halt genau diese Feedbackkultur die unfassbar
wichtig ist. Ja, und ganz wichtig noch die
Abhängigkeit minimieren. Man kann sie nicht immer
vollständig eliminieren, aber sie sollten sehr gering gehalten
werden und es gibt Möglichkeiten trotzdem User Stories autark
behandeln zu können, beispielsweise hey ja, ich kann
mich nicht registrieren wie du meintest, ja, aber ich kann
trotzdem das Login implementieren, indem ich
einfach Dummy user hab die Regel als registriert gelten sozusagen
und dann brauche ich nicht die Funktionalität mich registrieren
zu können. Ja, das sind so die Do's, würde
ich sagen. Die Don't sind aber fast noch
wichtiger und da ganz als allererstes, weil du es mehrfach
genannt hast. Die Leuchtschrift, die
Leuchtschrift, das größte Don't ist technische Details, wenn es
eigentlich darum geht fachlich zu beschreiben, was die Story
ist. Dahinter also nicht sagen, der
User XY würde sich sehr gerne auf der Seite einloggen, aber
mit dem Authentifizierungsverfahren.
Das macht halt keinen Sinn und das gehört da auch nicht rein.
Das erschwert nur das Ticket abzuarbeiten ist überhaupt zu
verstehen, es bläht so n Ticket extrem auf wie wir gesagt haben
und das ist einfach keine gute Practice.
Als nächstes könnt ich ja kurz weitermachen, dass man zum
Beispiel Stories nicht zu groß macht.
So also man spielt da quasi wieder mit rein, genau, also
nicht zu viel reinballern und was auch wichtig ist, Stories
sollten ne gewisse Struktur haben.
Weil es bringt nichts, wenn du sagst, ich Klatsch jetzt einmal,
wie ich am Anfang meinte, einfach so ne Mail, irgendwie
werf ich über n Zaun und dann so mach mal hier wird schon
irgendwie hinhauen, das führt meistens eigentlich würde ich
sagen zu 100 und ein Prozent immer dazu, dass es nicht gut
funktioniert und das am Ende einfach viel zu viel Zeit ins
Land fließt um diese Aufgabe im Endeffekt abzuschließen, ja.
Genau dann wichtig ist auch, Stories ohne Nutzen zu
formulieren. An der Stelle muss man immer
gucken, okay welchen Wert bietet diese Story, weil wenn du am
Ende irgendwas schreibst, was wo man sich so denkt, so okay die
Anwendung mit oder ohne ist eigentlich völlig Käse, was
bringt mir das, bietet keinen Wert, bietet die Story keinen
Wert, ist es kein user Story man kann differenzieren finde ich
zwischen sogenannten Chaws wie ich das kenne das sind.
Auch Aufgaben, die kein User Value bringen, die aber
technisch sozusagen die Anwendung verbessern.
Also wenn du zum Beispiel eine gewisse Art von Refactoring hast
oder deine Architektur so umstellst, dass du zum Beispiel
schnellere Verarbeitungszeiten hast oder keine Ahnung, deine
Architektur, die du verwendest, nur noch die Hälfte kostet oder
was auch immer, solche Dinge die Anwendung macht genau das
gleiche wie vorher. Der User merkt davon aber
nichts, aber es ist quasi technisch optimiert so.
Aber das sind zum Beispiel auch Aufgaben, die definitiv
natürlich vom Entwicklerteam geschrieben werden und ich kenne
das in dem Sinne keine keine User Stories, so wie wir sie
hier definieren, genau und ansonsten vielleicht noch der
letzte Punkt, dass man eben nicht.
Sag ich jetzt mal akzeptanzkriterien so
verwurstelt, dass man sie eigentlich gar nicht richtig
reviewen kann, dass man irgendwie nicht in der Lage ist
Herauszukristallisieren oder diese Testbarkeit zu haben um zu
sagen, OK was also man sollte immer gucken, ne, wie kann man
denn zum Beispiel auch aus nicht technischer Sicht ne Story
abnehmen und wenn man das jetzt in Don't packt, muss man einfach
die Akzeptanzkriterien sollte man nicht schwammig formulieren.
Ja oder gar keine haben ja. Wäre auch nicht so gut.
Ja genau das sind so das noch mal knapp zusammengefasst, also
schnell zusammengefasst. Der Inhalt der heutigen Folge
der heutigen Folge meine Güte so, deswegen würde ich sagen,
würde ich jetzt auch die Folge beenden.
Wir haben jetzt auch schon ne sehr fortgeschrittene Zeit, weil
das Thema einfach so wichtig ist und so umfangreich, man könnte
mehrere Folgen da drüber machen und ich hoffe, dass wir dem auch
gerecht geworden sind, auch noch mal liebe Grüße an Veronika.
Und ja, es hat mir mega viel Spaß gemacht und vielen Dank für
das für den Austausch. Ja dann würde ich sagen, bleibt
mir nichts anderes über als die Folge zu beenden und deswegen,
liebe Zuhörer, liebe Zuhörer, falls du Feedback hast, Fragen
oder auch Anmerkungen zu der Folge, lass es uns gerne wissen,
schreib uns ne Mail, meld dich auf den Social Media Kanälen.
Wir freuen uns über jede Nachricht.
Schreib uns auch gerne von User Stories von Erfahrung, die du
hattest, die so richtig absurd waren.
Sowas finden wir auch immer super, da können wir auch eigene
noch berichten, dann da können wir an n Austausch kommen wenn
dir der Podcast gefällt, lass gerne ne Bewertung da empfehlen
gerne weiter es hilft uns enorm uns hier noch zu verbessern und
auch andere Leute daran teilhaben zu lassen.
Du findest in den Shownotes auch n kleinen Spendling falls du uns
so unterstützen möchtest, dann vielen vielen Dank dafür.
Und ja, ansonsten würde ich sagen, hören wir uns alle beim
nächsten Mal wieder. Ich wünsche euch noch eine
schöne Weihnachtszeit und bis dahin deine Coding Buddies.
Gemeinsam besser.