Latest / Coding Buddies | Tech & Dev-Mindset / Endlich verständliche User Stories!

Transcript

Endlich verständliche User Stories! · Coding Buddies | Tech & Dev-Mindset

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