Willkommen zu einer neuen hervorragenden Woche mit Secrets Not Included, die 8. Folge wieder mit Daniel und Ole hier. Und Daniel wollte mir jetzt mal erklären, wie denn Tickets eigentlich richtig funktionieren, damit da tolle Sachen bei rauskommen und nicht so viele Bugs produziert werden oder so.

Ja, also in der klassischen Softwareentwicklung war oder ist es ja immer noch so, dass egal ob du agil oder wasserfallmäßig unterwegs bist, war ja immer so ein bisschen der Grundsatz, keine Arbeit ohne Ticket. Die einen wollten halt Stunden darauf oder Zeiten gebucht haben, die anderen wollten agile Punkte drauf gebucht haben, so ein bisschen, um das managen zu können. Und für uns Entwickler ist es ja eigentlich immer gewesen, du kriegst ein Ticket über den Zaun geschmissen und dann steht dann drin mit, weiß ich nicht, Seite XY funktioniert nicht. Und das ist ja so...

Das ist ja mehr so ein Support-Ticket. Und über den Zaun geschmissen, da sind wir auch schon wieder methodenmäßig so völlig auseinander. Ich bin ja ein großer Verfechter von agilen Methoden wie Kanban und Scrum, wo es ja keinen Zaun gibt, über den du es drüber schmeißen kannst. Also zumindest nicht, außer du schmeißt zu einem anderen Team.

Nein. Dann heißt das Kick the Can down the road.

Aber dann ist es bitte auch ein tiefer Burggraben, damit man nicht miteinander spricht.

Nein, aber das ist eine andere Baustelle.

Ja.

Ganz mysteriöse Weise in allen möglichen Firmen kommst du zu einem neuen Ticket. Und natürlich hast du recht, im Idealfall ist da so ein Pull-System hinter, dass jeder Entwickler sich, sagen wir mal, Tickets nimmt, die er sich zutraut oder wo er weiß, was er zu tun hat. Und damit dieser Zustand eintreten kann, muss ja vorher eigentlich einiges in einem Ticket passieren, dass der Entwickler... von dem Zeitpunkt an, wo er sagt, ich arbeite aktiv an dem Ticket, bis es fertig umgesetzt ist, möglichst, also ich sage möglichst viele, nicht hundertprozentig, möglichst viele Informationen hat, um nicht noch extra Schleifen drehen zu müssen. Also zum Beispiel, wenn es ein Bug-Ticket ist, wo genaue Punkte beschrieben sind, was passiert, was hätte passieren sollen, wo passiert es, was habe ich gemacht, um dahin zu kommen, so ein bisschen, um das genauer zu beschreiben oder im agilen Kontext, wenn das so ein Feature-Ticket ist, wird ja so oft davon gesprochen, dass man aus der Ich-Perspektive beschrieben haben sollte mit, ich als, weiß ich nicht, Benutzer XY für ERP-Software möchte gerne dies, das und jenes beschrieben haben. Du schmunzelt schon, so.

Ja, also ich bin in der, also ich glaube auch Entwicklerinnen arbeiten mit Tickets, hoffe ich.

Wir teilen uns den Schutzraum. Ich meinte beides. Geschlechtsneutral. Sehr gut.

Ja, aber dann ist es ja mehr als beides. Ja, heute bin ich fit, finde ich, unterwegs. Aber jemand, der halt mit diesen Tickets arbeitet, Äh, wo wollte ich denn jetzt hinaus? Ich hab meinen roten Faden verloren. Hervorragend. Sehr gut. Neues Ticket, bitte.

Genau, also ich hatte gesagt, dass Tickets ja so schön beschrieben sind, immer aus der Ich-Perspektive, mit Ich möchte als...

Ah ja, genau, genau. Und ich finde auch wichtig, dass die Rolle, die man dort schreibt, ich als Administrator oder bla bla bla, ich als Endnutzer oder so, ich finde das wichtig, dass man auch eine Person dahinter hat, die die Rolle genauer spezifiziert und definiert, weil sonst hat man auch da schon wieder ein unterschiedliches Verständnis. Und Für mein Dafürhalten ist es auch so, ein Ticket sollte fertig spezifiziert sein in dem Moment, also spätestens in dem Moment, wo die Entwicklungsarbeit startet, also wo das Produzieren, Umsetzen von dem Ticket startet, weil ich erlebe das halt immer wieder, dass in bestimmten Teamkonstellationen dazu geneigt wird, später die Tickets anzupassen und zu verändern.

Ansonsten geht es nochmal ganz nach vorne wieder.

Nachdem die besprochen wurden, also das Besprechen von und jeder ist quasi im Team enabled, dieses Ticket zu bearbeiten. Das ist so für mich der Zeitpunkt, wo ich sage, ab dem Zeitpunkt ändert sich nichts mehr in dieser Ticketbeschreibung. Weil, genau. Und ich finde, das ist auch so ein... mag es auch sehr, wenn in Tickets nicht die Beschreibung geändert wird und irgendwas abgehakt wird, sondern wenn kommentiert wird mit, okay, ich habe diese Punkte erledigt oder das, das und dieses. Ich erlebe das immer wieder, dass diese Beschreibung geändert wird und dann fehlt so ein bisschen, je nachdem, mit welchem System man ist, die Historie, was wurde denn verändert?

Mhm.

Und dann ändert sich auf einmal der Scope der Aufgabe oder des Tickets, weil das Testteam sagt dann auf einmal noch, also wenn man so getrennte Teams macht, wovon ich kein Fan bin, ja, sagt dann einfach mal, naja, wir haben noch dieses und jenes, aber das ist auch noch ein Akzeptanzkriterium und das wurde am Anfang gar nicht besprochen.

Mhm.

Weißt du, aus der Richtung komme ich und sage, okay, wenn in dem Team, das das bearbeitet, sich auf ein Ding geeinigt wurde, dann kann man auch losgennen und dann ändert ab dem Zeitpunkt auch niemand etwas mehr daran.

Ja, also jetzt ohne groß alle agilen Buzzwords zu nennen, die Definition of Ready ist so, wann ist das Ticket als fertig zu betrachten und wenn es diesen Zustand erreicht hat, das ist der Moment, wo die Entwickler loslaufen können und, also da kann ja immer wieder mal passieren, dass der Entwickler das anfasst und sagt, irgendeine Frage ist noch offen.

Ja, ist ja egal, ob es jetzt... Ja. Ja.

dann muss das aber dazu führen, nicht, dass der Entwickler weitermacht, sondern dass man nochmal hingeht und eigentlich sollte im Team ja vorher besprochen sein mit, guck mal, das ist das Problem, das wollen wir so lösen, es wird dokumentiert, dann ist dieser Punkt Definition of Ready erreicht und dann kann der Entwickler loslegen. Heißt, das Ticket springt wieder an den Anfang, es reden nochmal alle drüber, ändert sich was, ja, nein, explodiert die Komplexität, muss etwas hinzu, hinweg, Vielleicht braucht man einen anderen Experten oder ein anderes Team ist auf einmal beteiligt. Oft sind ja auch so, gerade in größeren Unternehmen, mehrere Teams, die da auch zum Beispiel sind Message-Queues, die untereinander irgendwie zwischen Teams Messages hin und her schicken.

Ja.

Und drei Teams verlassen sich darauf, dass die Struktur von einer Message oder von einem Datensatz sich nicht ändert. Dann musst du auch da noch Runden drehen und abholen. Und das habe ich auch schon oft erlebt, dass das vergessen wurde. Und auf einmal weiß das ERP-Team nichts davon und irgendwelche Sachen knallen. Bestände werden nicht aktualisiert oder so. Und das ist... Hm.

Ja, ist tausend und eine Variante. Das ist unfassbar wichtig und wertvoll, was da in den Tickets stehen müsste und ganz, ganz häufig einfach keinen Weg da reinfindet, wenn man auch mit sehr vielen impliziten Annahmen arbeitet. Weil wir haben ja mal vereinbart, da war dann die Hälfte der Leute nicht da oder noch gar nicht im Team oder, oder, oder. Ja, Oder es gibt so eine Anekdote damals im Jahr 2000, da kam ein Stern und hat uns den Weg gewiesen, dass wir so vorgehen wollen, ja, wenn das aufgeschrieben wird, dann weiß es auch nicht.

Was hat der Entwickler entschieden, der nicht mehr im Projekt ist? Keiner weiß warum. Hm.

Genau. So, mega gut. Mag ja eine valide Entscheidung sein. Die Schwierigkeit besteht immer dann, wenn, also finde ich persönlich, wenn so Tickets einfach kein Wissen transportieren. Also nicht so, dass ich das Ding nehmen kann und sagen kann, naja, jetzt bearbeite ich das. Und zwar aus der Perspektive, ich habe heute meinen ersten Tag und bekomme dieses Ticket. weiß ich dann, was ich mit diesem Ticket anfange. Jetzt kann man natürlich sagen, nein, natürlich nicht, du hast dann auch kein Setup, bla bla bla, aber das blenden wir mal aus. Also ich bin jetzt ready für meinen ersten Task, nimm mir das Ding, weil ich denke, da stehen drei Punkte dran oder das ist nur geschätzt auf einen Tag Aufwand, welche Methode auch immer, ist ja völlig Latte, aber ich nimm mir halt mein Ding Ding und soll damit loslaufen und dann steht da drin, Button-Farbe ändern, wie besprochen.

Boah, da triggerst du was bei mir.

Und du denkst mir so, also, okay, welcher Button, wo finde ich den?

Das ist... Warum?

Welche Farbe soll es jetzt werden? Das war, warum ist mir bei dem fast noch egal, ja? Meinetwegen hat das irgendein Grafiker, UXer,

Doch irgendwie... Nein, meistens ist es dann nämlich so, weil bei dem Nutzer XY irgendwas eingestellt war und du änderst die Buttonfarbe, löst aber gar nicht das Problem, weil du nicht... Also... wenn derjenige gesagt hätte, was er haben will, ich möchte auf dem System XY haben, dann könntest du als Entwickler mitdenken.

Ja.

Und das ist also eins meiner größten Themen oder Lieblingsthemen. Schreib mir nicht in die Tickets, was ich machen soll. Das ist meine Aufgabe als Entwickler, sondern warum oder was. Also schreib nicht rein wie, sondern was.

Ja, also bei der Button-Farbe bin ich jetzt vielleicht ein bisschen sehr nachsichtig mittlerweile, aber vom Grundsatz gebe ich dir recht, wenn von außen ein Team eine Lösung vorgegeben bekommt, für eine Lösung für ein Problem, dann kann das vielleicht eine gute Lösung sein, muss es aber nicht. Und ich bin mir fast immer sicher, dass das zweite zutreffend ist.

Also es verursacht bei mir einfach, also wenn ich zum Beispiel ein Ticket bekomme, wo drin steht, wir brauchen Klasse A, B und C in dem Pfad mit diesen Fähigkeiten, baue ich dir. Dann ist das Ticket fertig, gebe ich dir ab und dann liegt das wieder bei dir und du musst dann verifizieren, ist das alles. Wenn ich aber wüsste, dass du ein Problem lösen willst oder dass irgendwo zum Beispiel Performance-Probleme sind, dann kann ich ja schon sagen, guck mal, das habe ich bei einem anderen Projekt gesehen, das hat gar nicht so funktioniert. Oder warum ist denn da ein Performance-Problem? Vielleicht kann man das ganz anders lösen. Mhm.

genau ich kann halt mit meiner erfahrung hingehen und sagen ja schau mal wir müssen an den stellschrauben drehen weil irgendwie macht man ja diesen Job schon irgendwie zwei, drei Sonnenumrundungen und hat halt Erfahrungen gesammelt. Und die Erfahrung... Genau.

Ich habe genug kaputt gemacht, dass ich weiß, was man kaputt machen muss, damit Sachen nicht funktionieren. Ja. Ja.

So, ich habe genug Bauklötze umgeschmissen, um zu wissen, man muss das breiter bauen, wenn der Turm höher werden soll. So, und vielleicht wäre zu beweisen, ähm... Wollte ich jetzt eigentlich hinaus? Also heute ist nicht mein Tag, glaube ich.

Hättest du das in einem Ticket stehen, wäre dir das nicht entfallen. Dann könntest du das nachlesen. Oh.

Jetzt wolltest du mir sagen, wie sieht denn das eigentlich aus, das ideale Ding jetzt, damit ich auch jeden Tag verpeilt sein kann, gerade wenn meine Kaffeemaschine nicht mehr funktioniert, Ja, du erkennst die Dramatik dieser Worte. Also, meine Kaffeemaschine tatsächlich kaputt gerade. Und der Hersteller hat so Spezialschrauben. Ja, ganz, ganz furchtbar. Also man kann nicht mal eben aufschrauben und nachschauen, ist der Schlauch abgerutscht, sondern geht nicht. Und man braucht Spezialwerkzeug. Mega ätzendes Ding. Da wollte ich aber gar nicht drauf hinaus. Außer, dass ich keinen Kaffee habe und deswegen noch verpeilter bin als sonst.

das ideale Ticket. Also wenn eine kleine Fee auftauchen würde und ich mir was wünschen dürfte, dann würde ich mir echt wünschen, dass ich Tickets bekomme, die nicht KI generiert sind, weil das ist viel zu viel Text, der, also habe ich auch schon gesehen, das wäre zu viel Text, das ist das andere Extrem.

das ideale Ticket. Was hilft, mir dann hilft, wieder das Ding eigentlich perfekt zu entwickeln, obwohl ich keinen Kaffee habe. Oder nur Tee.

sondern wo einfach drinsteht, was ist gerade das Problem oder was möchten wir lösen? Was ist der Vorteil? Was bringt das zu machen? Wenn es ein Feature ist zum Beispiel, wir möchten Kunden ermöglichen, Sachen auf eine Merkliste zu packen oder wir möchten, keine Ahnung, Kunden dazu führen, irgendwelche Querkäufe zu machen und irgendwelche Sachen anbieten.

Mhm.

Beispiel. Und das könnte, also da darf auch drunter stehen, also ich bin nicht so strikt und sage, da darf bloß keine Lösung drin stehen, aber wenn der erste Block sozusagen das Problem umreißt oder die Lösung oder den Mehrwert, Mehrwert ist vielleicht das Richtige, Mehrwert umreißt, kann da drunter stehen, guck mal, eine Lösung könnte sein, evaluier mal. Gerne, kein Problem. Schränkt mich, weil das Problem ist, das schränkt mich vom Denken immer automatisch ein, wenn ich einen ganz festen Korridor habe und wenn so offen geschrieben wird, der erste Block, ja super, dann bin ich direkt drin, kann ich mitdenken, vielleicht sehe ich noch ein paar Sachen oder verstehe gar nicht, wo die Reise hingehen soll, bin dann aber spätestens da schon in der Lage zu sagen, ich verstehe das nicht, erkläre mir das mal. Bei dem technischen, wenn jetzt nur der technische Part geklärt gewesen wäre, dann wäre ich bis zur Hälfte gekommen und sage, komisch, warum mache ich das eigentlich? Und würde eine Woche später Rückfragen stellen. Das führt halt dazu, dass du schon früher darüber reden kannst. Wenn grob sowas spezifiziert ist, dann finde ich es immer sehr angenehm, so in der Runde, also ich bin sehr agil geprägt, das merkt man überhaupt nicht gerade.

Nein, nein, gar nicht, Daniel.

Ja. gut versteckt.

Dass wir beide, glaube ich, agiles Arbeiten bevorzugen, ist kein Geheimnis.

Also ich mag es dann, naja, ich schäme mich auch nicht dafür. Ich kenne es halt so, dass die so grob die Tickets ankommen. Das ist vollkommen in Ordnung, weil dann reicht das so, dass die Entwickler sich da, zwei Entwickler setzen sich ran und sagen, was ist das für ein Ticket? Was macht das? Was soll das? Und die spielen sich einfach gegenseitig Fragen zu. Paff, landet eine Frage im Kommentar oder man holt noch jemanden kurz ins Meeting hinzu, Also ich möchte keine Buzzwords aus dem agilen Kontext nutzen, welches Meeting was wo passieren sollte, das ist egal.

Ja.

Es reicht, dass das passiert. Dann kann man einen Projektleiter dazu holen, keine Ahnung, einen CEO vielleicht, wenn es ein kleiner Laden ist, der einen Wunsch hat, irgendwie den Umsatz zu verdoppeln. Und da redet man darüber. Und dann hat man so, okay, da soll die Reise hingehen, dann können die Entwickler sagen, die Lösung, und dann ist dann der letztere Block, das sind die Akzeptanzkriterien. Was muss passieren, damit wir messen können, dass das Ergebnis eingetreten ist? Oder kann, wenn man es messen kann. Wobei selbst Codequalität verbessern kann man auch messen, also hatten wir auch schon als Akzeptanzkriterium.

Ja.

Also das ist so der letzte Block, den füllen die Entwickler dann aus, wo man dann auch noch Kommentare hinzuschreibt, technische Informationen, brauchst du irgendwas, Credentials, externe Systeme, andere Teams, die informiert werden müssen oder andere Personen. Und dieses Ticket lebt ja eigentlich. Also das ist so der erste Schritt. Einer macht den Aufschlag, sagt, was hätte ich gerne? Vielleicht auch mit dem Entwickler schon zusammen oder spezifiziert das erstmal aus. schreibt seine Wünsche darunter, wenn er schon technisch so tief ist. Es gibt genug Leute, die sind technisch tief genug, die auch das System kennen und auch schon Hilfestellung geben können. Gerade so, wenn ich neu im Projekt bin, sind selbst manchmal die Projektleiter tiefer drin als ich nach einer Woche oder so.

Mhm.

Natürlich hilft mir das dann, dass ich sagen kann, guck dir mal die Stellen an, da ist das ähnlich gelöst. gehe ich hin, gucke, stelle Rückfragen und dann wächst das Ticket. Irgendwann bist du an dem Punkt, dass du sagen kannst, okay, ich verstehe das ganz, das und das muss passieren, damit das läuft. Dann füllt man noch Akzeptanzkriterien aus und dann ist man eigentlich schon sehr weit, dass man sagen kann, Definition of Ready ist erreicht. Also je nachdem, wie sie definiert ist. Aber dann hast du einen Punkt, wo du ein Ticket hast, wo du dann nicht, also wirklich nur noch ab, das kannst du dir dann nehmen und sagen, guck mal, das könnte ich in diesem Sprint schaffen und setzt dich hin, arbeitest das ab und kannst dann nachher abgeben und sagen, hier, ist das so, wie wir es besprochen haben? Das wäre echt so, wenn die zugehört hat, die kleine fehlt.

Und warum machst du das nicht so?

Ja.

Bisschen böse, aber ich glaube, wir alle wissen ja, dass da so ein ideales Ticket aussieht.

Ja, ja.

Aber wir wissen auch aus der Erfahrung, sagen wir, wir haben es erlebt, dass das ja eben nicht der Zustand ist, in dem wir uns alle bisher bewegt haben. Jetzt haben wir aber ja letzte Woche festgestellt, wir haben da so jemanden, mit dem quatschen wir die ganze Zeit und machen vielleicht KI-Pair-Programming-mäßig rum. Unsere Ente, die wir früher hatten, antwortet auf einmal. Fällt mir ein, wo ist meine Ente? Egal. Also heißt ja, Macht das vielleicht sogar noch aus anderer Sicht Sinn, jetzt auf einmal sich diese Arbeit zu machen und diese Tickets mal endlich vernünftig zu schreiben?

Ich glaube, dass gerade so mit dem Buzzword Spec-Driven-Development etwas passiert, was früher viele Entwickler, also nicht Entwickler, Projektbeteiligte. In alle Richtungen. Ich möchte...

Ja, definitiv an der Stelle, definitiv.

Also das ist ja auch kein Geheimnis. Keiner hat Bock eigentlich Tickets zu schreiben und stundenlang in Meetings zu sitzen und Sachen auszuspezifizieren und irgendwie Linien zu ziehen und zu malen. Und was mir aufgefallen ist, ist gerade aber im Spec-Driven Development, passiert genau das Gleiche eigentlich. Also die Rückfragen, die gestellt werden, sind die, die ich früher gestellt habe, wenn der Projektleiter das Ticket vorbereitet hatte. Jetzt gehe ich ja auch hin und sage, also es gibt genug Frameworks mittlerweile ja auch schon für die KI und die Konsole, wo du sagen kannst, hier, also zum Beispiel von GitHub, um wieder Namen zu droppen, damit wir irgendwann mal einen Sponsor kriegen. Ja. Nee, also ich habe jetzt letztens Speckit ausprobiert für mich. Gibt bestimmt auch andere Sachen, fand ich sehr interessant. Ist halt so ein fertiges Framework, wo du sagst, so Speckit, ich würde gerne anfangen zu planen oder spezifizieren.

Vielen Dank.

Und dann schreibst du erst mal runter, ne? schon bist du bei der Analogie oder bei dem alten Ticket mit, ich als Daniel als Entwickler möchte das und das, dass das und das passiert. Oder ich brauche zum Beispiel ein Login-System, ich brauche, weiß ich nicht, ein Renewed Endpoint oder fängst du solche Sachen an, du schreibst sie erst mal. Dann kommt KI, die läuft dann immer so ein bisschen in der Schleife mit und stellt Rückfragen und sagt so, ja, okay, du brauchst, zum Beispiel einen Endpunkt. Wie möchtest du dich authentifizieren? Reicht ein Pfad? Muss das anders sichergestellt sein? Wie soll der Pfad heißen? So die ersten Rückfragen kommen dann. Und schon merkst du, dass du auch so diesen zweiten Part schon ausarbeitest, wo du sagst, ich hätte gerne, also das ist mir wichtig, dass zum Beispiel der Endpunkt existiert, ich hätte gerne das vielleicht so. Also du hast auch mit dem Warum angefangen, bist dann so ein bisschen, weil du als Entwickler bist, so, ja, ich wünsche mir, dass das so aussieht, vielleicht ein Login-Formular und ich brauche einen Endpunkt für einen JWT-Token.

Ja.

oder es läuft über Session oder was auch immer. Schon hast du deine Wünsche, die du da auch drunter geschrieben hättest, so mit, ja, vielleicht ist das eine Lösung. Und da läufst du dann mit KI-theoretisch ein paar Mal drüber, bis du sagst, okay, ich habe das verstanden. Und gehst dann auf den nächsten Schritt und sagst so, planen wir das jetzt? Und dann geht die, den Schritt tiefer und dann bist du sehr nah bei den Akzeptanzkriterien. Was muss passieren, ne? Und dann geht die auch von den Fragen einen Schritt tiefer und sagt so, guck mal, wie lange soll die TTL zum Beispiel, das ist so eine Frage, die mir gerade einfällt, JWT-Token, TTL, müssen irgendwelche anderen Infos da mit rein?

Ja.

Wo ist der Public Key? Den Schritt wieder. Und diese Analogie zu den alten Tickets fand ich letztens echt lustig, weil du eigentlich genau das machst, was früher auch hätte im Ticket passieren sollen und viel ausführlicher. Das macht man, oder habe ich jetzt die letzte Zeit öfter mit Speck-Driven-Development gemacht. Fand ich sehr interessant.

Spannend finde ich ja auch tatsächlich, dass der vorletzte Step eigentlich der Task ist, den man ja auch im Ticketsystem irgendwie nie angelegt hat.

Ja. Ja, ja, ja, ja.

Weil alle gesagt haben, ja, die Story reicht. Oder der Task war dann ja nur irgendwie so ein oder häufig so eine Dekoration, mit, wir wissen jetzt ja alles, wir brauchen das nicht weiter runterbrechen. Und eigentlich finde ich das halt mega spannend, dass wir jetzt halt wirklich hingehen, sagen, okay, wir spezifizieren, wir planen, dann brechen wir jetzt nochmal ein kleines Stück auf und dann wird es implementiert. Weil so hätte es ja einfach die ganze Zeit, ähm, gut laufen können. Das Kurzschreiben war ja nie das Bottleneck am Tagesende.

Ja.

Es ist ja auch immer noch so, dass das Außenrum der ganze Overhead sehr, sehr zeitintensiv ist. Und jetzt halt auf einmal dieses wir planen, weil wir jemanden einsetzen, der keinen Plan vom Kontext hat, kein, also zwar weiß, wie Programmieren funktioniert, theoretisch, aber jetzt gar nicht so genau alles weiß und vor allem nicht diese impliziten Dinge weiß, ja, die stillen Konventionen, die überall mitschwingen und solche Dinge und

Mhm.

Jetzt fangen wir an und schreiben das auf, weil wir dann sagen, ja, aber dann wird ja schneller programmiert. Ich finde, das ist ein ganz, ganz, ganz spannender Wandel, weil genau das hätten wir ja eigentlich schon in der Vergangenheit die ganze Zeit haben können.

Und ein ganz netter Nebeneffekt ist, du produzierst, also nicht ganz viel, aber du produzierst Markdown-Dateien mit genau diesen Informationen.

Ja. Ja.

Also ich bin mir noch nicht so sicher, was ich davon im Projekt behalten möchte oder nicht. Aber dass ich was davon im Projekt behalte, also die Tasklist, weiß ich nicht, ob ich die später noch brauche. Aber so die Anfangsspezifikation zum Beispiel zu dem Ticket, das hatten wir ja gerade, was ist, wenn der Entwickler schon gar nicht mehr im Unternehmen ist und da ist irgendwas.

Mhm.

Auf einmal hast du einen Doc oder Docs-Ordner, wo ganz viele Spezifikationen zu Features drin liegen, wo du nachlesen könntest, was damals die Anforderungen waren. Also wenn sich das jetzt ändert und es heißt hier, keine Ahnung, diesen tollen JWT-Token, den Daniel eingebaut hat von vor zehn Jahren, das ist sowas von veraltet, keine Ahnung, jetzt gibt es irgendwas anderes, dann könnte man mal nachlesen, warum ich das gemacht habe und was da wichtig war und könnte das dann auf die neue Technologie abstrahieren, weil diese Information sogar noch da ist im Projekt. Also das finde ich sehr interessant.

Ich fände ja sehr spannend und ich muss mir das definitiv anschauen, ich habe damit halt noch gar nicht weiter agiert, ob man das nicht auch zum Beispiel mit meinem heiß geliebten GitLab abbilden kann, dass eben da die Storys und halt Spezifikationen sind und dann plant man das da und dann halt die Tasks auch da drin hat und das darüber tatsächlich verwaltet wird und dann habe ich es ja auch direkt so, dass ich es durchsuchen kann und solche Sachen, das lässt sich ja viel...

Blöde Frage, hat GitLab eine MCP-Schnittstelle? Bestimmt. Was frage ich eigentlich? Natürlich haben die das, bestimmt.

Ich weiß, dass es Open-Source-Projekte gibt und ich weiß, dass es Paid-Features gibt, wo es, glaube ich, dann auch MCP gibt. Aber dann wäre es für mich nochmal zugänglicher für andere Projektbeteiligten, die sich nicht extra das auschecken müssen und anschauen müssen.

Also, kleine Side-Note, ich nutze gerne Jira, Asche auf mein Haupt, also irgendwie mag das keiner außer ich.

Das stimmt.

Und ich bin sogar so nerdig, ich habe Jira CLI auf der Konsole, dass ich über die Konsole Tickets erstellen kann, abrufen kann und alles. Und ja, aber genau, dann hast du das doch, was du wolltest.

Ja gut, das kann ich mit GitLab Seal Eye auch. Das ist jetzt... Hm.

Und genau das habe ich letztens gemacht mit Speckit fertig und habe gesagt, erstell mir nochmal Jira Tickets dafür. Und dann ist das Ding über die CLI hingegangen, weil ich war mal mutig, hab den Token da reingeschmissen, also nicht reingeschmissen, hab dann an der Session auch wirklich den Token aktiviert und dann hat das Ding da Tickets erstellt. Also das, was du wolltest oder willst. Mhm.

Interessant. Vielleicht sollte ich mir das mal anschauen.

Also mit einem Sternchen, deswegen hatte ich vorhin auch gesagt, es ist sehr ausgiebig und da noch so einen Mittelweg zu finden zwischen ich nerv den Entwickler, der zwei Stunden lang 50, die in vier Seiten lesen muss, um zu verstehen, was da passiert. Also zu viel Dokumentation ist, glaube ich, auch nicht hilfreich.

Ja, das kann die KI dann ja auch wieder zusammenfassen.

Wir haben ein Problem gelöst, das wir nicht hatten. Aber ja,

Ist das jetzt nicht die Antwort, dass man aus fünf Bullet Points eine E-Mail generieren lässt, die dann jemand anderes wieder in die KI schmeißt, um fünf Bullet Points rauszubekommen?

Ja, wir haben es drauf. Ja, aber irgendwo dazwischen ist die Lösung. Also zu viel ist auch nicht richtig, aber und das fand ich in dem Prozess echt interessant, also jetzt nur ein, zweimal so für mein Projekt genutzt, leider, oder nicht leider, noch nicht, beim Kunden habe ich mich noch nicht getraut, aber das aus der, also aus Open Code heraus oder halt aus Codex oder

Ja. Ja, weiß ich nicht, ob ich das kann, aber ich könnte es ausprobieren.

Aus meinem Tool der Wahl zu sagen, hier mit Speckit Spezifikationen komplett runtergebrochen und dann auch gesagt, hier erstellen wir mal die passenden Tickets für die Tasks.

Das ist gut. Erster Schritt geschafft. Daniel traut es mir zu. Sehr gut. Ja,

Fand ich sehr interessant. Also das könntest du machen. Ich trau dir das zu.

Meinst du denn, das lohnt sich auch? Oder sagst du, der Overhead ist dann doch so groß? Also für mein Empfinden ist es so, entweder hatte man in Projekten zu wenig Dokumentation oder zu viel tote Dokumentation oder unpassende Dokumentation.

Ja, ja, das auch.

Wenn ich an gewisse formalen Vorgaben denke, in denen Dokumentation zum Teil erstellt werden musste, waren das häufig so Dinge, die einfach nicht hilfreich sind. Aber man konnte dann im Compliance schön ein Häkchen dran machen und sagen, ja, wir haben nach dem Standard aber Dokumentation erstellt in monatelanger Arbeit. Also das ist halt immer so mein Ding, wo ich sage, also vom meine Denkweise ist halt irgendwie okay, an meine Code-Änderung, im Sinne von an meinen Commit schreibe ich das Issue, also eine Referenz auf das Issue, damit ich weiß, wo gehört es denn hin und dann, wenn ich mich frage, warum ist denn dieser Quote da, mache ich quasi meine History auf und sage, was hat das denn verändert, dann komme ich darüber an den Commit, der Commit leitet mich zu dem Ticket und dann finde ich alle Informationen da. So, das ist der ideale Weg.

In Confluence, die sich nie ändert und keiner liest. Ich auch nicht. Naja.

Und in der noch besseren Welt wurde dann aus dieser Dokumentation, die da existiert durch die Tickets, auch tatsächlich Dokumentation für Nicht- Entwickler und Entwicklerinnen produziert. Ja, ich bin jetzt ja kein Confluence-Fan, aber in einem Wiki oder in irgendeinem System der Wahl, was vielleicht auch genutzt wird.

Also ich würde mir hoffen oder wünschen, also ich behaupte nicht, dass das die Lösung ist, aber in meiner Fantasie ist es so, wenn ich mit Spec-Driven Development Markdown-Dateien generiere, die ausführlich genug sind, dass auch Nicht-Techniker das verstehen, also gerade so der erste Aufschlag, die erste Datei, die generiert wird, ist sehr, also Sehr wenig technisch so rum.

Ja, also sehr high level im Prinzip.

Ja, ja, genau.

Ja.

Und wenn das im Projekt bleibt, kannst du das ja auch über Hosting an Vita XY sogar super Markdown lesen. Also musst du nicht irgendwie umwandeln in HTML oder in irgendwelche Sachen importieren. Funktioniert ja auch. Und ich denke mal, ein Link oder Leseberechtigung auf jeden Repo ist ja kein Problem. Also hast du fast eine lebende Doku oder eine bessere Doku, als wenn du das über mehrere Systeme verteilst? Also das... Ja, siehst du... Hätte ich doch Obsidian-Aktien gekauft, ne?

Definitiv. Also ich glaube, in GitLab wird das wirklich auch mit Markdown betrieben. Es ist ja auch spannend, dass wir so ein altes Format wie Markdown, was ja quasi in der Versenkung verschwunden war, jetzt wieder rauskramen und alle arbeiten auf einmal mit Markdown. Und es ist halt so ein bisschen so, ja, das ist so ein bisschen so, dass man,

Ja.

Verstoßene Kind ist jetzt wieder da und ist jetzt das Lieblingskind.

Es ist einfach menschenlesbar und auch gut lesbar, ohne Programmierverständnis, finde ich.

Das ist ein bisschen witzig, finde ich, dass jetzt dieses einfache Textformat wieder belebt wird. Ja, und ich finde, das ist aber...

Das ist

gewünscht.

Entschuldigung. drauf. Womit schreibt man die ganzen Doktorarbeiten? Latex.

Latex.

Boah, Latex. Ich habe nicht versucht, ich bin zu dumm für sowas. Also... Aber nochmal zurück zum Spec-Thema. Also ich nutze das nicht für alles. Also das ist jetzt nicht so, ich spezifiziere alles und mache das Projekt voll mit solchen Dateien.

Mhm. Mhm.

Früher hätte man auch nicht für alles, also je nachdem, ein Epic oder eine Story gemacht. Und das ist so, glaube ich, eine gute Analogie. Wenn du etwas hast, was groß genug ist, Da ist das super hilfreich, wenn du sagst, ich will komplette Storage Engine irgendwie in mein Projekt einziehen oder ich habe nur lokalen Speicher und möchte jetzt irgendwie ein S3 Bucket anbinden. Das wäre so etwas, wo du sagst, das ist groß genug, wo du spezifizieren kannst, dich runterarbeiten kannst. Hast du irgendwie, weiß ich nicht, brauche ich eine Lokalisierung an irgendeiner Stelle, da würde ich damit nicht anfangen. Da ist das so mit Kanonen auf Spatzen schießen. so diesen richtigen Weg finden, ich glaube, das ist noch der Punkt, den ich auch für mich finden muss. Am Projektanfang nutze ich es viel mehr, weil halt natürlich noch viel auf der grünen Wiese ist und du halt noch viele Baustellen hast. Und je weiter du im Projekt kommst, wenn ich jetzt überlege, ich habe so ein Projekt, was zehn Jahre alt ist, da gibt es jetzt nicht mehr viel, was sich so massiv bewegt. Also, ja,

Also wenn ich mir das so, also aus meinem Verständnis gerade, würde ich ja sagen, die Specify und Plan, das ist ja quasi die Story-Ebene.

Ja. Ja, aber das ist ein gutes Beispiel. Das passt. Ja.

Task ist Task und Implement ist Implement. Es verschiebt sich halt noch vielleicht, wer es tut, oder was es tut. Ja, ist KI sächlich? Naja, also, so. Ähm, So von meinem Bauchgefühl, ja. Also wir haben das Epic oben drüber und dann wird es ja speziell und dann wäre es für mich quasi diese Story-Ebene und dann kommt die Task-Ebene und dann das tatsächlich eher Doing. Ich finde, das passt eigentlich sehr gut in diese agile Welt.

Extreme.

Oder in diese Aufbauform von Aufgaben. Das heißt ja nicht, dass das immer im Agilen auch so sein muss. Man kann ja auch das mit Wasserfall machen oder mit whatever, welche... Methode man sich jetzt überlegt und wie man das Kind dann nennen wird. Aber es ist halt eigentlich eine schöne formale Methode, um da ranzugehen. Und gleichzeitig muss ich auch sagen, dass es ja wunderbar in die Gesamtpatterns auch reinpasst mit Atomic Design und so weiter. Aber das sprengt, glaube ich, jetzt unseren Zeitrahmen, wenn ich ehrlich bin. Auch so auf Komponentenebene. Du kannst es halt wunderbar weiterspinnen und gibst eigentlich sehr viel Architekturstruktur schon durch diese Aufgaben vor. Ich glaube, ich werde das ausprobieren.

Ich habe dich eingefixt. Freut mich.

Und dann werde ich über dich schimpfen, wie schlimm das ist, diese langen Tickets, dass man so viel lesen muss.

Ja, bitte, bitte. Hätte ich doch einen Affiliate-Link. Ja. Bis dann, ciao.

Perfekt. Dann glaube ich, war es das diese Woche wieder für Secrets Not Included. Und dann sehen wir uns nächste Woche wieder zu einem neuen spannenden Thema. Macht's gut, bis dahin. Ciao, ciao.