#218 Bug Management Teil 2: Priorisieren, Fixen, Verhindern, Anerkennen

[SPEAKER_01]: Und weil du damit irgendwie jeden Tag zu tun hast, dachten wir, bauen wir doch gleich eine zweite Episode um das Thema. [SPEAKER_01]: Okay, zugegeben, das Thema gibt auch einfach sehr viel her. [SPEAKER_01]: Das hier also ist Teil 2 unserer Backmanagement Episode. [SPEAKER_01]: In Teil 1 haben wir jetzt um die Themen. [SPEAKER_01]: Backs finden z.B. [SPEAKER_01]: Alfa Beta-Channel-So-Dock-Footing, reporting von Backs und Backtree-Asch gekümmt.

[SPEAKER_01]: In dieser Episode, Teil 2, dreht sich alles um die Halbwehrzeit von Bugs, Bugs in Solvenzen und Zero-Bug-Polices, wie man Zeit und Raumschafft damit die Bugs auch gefix werden können, Rudkorsanalysen und Insidenz für Bugs, wie man Bugs auch in Produktion noch verhindern kann, sowie die Tech-Kultur und Leadership an der Kennung wird es um Qualität und Bugs fixieren. [SPEAKER_01]: Wir legen los.

[SPEAKER_00]: So, jetzt kommen wir aber mal zurück zu dem eigentlichen Problem, weil sie ganz am Anfang erwähnt habe. [SPEAKER_00]: Meine Liste an Bags fühlt sich und fühlt sich und fühlt sich. [SPEAKER_00]: Und wird immer größer sein oder fast immer größer sein als die Zeit, die ich zu verfügung habe. [SPEAKER_00]: Wie geht eigentlich mit dem dagdäglichen Alldagsproblem um, dass sie ganz viele Bags fixen müsste?

[SPEAKER_01]: Wir schauen jetzt mal hinter die Kulissen und nehmen mal deine Annahme raus. [SPEAKER_01]: Und die Annahme ist, ich muss ein Back fixen. [SPEAKER_01]: Meine Frage war, musst du diesen Back fixen, denn ich denke, [SPEAKER_01]: Ich denke, es ist mehr aufwand, ein Back zu fixen, der vor einem Jahr reportet wurde als einen der gestern reportet wurde. [SPEAKER_01]: Der Grund ist, die Software erinnert sich, der Kontext verschwindet.

[SPEAKER_00]: Ja, aber die Taxuelle, dass man noch früher den Back fixen muss, noch mehr Druck. [SPEAKER_00]: Dass ich sofort den Back behebe, weil er aktuell leichter zu beheben ist. [SPEAKER_01]: Na ja, das Optimum wäre natürlich der Backcom rein und du fix das, aber du redest ja jetzt von einem langen Backlock, was du breit angehöft hast und da könnte mein Witz sagen, als ganz brutale Vorgehensweise ich lösche alle wachs und sage, was wichtig ist, kommt wieder.

[SPEAKER_01]: Oder ich kann die Jurisier sogar und ich lösche nur alle low priority wachs, dann hab ich hoffentlich ein deutlich leerlos Backlock. [SPEAKER_00]: Aber was machst du dann mit den ganzen Kunden durchs Tier zuerst erwähnt? [SPEAKER_00]: Irgendwann hat die Reportet und die sind jetzt alle ziemlich frustriert. [SPEAKER_00]: Wenn nicht ihre Backnummer mehr vorhanden ist.

[SPEAKER_01]: Da er was so auch machen kann, zu Kanzellen an einer Lise fahren, die Kunden, die den Back reportet haben, sind die überhaupt noch meine Kunden. [SPEAKER_01]: Oder sind die schon geschafft. [SPEAKER_01]: Du kannst es weiter weiterfühlt haben, dass du die Kunden nicht frustriert. [SPEAKER_01]: Du kannst auch sagen, wann hat der Kunden das letzte Mal nachgefragt? [SPEAKER_01]: Der vielleicht hat er das einfach von einem Jahr ge reportet und gar nicht mehr nachgefragt.

[SPEAKER_01]: Vielleicht hat er das gar nicht mal verschirbt. [SPEAKER_01]: Also, Präzipel ist natürlich die Gefahr, wenn du backst löscht, das du die Leute, die den Back report haben, dass du die frustrierst und dass sie dann am Ende des Dorie aufhören, Backs überhaupt zu reporten. [SPEAKER_01]: Du kannst auch so eine Unterform machen und sagen, du declarierst mit eine Back in solvenz und sagst, okay, du löscht nur backst sie in den 16, 16 oder keine Abdez bekommen haben oder ähnliches.

[SPEAKER_01]: Kann man machen, ich persönlich bin da kein Fan von, denn ich halte dieses Frustrationslevel für real. [SPEAKER_01]: Und ich hatte das selbst schon. [SPEAKER_01]: Ich bin auch eigentlich kein Fan davon, bei Github, dass du so eine Automation hast, die sagen, dieses Ticket ist stäil und wird deswegen automatisch geschlossen, weil das frustriert nicht.

[SPEAKER_01]: Ich weiß ganz genau, hier sind mehr Tickets als das Engineering Team behandeln kann, es macht für mich keinen Sinn, da mehr was zu reporten. [SPEAKER_01]: Also, ich hab diese Frustation schon selbst erfahren. [SPEAKER_00]: Du kannst natürlich auch einfach eine Message schreiben. [SPEAKER_00]: Hey, hier ist schon lange nichts mehr passiert. [SPEAKER_00]: Ist dieser Back noch relevant. [SPEAKER_00]: Also es wäre so eine abgeschwächte Variante.

[SPEAKER_00]: Und dann kann man immer noch entscheiden. [SPEAKER_00]: Auf allen Seiten, also alle die Bedeidigt sind, ist das überhaupt noch relevant.

[SPEAKER_00]: Üblicherweise, wenn man jetzt weggeht vom Open Source-Bereich, wo ich direkt auf Repository oder Backtrack-Kazu-Kriff habe, üblicherweise ist es ja getrennt und der Kunde sieht ja nicht alle Informationen auf einem Issue von außen, oder hat vielleicht überhaupt keine Zugriff, also der hat es irgendwann rebordet, hat eine immer bekommen, und da kann vielleicht gar nicht auf irgendeinen Issue gehen,

[SPEAKER_00]: Und dann hast du natürlich auch andere Möglichkeiten, weil wahrscheinlich, wenn der Kunde des ein Jahr lang nicht rebordet hat oder vielleicht gar nicht mehr Kunde ist, dann lässt es dir einfach und gerade im kleineren Umfeldstader Bereich, wo die auch sagen, weg mit dem alten Zeug. [SPEAKER_00]: Also du bist das so agile und da hat dich schon zehnmal was geändert an das Software. [SPEAKER_00]: Da kann man ruhig intensiver, Backslushen und Aufräumen.

[SPEAKER_01]: Du kannst natürlich auch eine Teamaktivität rausmachen. [SPEAKER_01]: Du kannst halt sagen, okay, du hast ein Team von vier Leuten. [SPEAKER_01]: Und dann splittest du in zweimal zwei grobben auf. [SPEAKER_01]: Und sagst du, okay, du nübst jetzt zwei Stunden Zeit. [SPEAKER_01]: Und gehst als Team durch das Backlock und versuche sie, Backst du reproduzieren. [SPEAKER_01]: Du versuche sie nur zu reproduzieren.

[SPEAKER_01]: Und wenn du es geschafft hast, dann abdätst du mit deinen Informationen das Backticket. [SPEAKER_01]: Und wenn du es nicht geschafft hast, schließt du den Back. [SPEAKER_01]: Das kannst du natürlich auch mal. [SPEAKER_01]: Ist doch ein gutes Zeitinvestment. [SPEAKER_01]: Ist so ein Mittelweg. [SPEAKER_01]: Und dann hast du den Kontext.

[SPEAKER_01]: Und vielleicht sagst du, dass es eine 30 Minuten Sache [SPEAKER_01]: Eine Sache, die mir noch wichtig ist, zu erwähnen, ist die tematik, dass Leute Backsteklarieren und es eigentlich in Missing Feature ist. [SPEAKER_01]: Denn da habe ich einen schönen Vergleich in der Vorbereitung gelesen und zwar zwischen sogenannte KTLO-Work, also Kiebse Leitz-On und ab und zu auch mal, ich sag mal, Backs, die dann zu größeren Refactoring führen.

[SPEAKER_01]: Und der Vergleich war deine Wartungsarbeiten an deinem Auto, ist eher so KTL Over, okay?

[SPEAKER_01]: Also du packst da neue Reifen drauf, du fühlst das Öl nach und so weiter. [SPEAKER_01]: Das sind ja alles keine Dinge, die etwas verbessern, sondern du verhinderst nur, dass das K, dass das K, dass das Auto kaputt geht und du verlängst irgendwie die Lebenszeit des Auto, das du's einfach weiter nutzen kannst, aber du setzt er jetzt keine neuen Felgen drauf, [SPEAKER_01]: wo im Gegensorfer so mehr wie Gartenarbeit ist, in Gartenarbeit kannst du kein KTL ummachen.

[SPEAKER_01]: Weil du, du flanzst die Flanzen und du, amachst vielleicht die Rasenkannte ein bisschen rund, wer du die Seins dein Garten, dann kümmest du dich natürlich irgendwie um die Flanzen du, du wässer sie, du schneiden sie zurück, ist das vielleicht KTL?

[SPEAKER_01]: Oh ja, vielleicht so ein bisschen, [SPEAKER_01]: Aber im Endeffekt musst du dann teilweise auch mal Refaktorierungsarbeiten in einem Garten machen, wie zum Beispiel im E-Unkraut ziehen oder dann eine Wasserleitung ist geplatscht und so weiter. [SPEAKER_01]: Also Software ist so mehr wie der Garten und weniger wie das Auto und deswegen ist halt echt irgendwie ich glaube ich schwierig und vielleicht geht es auch wieder zurück auf die Backdefinition.

[SPEAKER_01]: Ja was ist jetzt wirklich ein Back? [SPEAKER_01]: Und was ist jetzt kein Back? [SPEAKER_01]: Und das so ein Einzel verständnis hast? [SPEAKER_01]: Was ist wirklich notwendig? [SPEAKER_01]: Was ist Katie? [SPEAKER_01]: Oh, was ist notwendig? [SPEAKER_01]: Um die Software weiter am Leben zu halten? [SPEAKER_01]: Und was ist mehr, der nacheierarbeiten? [SPEAKER_00]: Wie heißt zu schön, jeder vergleich hinkt oder wie war das?

[SPEAKER_00]: Also, heute ist die Episode der schlechten Vergleich auf meiner Meinung nach.

[SPEAKER_00]: Aber ich verstehe grundsätzlich, was du meinst, meine Herangehntz, weiß es, er muss sich das überhaupt groß unterscheiden, weil am Ende habe ich meine Newse im Auge und der soll in eine gute Experience haben und ob das jetzt ein Back ist der irgendwas beeinträchtigt oder ein absolut kritisches Feature, was fehlt, ist im Endeffekt eigentlich egal, ist ähnlich wichtig, meine Meinung nach, aber natürlich, wenn du

[SPEAKER_00]: Klassisch, wir hatten das ja auch mal in einer Episode, wenn man Prozentuelle Aufteilung macht, was ist KTLO, Work, was ist neue Feature, Work, jetzt auch in den 70-30-Gregeln, 60-40-Gregeln, dann ist das vielleicht wichtig, dass natürlich so zu Kategorisieren, der stimmt natürlich schon. [SPEAKER_01]: Ja, das ist fair, was du sagst und ich stimme dir auch zu, dass du den User im Auge behalten musst.

[SPEAKER_01]: Aber du musst im Endeffekt an der Entscheidung treffen, besonders wenn du in der Ausgangssituation bist, die du geschrieben hast, du hast ein super elanges Beckler. [SPEAKER_01]: Da musst du eine Entscheidung treffen, was nimmst du zuerst an. [SPEAKER_00]: Aber auch da kann sein, dass ein neues, fehltsche wichtiger ist als ein alten Back zu beheben. [SPEAKER_00]: Weil vielleicht ist Fitscher mehr Impact hat als der alte Back.

[SPEAKER_01]: Und da sind wir wieder auf der Definition von Impact und noch selber auf seiner Sichtweise. [SPEAKER_01]: Wenn du das CEO bist, natürlich ist dann ein neues Fitscher immer wichtiger als ein Back. [SPEAKER_01]: Denn dieser bringt natürlich mehr Geld. [SPEAKER_01]: Und das bringt natürlich mehr Geld in deine Hosentasche und bla bla bla bla. [SPEAKER_01]: Aus Sichtweise des Entwickler Teams, was der Back dann immer vier Stunden zu ist.

[SPEAKER_01]: Ich im Manuelle Arbeit in der Woche erzeugt, ist gegebenenfalls dann ein anderer Impact. [SPEAKER_00]: Ich hatte mal das Ganze mit der Lebt in einer Firma, wo es wirklich darum gegangen ist, um einen kleinen Back, der einen recht kleinen Userkreis, eigentlich betroffen hat. [SPEAKER_00]: Und es war, glaube ich, auch nur eine Zeitberechnung oder so, was war, auch, glaube ich, mit Browser, mit alten Browseren, hatte das zu tun. [SPEAKER_00]: Und das Ganze ist so hoch gekocht.

[SPEAKER_00]: dass sich teilweise der Sea Level eingeschaltet hat. [SPEAKER_00]: Nur für diesen einen Back und es gab Besprechungen und Meetings, wo Qualete Ashurance gegen product diskutiert hatte und die Wellerbar auch, glaube ich, noch mit dabei. [SPEAKER_00]: Ob das jetzt wichtig ist, diesen Back für die 0,6% User zu fixen oder nicht.

[SPEAKER_00]: Also es hat Stunden verbraten in Meetings, sie glaube am Ende, wenn ihr das richtig im Kopf habe, wo der entschieden QA, also Qualete Ashurance hat, [SPEAKER_00]: Das letzte Sagen und wenn dies sagen, es ist wichtig, dann entscheidend die.

[SPEAKER_00]: Meine Meinung nach, wurde eher product, wichtiger sein, product ohne, aber muss man irgendein Weg finden, aber nur um zu zeigen, wie weit oder wie groß das Ganze werden kann, wo es nur darum geht, wurde eine Zeit richtig berechnet oder nicht. [SPEAKER_01]: Das genau mein Humor von Internetpolitik, ja, und irgendwie auch [SPEAKER_01]: genau so ein so machthaber und meine Sachen es nach ist da eindeutig nicht klar, wer die Rohalt über das Produkt hat.

[SPEAKER_01]: Wenn du dir einfach nur mal die totalen Kosten ausrechnen würdest für diesen Back. [SPEAKER_01]: Also auf Basis der Meeting zeit und co, dann würde ich auch mal die Frage stellen, weil diese komische Berechnung so wichtig, dass diese, weil sie nicht viel stelle ich fünf Stelle gekosten erzeugt hat. [SPEAKER_01]: Weil die Menteffekt sind, dass er operatien Setskosten von der Sieler bemämmt, hat vielleicht wichtige Dinge zu tun.

[SPEAKER_01]: Das Sieler bemämmt, man hat einen Schienen, dass es keine wichtigen Dinge gibt, als diesen Weg. [SPEAKER_01]: Aber da wird man schon ein bisschen schwindelig, wenn ich diesen Geld betrag, nur in meinem Kopf hochrechnen. [SPEAKER_00]: Es war natürlich dann auch auf der technischen Seite, wenn es richtig im Kopf habe, ein sehr großer Aufwand, weil zum die Unterstützung von alten Browseren gegangen ist.

[SPEAKER_00]: Und da hast du natürlich, wenn du zum Beispiel Libraries verwendest, die nicht mehr die alten Browser-Supporten und des Deppricate, dann hast du natürlich das Problem, dass du die die Library eigentlich nicht mehr verwenden kannst, oder nicht abdaten kannst. [SPEAKER_00]: Und dann hat es natürlich auch extrem großen Impact auf der technischen Seite.

[SPEAKER_00]: Also darum, was du hier richtig gesagt hast, man muss auch auf der technischen Seite den Aufwand sehen und denn dann auch vergleichen zu dem Impact auf der User Seite. [SPEAKER_00]: Ab da wird's dann schon sehr komplex. [SPEAKER_00]: Was dann wichtiger ist, welche Zeit wichtiger ist. [SPEAKER_00]: Und da ist es dann auch gut, wenn man einfach eine Struktur hat, wer entscheidet es dann?

[SPEAKER_00]: Wir hatten ja auch eine Episode zu entscheidungen, wo es darum ging, dass es wichtig ist, eine Therapie zu haben, auch wenn die selten zu anwendung kommt. [SPEAKER_00]: Aber wenn du dann mal so kritische Box hast, wo das entschieden werden muss, dann muss es halt eine Position geben, die im Ende des Sagen hat und dann entscheidet, was ist wichtiger. [SPEAKER_00]: Und meiner Meinung nach ist es eher auf der Produktezeite, weil die Produktezeite verantwortlich ist für das Produkt.

[SPEAKER_00]: Aber kann natürlich jede Firma entscheiden, wie sie will. [SPEAKER_01]: Tollig Diskussion einfach aus dem Weg zu gehen, ist eine sogenannte Zero-Buck-Policy. [SPEAKER_01]: Ah, das ist was, was ich habe, oder? [SPEAKER_01]: Ich habe keine Box. [SPEAKER_00]: Mein Code ist Backfree. [SPEAKER_00]: Hab kein Problem. [SPEAKER_01]: Hier du ignorierst, das ist die Zero Ignorens. [SPEAKER_01]: Nein, das ist die Allignorens Backpolicy, die du betreipst.

[SPEAKER_01]: Ich rede von der Zero Backpolicy in der es darum geht, dass Box sofort gefixed werden, dass sie gar nicht erst gemennetscht werden müssen. [SPEAKER_01]: Das Software-Tool Linear, es so eine Art Project Management-Giro-Competitor, ist da sehr bekannt für, dass dies was betreiben. [SPEAKER_01]: Was ist deine Meinung zu diesem Thema? [SPEAKER_01]: Hast du das schon mal in der Realität erlebt, dass du das funktioniert?

[SPEAKER_00]: Ich hatte immer Teams, die ein sehr großes Spekler kann. [SPEAKER_00]: Also ich leese das immer wieder, aber ich frage mich immer, wie funktioniert das in der Realität? [SPEAKER_01]: Ich glaube, Etyorie ist wundervoll und ich glaube, Etyorie ist sehr gut. [SPEAKER_01]: Ich glaube, die Praxis schwierig. [SPEAKER_01]: Ich denke, das Ganze muss wirklich in der kompletten Firma gelebt werden.

[SPEAKER_01]: Das muss von oben herabkommen, denn wenn ein einzelnes Team das bestimmt, dann hast du immer Konflikte zwischen auch dieses Feature ist wichtiger und dieser Deal hängt von diesem neuen Feature ab und zu weiter und zuvor deswegen müssen wir das Backfixing depriorisieren.

[SPEAKER_01]: Also ich glaube, es muss eine effektive 4.000 Kultur darum geschaffen werden, dass sie eine tematik, woran es noch mich erhofft scheitert, [SPEAKER_01]: speziell bei wachsenen Firmen, dann die zweite thematik. [SPEAKER_01]: Es ist ein Unterschied, hast du ein existierendes Produkt an ein existierendes Codebase und eine lange Historia oder Fenx zu auf der grün Wiese an.

[SPEAKER_01]: Und ich denke, du musst sehr gute Geidens haben, was ein Back ist und was eine fehlendes Wirtschaft ist. [SPEAKER_00]: Also es ist interessant zu wissen, wie Linia das wirklich umsetzt. [SPEAKER_00]: Was sie mir schon vorstellen kann und was sie an sich eine gute Errangehensweise finde, ist, dass man, wenn man neue Fieges programmiert, dass man sagt, diese Fieges müssen backfree sein, in dem Sinne, dass wir keine Box entdeckt haben.

[SPEAKER_00]: Und ich spreche jetzt nicht von den Problemen. [SPEAKER_00]: Das mit kein MVP mehr bauen könnte, das ist ja okay, dann kann man die Features reduzieren. [SPEAKER_00]: Aber diese Features, die man Release-Zirken backfree sein und auch nicht UX-Backfree, weil das man vielleicht noch was optimieren kann in der User Experience oder im Flow. [SPEAKER_00]: Das ist wieder was anderes.

[SPEAKER_00]: Aber die Features, die man Release-Zirken so funktionieren, dass eben keinen Fehler helfen, dass sie falsche Berechnungen durchführen. [SPEAKER_00]: Also, dass sie von der Seite wirklich backfree sind. [SPEAKER_00]: Weil, wenn man Backs akzeptiert und sagt, okay, ich relise jetzt dieses Features, es hat noch einen kleinen Back, das, wenn ich wieder falsche Herangehensweise.

[SPEAKER_00]: Weil da bin ich noch im Kontext, ich kann noch schnell fixen, ich kann meine Zahlen Code, die geschrieben habe, hoffentlich, wenn es nicht die AI geschrieben hat, dann kann ich noch schnell was fixen und da bin ich noch malerweise schneller. [SPEAKER_00]: Und diese 5% mehr Zeit, die sollte man investieren, aber wieder richtig sagst, das muss halt dann auch.

[SPEAKER_00]: In der Kultur so verankert sein, dass es überabfunkteniert und nicht die Produkte ohne sagen, ja, na, wir müssen realisten, es können wir eine Tag später noch fixen. [SPEAKER_01]: Ja, ich glaube, ein Mittelweg von dieser Zero-Back-Polle-Ci, um es das auf ganze Produkt anzuwenden ist, jetzt, okay, ich schippe nur als Fiecher und sage, die nächsten zwei Monate, verfolge ich eine Zero-Back-Polle-Ci auf das neu gerießt Fiecher.

[SPEAKER_01]: Ich glaube, das könnte ein Weg sein, wo auch Teams mit einer Software die Historie hat, langsam mit diesen Weg exorometieren können. [SPEAKER_01]: Aber warum die nächsten zwei Monate? [SPEAKER_01]: Weil die Theorie ist, dass wenn ein neues Fiecher da ist, dass das Fiecher Initial mehr Backs hat. [SPEAKER_01]: Man kann es auch auf vier Monate machen. [SPEAKER_00]: Würdest du dann Backs zulassen, die schon bekannt sind?

[SPEAKER_00]: Also würdest du ein Fiecher Releaseen obwohl du weißt, dass Backs hat? [SPEAKER_00]: Weil das danach Backs kommen, das kann ja immer passieren. [SPEAKER_00]: Also es kann ja sowieso nicht verhindern. [SPEAKER_01]: Das wäre dann schon flicht, dass du das Feature nicht realist wenn du Bugs weißt, denn im Endeffekt ist das ja die Augen zu machen, zwar etwas.

[SPEAKER_01]: Also wo ist der Unterschied, wenn du es Feature schippst und da kommen ein Back rein oder du schippst das Feature mit einem Back, den du bereits kennst, da sehe ich kein großer Unterschied, wenn du die Zero Back policy auf neuen Features anwenden möchtest. [SPEAKER_00]: Also, was du sagst, ist, dass die Priorität den nächsten zwei Monate dann automatisch hoch wäre, wenn ein Back zu einem realisten Feature reinkommt.

[SPEAKER_01]: Zu dem Neuralisten Feature, ganz geil, das ist auch eine halbe Wertzeit von zwei Monaten. [SPEAKER_01]: Und ob es jetzt vier Wochen sind oder sechs Monate, da kann ich da ein Produkt nicht. [SPEAKER_01]: Aber dass du dir selbst eine Deadline setzt. [SPEAKER_01]: Weil sonst hin, dass du ja schon das komplette Feature development. [SPEAKER_01]: Also, wo man ganz klar sein muss, ist, dass das nicht das eine Xtreme oder das andere Xtreme gibt.

[SPEAKER_01]: Das eine Xtreme ist bei den Software-Entwickler-Times in der Regel. [SPEAKER_01]: Wir müssen immer alle Backs fixen und immer Stabilität machen. [SPEAKER_01]: Immer Katie Lohen so weiter. [SPEAKER_01]: Das stößt natürlich irgendwie auf negativen Stimmen. [SPEAKER_01]: Da eine Männisch-Männisch-Männisch-Männisch-Männisch-Männisch-Männisch. [SPEAKER_01]: Und dann kommen die Produktownerseitung, die Seelöffelseitungsniederschöpseitung.

[SPEAKER_01]: Wir müssen mehr Features wie Chastiche machen, wir haben keine Zeit zum Box. [SPEAKER_01]: Aber wenn man sich gegenseitig in der Mitte trifft, ich glaube, dann kommt man relativ gut klar. [SPEAKER_01]: Und wenn man sich diese Halbfettzeit, diese Deadline von zwei Monaten, dann setz dich, ich glaube, das ist so in der Mitte treffen.

[SPEAKER_00]: Es ist vor allem wichtig, wenn man so eine forkussierung auf neue Features hat, wenn man sonst die klassische Polisi hat, wir bewerten alles nach Inbeckt, weil üblicherweise neues Featuren Back hat keinen hohen Inbeckt, weil es ja noch eine kleine User base gibt, üblicherweise. [SPEAKER_00]: Also je nachdem, was es für ein Features ist, aber ganz oft fangen ja erst an, meine User dieses Featured zu verwenden.

[SPEAKER_00]: Das heißt, es ist ein nur ein kleiner Prozentsatz oder vielleicht überhaupt nur in den Alpha testgruppe oder bettertestgruppe und dann würde natürlich mein Back nie hoch Priorisiert werden, weil ich ja immer auf im Back gehe. [SPEAKER_00]: Das heißt, wenn man da eine zweite Dimension hinein bringt, dass man eben diese zwei Monate Focus Zeit auf dieses neue Realistic feature hat, dann deckt man natürlich beide Welten ab und kann so das auch Priorisieren.

[SPEAKER_01]: Einen riesen Schreithemer, was mir schon wirklich oft untergekommen ist, wie schaffen man eigentlich Zeit und Raum, um Backs wirklich zu fixen, denn wir kennst alle vor dem Feature ist nach dem Feature. [SPEAKER_01]: Also mit Formen, das eigene Feature, was man jetzt schon entwickelt hat, geschippt hat, planen andere schon am nächsten Feature, deswegen man hat ja nie Zeit, wenn man halt immer im nächsten Produkt ist und was war deine Strategie als du damals?

[SPEAKER_01]: vor dem Krieg 1900 noch Engineering-Manager-Was. [SPEAKER_00]: Was war sie? [SPEAKER_01]: 1700, was? [SPEAKER_01]: 1700. [SPEAKER_01]: Was war dein Weg um deinem Team Zeit- und Raum für das Backfaxing zu geben? [SPEAKER_01]: Das war relativ einfach jemand mit guten Produkte und dann zusammengearbeitet. [SPEAKER_00]: Das bedeutet, du hast die Arbeit und die Argumentation auf dieser anderen Leute abgewählt. [SPEAKER_00]: Ja, so kann man das sehen.

[SPEAKER_00]: Also, ich habe das deutlich gesehen, dass die guten Produkte ohne das sehr wohl im Auge hatten und dann eine gute Balance gefunden haben. [SPEAKER_00]: Und die schlechterin, also ich sage jetzt mal schlechterer Product Owner, da hat es mehr Knatschgegeben zwischen Team und Product Owner, wenn es eben diese Balance nicht gegeben hat. [SPEAKER_01]: Aber was heißt das? [SPEAKER_01]: Ihr habt dann ein Continuous-Back-Fixing betrieben.

[SPEAKER_01]: Sie habt dann die Backs unsere Go-Gefix. [SPEAKER_01]: Der Pollack hat dann eine Balance-Jährung zwischen ich erschaffen neuen Value und ich verhindere das Value runtergeschraubt wird. [SPEAKER_01]: Also los Prevention oder wie darf man das sagen? [SPEAKER_01]: Also habt ihr irgendwie so ein Scrum?

[SPEAKER_01]: Sprint gehabt und da habt ihr dann immer [SPEAKER_01]: fünf Box mit reingenommen oder hat er die Dalimmelz oder hat er einfach gesagt auch nee jetzt machen wir einen kompletten Backsprint oder wie hat das funktil.

[SPEAKER_00]: Das Gute ist ja, wenn man so viele Episodeen hat wie wir, dass man immer auf andere Referenzieren kann und wir hatten mal in Episode 102 wo es um Kradalsplan und gegangen ist genau darüber gesprochen, dass man eine Balance finden muss zwischen KTLO gibt der Leitzorn 9 Features und so weiter. [SPEAKER_00]: Bei diesen Teams [SPEAKER_00]: Mit den guten Produkte ohne Hats eigentlich selten so eine genaue Spezifikation, also im Sinne von Prozenten gegeben.

[SPEAKER_00]: Die hatten das einfach ganz gut im Gefühl und hatten dann einen Sprint Planings, das einfach auch noch im Becht, preurisiert und dann aber immer mit hinein genommen. [SPEAKER_00]: Aber haben auch unbedingt darauf geschaut, dass das eben sinnvolle Balance ist, da kommt ja auch dann das ganze Thema von technische Schuld noch mit rein, was jetzt keine Back sind, aber natürlich auch irgendwas, was beachtet werden muss.

[SPEAKER_00]: Und die hatten das dann natürlich auch je nachdem, wie gerade der aktuelle Stand war, also wo befindet man sich im Quadal, es crunch time oder nicht, haben das dann dementsprechend auch noch mit reingenommen und da die richtige Balance gefunden. [SPEAKER_00]: Aber es gibt natürlich auch Möglichkeiten, dass man es einfach konkret anspricht und vor allem in Teams, wo es ganz viele Backs gibt.

[SPEAKER_00]: Also über einmal auch für ein Team verantwortlich, wo extrem viele Backs reingekommen sind. [SPEAKER_00]: Also wo es um nicht suchen, engen gegangen ist und zuhe kann immer nur falsch sein. [SPEAKER_00]: Also was wird gefunden, je nachdem was ich für einen Zugbegriff eingebe. [SPEAKER_00]: Und da sind Bags reingebrasselt, es kann gar nicht schlimmer sein. [SPEAKER_00]: Ob man die, als Bags sieht, ist dann noch mal eine andere Frage, aber da war dann Priorisierung extrem wichtig.

[SPEAKER_00]: Da hat man sich dann natürlich auch in meetings mit dem Team zusammengesetzt und hat Priorisiert.

[SPEAKER_00]: Welche Box überhaupt löisbar sind, was das auf der Technischen Seite bedeutet, was das für ein Impact auf das gesamtes System hat und hat wirklich in konzentrierten Meetings, die wichtigsten Prioritäten oder die wichtigsten Box gemeinsam herausgefilft hat aus diesem riesen Bullk von Box, weil da sind wirklich da täglich, wird mal sagen, hundert der Box auf ein Team fast eingebrasselt.

[SPEAKER_01]: Okay, das bedeutet ihr habt teilweise Backshöhe als Features preurisiert und ihr habt dann über die So einer Art Weekly Back Pickup gemacht, keine Ahnung, ihr habt dann in den Back Meetings 5 Backs rausgenommen, die dann als nächstes Cliffix werden und dann. [SPEAKER_00]: Genau, hat auch keine...

[SPEAKER_00]: Fixen nun mal jetzt gegeben, fünf Bugs, aber grundsätzlich, dass man sich zusammensetzt und über diese ganzen Probleme sprich sehr wohl, wobei auch, wenn der Produkt ohne natürlich auf der Technischen Seite sehr gut ist, dann hat der auch einen gewissen Einblick, um kann schon vorfiltern, dann kann vielleicht da das Team ein bisschen entlasten, weil wenn du mit dem Team immer 100 Bugs durchgehen musst, das ist dann schon natürlich auch Zeit auf Reibend und bringt dann weniger, so da hast du dann im Idealfall ein Produkt ohne

[SPEAKER_01]: Also, wenn ich zufriedi verstehe, hilft das natürlich oder bzw. [SPEAKER_01]: das war der Ansatz, dass man das Backback-Lock einigermaßen stabil hält, oder? [SPEAKER_00]: Also, du musst es dann einfach akzeptieren, dass du ganz viele Hunderte auf eine Box hast. [SPEAKER_00]: Also, du wirst ihn zonen, die nie alle Box lösen können. [SPEAKER_00]: Das ist einfach unmöglich. [SPEAKER_01]: Die Grundvoraussetzung ist, dass mehr Box reinkommen als man fekst und kann.

[SPEAKER_01]: Meine Rudecaus-Analise würde dann eher fragen, habt ihr dann nicht ein ganz anderes Rundproblem. [SPEAKER_01]: Also, einwickelt in die richtige Lösung. [SPEAKER_01]: Also, ist die richtige Lösung. [SPEAKER_01]: Implementiert worden auf Basis der Anforderung, wenn man so viele Box hat.

[SPEAKER_01]: Also so liegt das Grundproblem nicht an der Software selbst, sondern vielleicht an der Qualitätsicherung oder an der Erwartungshaltung oder an der fehlende Definition, was die Software eigentlich tun soll und das ist keine Abgrenzung gibt. [SPEAKER_01]: Also das muss ja nicht beantworten, aber wenn so viele Box kontinuertig reinkommen, sollte man vielleicht dahinter schauen.

[SPEAKER_00]: Da hast du natürlich recht und wenn du aus einer Software oder Plattform bestpektive kommst, dann hast du dann natürlich recht. [SPEAKER_00]: In dem Fall ist es um eine Suchmaschine gegangen. [SPEAKER_00]: Also das ist nicht deterministisch, was dort passiert. [SPEAKER_00]: Könntest du das auch weiterziehen in Data Science oder Recommendasystems oder irgendwelche Produktschen Algorithm entwickelt? [SPEAKER_00]: Weil da gibt es ja kein richtig und falsch.

[SPEAKER_00]: Da gibt es nur eine Anneerung an das richtig und jeder benutzer benutzerin hat eine andere Welt von richtig. [SPEAKER_00]: Wenn du eine Recommendation jetzt bekommst, dann hast du eine ganz klare Vorstellung, was da eigentlich jetzt rauskommen sollte. [SPEAKER_01]: Warte ihr damals in der Lage, das System zu verstehen, warte ihr in der Lage zu sagen, und ich habe diesen Supergriff eingegeben, das ist das Resultat und hier ist ja klare rum, warum?

[SPEAKER_00]: Da er weiß ja ja, da er weiß es ist hier zu dessen natürlich, aber du hast bei Recommendosystems, ja das allgemein Problem, dass wenn du irgendwo was ändest, jetzt oder in Data Science ganz allgemein, wenn du und Gewicht ändest. [SPEAKER_00]: z.B. [SPEAKER_00]: irgendwo oder nen Läher, wenn es jetzt um irgendwelche AI-Algeridmen geht, dann hast du vielleicht dann ein richtiger Resergebnis, aber an 10 anderen Erken plickte wieder was um die Ohren.

[SPEAKER_00]: Und das musst du natürlich immer balancieren und z.B. [SPEAKER_00]: du in so einem Umfeld unterwegs bist, ist ein Backhalt kein klare Back mehr, weil du hast nicht nur nur nun und einsen, weil ein Back kann halt im Blickwinkel des Juselsen Backs sein, aber für andere ist vielleicht kein Back. [SPEAKER_00]: Ich glaube in der UX-Ecke hast du das selber Problem.

[SPEAKER_00]: Weil eine gute UX ist halt für manche User und Back und für andere User ist vielleicht der UX-FloE der korrekte. [SPEAKER_00]: Das heißt, sobald so weiche Kriterien gibt wird das Ganze natürlich nochmal schwieriger und da ist dann halt auch noch mehr Fingerspitzen gefühlt gefragt, wenn man über Beurteil muss, ist ein Back und Back. [SPEAKER_01]: Ich finde, das ist ein sehr schönes Beispiel von ich lebe in meiner Babe.

[SPEAKER_01]: Ich bin offen und ehrlich, dieses Beispiel hatte ich jetzt nicht auf dem Aufnusschirm mit den Recommended-Systems. [SPEAKER_01]: Ich muss auch zugeben.

[SPEAKER_01]: Ich finde nicht der feministische Systeme immer sehr schwierig, weil viele nicht der Terministische Systeme können einfach nicht erklärt werden, wie das System zu diesem Ergebnis kam und das werde ich immer sehr traurig, weil das hat immer so ein bisschen Gedanken, wie ich weiß nicht, was das System hier macht und dann stellt sie die Frage, habe ich noch die volle Kontrolle über das System.

[SPEAKER_01]: Aber das geht auch schon wieder in die Philosophie ab, wie wir in dieser Infasore schon ab zu mal abgetrifft sind. [SPEAKER_01]: Deswegen finde ich das ein sehr schönes Beispiel, hat ich nicht aufschirmen. [SPEAKER_00]: Und sogar, wenn der Städter meines Tisch ist und du weißt, warum das besiert ist, ist es halt oft so, wenn du was endest, knallt an 20 anderen Ecken.

[SPEAKER_00]: Und dann ist vielleicht eine Lösung, die du siehst, halt nur ein Lösung für einen, für einen Back und du machst aber 100 neue Backswitter damit auf. [SPEAKER_01]: Da würde ich mich mal aus dem Fenster lehnen, da würde ich sagen, wenn du die feministische System hast und du änders eine Sache und Kneils an anderen System hast du einen Riesenflow in der Nallogik oder zu wenig testst.

[SPEAKER_00]: Du hast ja schon testst, die dann vielleicht anschlagen und sagen, hey, du hast jetzt aber bei 100 anderen Suchbegriffen oder Kontexten, wo du einen Recommentation dann ausspuckst, da hast du wieder einen schlechter Resser gemis. [SPEAKER_00]: Und dann musst du überlegen, hmmm.

[SPEAKER_00]: Der Backfix ist jetzt insgesamt gut, der löst zwar diesen einen Back, aber an 100 anderen Stellen ist es vielleicht wieder schlechter, wobei schlechter ja auch wieder teilweise gar nichts zu genau definierbar ist. [SPEAKER_00]: Aber versucht, du dann nicht die Eilänge wollen mich auch zu programmieren, aber das hast du genau in diesen Bereichen.

[SPEAKER_00]: Also, du probierst hierherwend zum Unteranführungszeichen, Intelligenz geht AI, KI, Search Results, Information Retriever, machst du ja immer nur eine Anneerung an das [SPEAKER_00]: Ergeben ist, du kannst ja nie das absolute perfekte ergeben ist erreichen und das ist die Eierlegende wollen wir nicht so die du probierst zu erreichen und zwar auf ganz vielen Dimensionen. [SPEAKER_01]: Gut, da hat die Historie gezeigt, dass dies oft nicht funktionieren.

[SPEAKER_01]: Komm jetzt zurück zum Thema, wie schaff mir eigentlich Zeit und Raum umwachsen zu fixen. [SPEAKER_01]: Was hält so von dem ganz klassischen Prinzip, dass man sagt, du gibst dem Team Provo-Promonat oder pro Sprint einen gewissen Prozentualanteil umwachsen zu fixen 10, 15, 20%. [SPEAKER_00]: Es ist sehr gute Variante, wenn es Probleme gibt.

[SPEAKER_00]: In einem gut funktionierenden Team mit einem guten PO, brauchst du das meiner Meinung nach nicht, weil der funktioniert das automatisch. [SPEAKER_00]: Der PO kann das gut, managen mit dem Team oder Projektmanager, was es immer ist. [SPEAKER_00]: Sobald es dann natürlich nicht mehr funktioniert und sich die Entwickler in den Beschweren zum Beispiel, oder irgendwie ständig die Diskussionen haben, dann kannst du natürlich mit so einem Modell Klarheit schaffen.

[SPEAKER_00]: Aber da ist dann die Frage, machst du das eben zeitlich abhängig, wo von du, wo du jetzt gerade bist, in manchen Industrien gibt es natürlich irgendwelche speziellen Event zu wie Black Friday, wenn du jetzt im IKOMAs Bereich bist, dann wirst du nicht in der Woche vom Black Friday jetzt sagen können, ich mache 90 Prozent Backfixing oder Technikul-Dapt oder solche Dinge.

[SPEAKER_00]: Also es muss man dann natürlich auch mit einberechnen, aber grundsätzlich wenn es Probleme gibt, so eine Polizie mal zu definieren, um so eine Grobe Richtung zu haben, macht absolut Sinn oder vielleicht auch in Teams die weniger erfahren sind, dass man einfach mal so eine Geidlein hat, an die man sich richten kann. [SPEAKER_00]: Das macht absolut Sinn, dass man 30% Backfixing macht und 70% ist der Rest.

[SPEAKER_01]: Ja, ich glaube, das Stichwort ist grobegeitlein, ne, denn immer wenn man sagt, Engineering Power hat auf Stunden gemützt, dann ist es immer schwierig, weil wir Träken den Erfolg unserer Software-Teams hoffentlich nicht anhand erstunden, die wir in die Pandemie rein gesteckt haben, sondern hand der Sachen an der wir arbeiten. [SPEAKER_00]: Aber du kannst ja Scrum Points machen.

[SPEAKER_00]: Wenn du die Punkte in Sprintblaning dann definierst, dann sagst du halt so, um zu viele Punkte gehen an Bucks oder Problemen, Behebungen und so und zu viel an neue Features und dann hast du nur bei Keep the Lights on Buckte. [SPEAKER_01]: Ja, ich bin kein Fan von Scrum. [SPEAKER_01]: Ich bin auch kein Fan von Scrum Schätzen.

[SPEAKER_01]: Ich bin eher der [SPEAKER_01]: Der kann mansteil Mensch, weil ich denke, dass Produkte und Teamverhalten und die reale Welt viel zu komplex ist, um auch fixe zwei Wochen zu machen, ich denke, es gibt immer Arbeit, die von links und von rechts reinkommt, die wir dann in den Sprint mit reinknerlen möchten. [SPEAKER_01]: Ja, auf der Ecke, dass ich ziemlich vieles Marteläuter in den Teams habe und auch bezahlen, die dann schon verantwortungsbewusst handeln.

[SPEAKER_01]: Und natürlich hat man dann gewissen Fokus, weil die Tickets, die im Kannwanz, da sind sollen schon irgendwie eine Synergie zu erinnern haben. [SPEAKER_01]: Aber ich würde noch nie mit's Gramm wirklich warm, muss ich zugeben. [SPEAKER_00]: Ja, wobei du natürlich jetzt nie in Product Teams gearbeitet hast, sondern das ist eine Lüge, ja. [SPEAKER_01]: Ich habe auch Product Teams geleitet. [SPEAKER_01]: Platform Team ist auch ein Product Team, ja, möchte ich nur mal ganz kurz sagen.

[SPEAKER_01]: Ja, im Plattformbereich und da hast du natürlich weniger Planbarkeit. [SPEAKER_01]: Ich möchte nur sagen, dass ein Platform Team ebenfalls ein Produkt Team ist. [SPEAKER_01]: Denn man schibt auch ein Produkt, nur da eine Kulturlinie. [SPEAKER_00]: Es gibt halt Bereiche, da ist Kram besser geägnet und bei anderen ist kann man vielleicht besser geägnet oder überhaupt eine Feuerlösstechnik gibt alle Varianten.

[SPEAKER_01]: Was hältst du von dem anderen extrem, dass man dir die Zierte Backs friends oder Backdays hat, so heggert uns soll? [SPEAKER_01]: Da wo man sagt, okay, zwei Tage nur Backfixing oder einen ganzen Sprint von zwei Wochen machen wir nur Backfixing oder ähnliches.

[SPEAKER_00]: Also ich bevorzugt schon, die andere Variante, dass man eher so eine Aufteilung hat, also fokussierte Wochen, habe ja auch eher so die Erfahrung gemacht, dass das oft so vom Productseite dann als Ausrede kommt, dann machen wir halt irgendwie so zwei Tage und dann machen wir nur nur das Backfixing oder nur der Kinkildab, damit die Entwickler ihnen irgendwie glücklich sind und dann geben die schon eine Ruhe.

[SPEAKER_00]: Wenn es natürlich irgendwo in der Kultur verankert ist und Sinn macht, ist es etwas anderes, aber sonst finde ich grundsätzlich das regelmäßige Backfixing eigentlich die bessere Erange ins weiße, es immer so fokussierte Dinge, wo man dann vielleicht auch nur immer A oder B macht und nie die Abwechslung hat. [SPEAKER_01]: Ich find's grundsätzlich eine coolie Idee, ich nenne das immer Backsmash und ich glaube, die internationale Industrie nenne das auch Backsmash.

[SPEAKER_01]: Aber es hat ein paar Gefahren.

[SPEAKER_01]: Auf der einen Seite kann man sagen, ist das vielleicht ein Antipättern, weil irgendwie dann jeder sagen kann auch, den Backfix ich jetzt nicht, den Skippe ich jetzt, weil das können wir am Backdemachen oder am Backsmash oder am Hacketton. [SPEAKER_01]: Und dann machen wir sich weniger geblanken über Backs. [SPEAKER_01]: Das ist ja nicht ein bisschen schwierig, oder die Gefahr aus da.

[SPEAKER_01]: Dann ist die andere thematik, wenn man es mal ausprobiert, dann kann es eher so ein Hit und Miss sein. [SPEAKER_01]: Also entweder, es wird super gut angenehm und es funktioniert super, und man wird er holt, dass in regelmäßigen Abständen oder man erhofft sich mehr von dem Event und wird dann am Ende enttäuscht oder wird es nicht wieder holt. [SPEAKER_01]: Und das finde ich dann immer so ein bisschen schwierig.

[SPEAKER_01]: Eine Methode ist mir aber bei der Recherche aufgefallen, die ich super gut fand und zwar bei die so gewissen internen Druck erzeugt und relativ einfach ist und sehr klare Strukturen wirbt und zwar Deadline für Box. [SPEAKER_01]: Jeder Bag der reinkommt, dem gibts Zune Deadline. [SPEAKER_01]: Und die Deadline kann ja unterschiedlich sein.

[SPEAKER_01]: Die kann länger sein für Low Priority-Bucks kürzeseit für High Priority-Bucks und Zomiter, je nachdem, welche Gategorisierung man auch immer hat. [SPEAKER_01]: Je näher die Deadline kommt, desto höher wie die Priorität automatisch gestellt. [SPEAKER_01]: Und wenn die Deadline erreicht ist, und dieser Bag nicht gefix ist, wie dieser Bag automatisch zum Release-Blocker. [SPEAKER_01]: Klinkt die in der Theo Heesanet, hast du das mal in der Praxis so erlebt.

[SPEAKER_01]: Nein, habe ich nur bei der Recherche gefunden und in irgendwelchen Art und Weise, wie ich das gern mal ausprobieren. [SPEAKER_01]: Ich finde, das mit Halle Modell ist unglaublich einfach. [SPEAKER_00]: Ich finde ja auch sehr interessant kann ich mir in der Praxis irgendwie schwerer Vorstellen. [SPEAKER_00]: Aber wie gesagt auch da wieder, wenn die Kultur mit spielt und das wirklich in der Kultur festverankert ist, könnte das funktionieren. [SPEAKER_00]: Aber was ist eine Kritik?

[SPEAKER_00]: Ja, der Alltag. [SPEAKER_00]: Weil dann heißt halt doch wieder, ja, das Features wichtigen. [SPEAKER_00]: Warum sollen wir jetzt die fünf alten Backster fixen? [SPEAKER_00]: Und zwar alles verzögert, nur wegen fünf Backstinnen, jemand braucht. [SPEAKER_00]: Ja, ja, ja, umlegen. [SPEAKER_01]: Okay, das hast du aber bei jeder Art von Modell richtig.

[SPEAKER_01]: Und die Einfachheit dieses Modells ist halt, dass es jedem eine relativ klare Strutur gibt, um diese kontinuierlichen Fragen, die du ja gerade aufwürft, der Alltag. [SPEAKER_01]: Also das Problem an deinem Kursett mit dem Alltag ist einfach, dass du dich kontinuierlich immer die selber fragestellt und jedes Mal neue Diskussion hast und jedes Mal neu mieten muss um und alleine zu haben.

[SPEAKER_01]: Und wenn du ein solches Metalles Modell hast, um gehst du einfach unglaublich viele Diskussion. [SPEAKER_01]: Natürlich muss das Supportet werden von Daniel Liederschip, hierher hier, aber das Modell ist sehr einfach. [SPEAKER_00]: Ja, ja, ich finde es, ich finde es Modell auch super interessant, drum wird mich interessieren, ob das wirklich so funktioniert.

[SPEAKER_00]: Also, wenn ihr irgendwann kennt oder selber verwendet in eurem Team, bitte lasst uns das Wissenschaft mal vorbei, Diskot Community und schreibt uns, wenn dieses Deadline Modell bei euch im Team so funktioniert und auch von der Productseite akzeptiert wird, das würde mich eigentlich immer meist nicht interessieren.

[SPEAKER_01]: Jetzt ist es so, Bugs kommen ja immer rein und ich frage mich gerade bei der ersten Diskussion, wo wir hier drüber sprechen, von wem ist das eigentlich die Aufgabe. [SPEAKER_01]: Wer kümmert sich eigentlich um die Baktriage? [SPEAKER_01]: Wer kümmert sich eigentlich um die Baktriere, Priorisierung, Co-ISAS Engineering, Manager, Product, Owner, Project, Manager.

[SPEAKER_01]: oder hat man vielleicht sogar eine DDR-Zierte Person für Bags, also so ähnlich wie, weil sie nicht On-Koll, ja, dass man so eine wöchentliche Rotation hat, wo man sagt, okay, du bist On-Koll, oder du kümmest dich jetzt, um den Slack-Channel für die Bags, oder vielleicht hast du auch so ein Support-S Slack-Channel, oder sowas wo Leute Fragen stellen können, zu deinem Produkt. [SPEAKER_00]: Ich würde das auch wieder abhängen, machen von der Anzahl der Bags, oder da größte der Firma.

[SPEAKER_00]: Du hast wahrscheinlich irgendwo gebündelt, [SPEAKER_00]: einen Kanal, wo die Box herinkommen, es kann ein Support Team sein, es kann Quality Assurance sein, es kann automatisiertes Formulasein von außen, aber das ist da irgendwo eine Grundtreeaschung gibt. [SPEAKER_00]: Wenn immer das zu Asenfeuer, wer weissend denkt, gibt's eine Leitstelle, die nimmt alle Notrufe an und entscheidet dann.

[SPEAKER_00]: Wer überhaupt allermiert wird im nächsten Schritt. [SPEAKER_00]: So sehe das eigentlich auch, dass man da irgendwie eine Filterfunktion hat und nachgelagert kommen, dann die Entwickler in einen Anzug product owner product manager, wer das dann auch immer ist und die entscheidend dann im weiteren Schritt, was für Priorität hat es, wie gehen wir das an, wann wird das umgesetzt.

[SPEAKER_00]: Also, dass man da eine Person hat, die dediziert irgendwie nur für Box im Team vollem [SPEAKER_00]: ohne Seite. [SPEAKER_00]: Also die Person, die das entscheidet, was für neue Product Features gemacht werden, was wird gefigst von einem aktuellen Produkt, wird eigentlich entschieden von dieser Person und das ist ein Product owner oder Engineering Manager, wenn das mit übernommen wird, die Product Seite von dieser Rolle.

[SPEAKER_00]: Und dann kann es natürlich im Team besprochen werden und vielleicht noch mal fein Granularer diskutiert werden, aber das sind so viel mir diese drei Schritte. [SPEAKER_00]: Ganz nach außen zum Kunden, dann irgendeine Manager, Funktion oder Product [SPEAKER_01]: Bei uns im Team machen wir das genauso mit der Rotation. [SPEAKER_01]: Also wir haben new-buildity-Randetmodell bei uns in die Team mit Liederon-Koll in einer öffentlichen Rotation.

[SPEAKER_01]: Und wenn jemand On-Koll ist, dann hat diese Person auch die Aufgabe die Bakteria-Schrüchse für die Bakkiosierung. [SPEAKER_01]: Teilweise dann teilweise auch das Backfixing, je nach Abhängigkeit der Priorität und ob es dann wirklich KTL-O-Back ist oder nicht. [SPEAKER_01]: Ihr habt da, wenn er durch die Kunden auch eh dann, nah auch Exen. [SPEAKER_01]: Also wir kriegen auch Exenaryports von Exen Kunden, die dann auf unsere Plattform gehen.

[SPEAKER_01]: Die kommen aber über die Support, Schienehörern. [SPEAKER_01]: So die Theorie und dann gibt es natürlich, wie in jeder Firma, die ganz großen Kunden, die natürlich auch eine direkte Leinhaben in der eigene Art und Weise. [SPEAKER_01]: Die gibt es halt fast in jeder Firma. [SPEAKER_00]: Aber ihr habt, ihr habt auch keine Produkte ohne oder so was? [SPEAKER_01]: Doch, wir haben Projektmänner. [SPEAKER_01]: Und die können man sich nicht darum,

[SPEAKER_01]: Doch auch, aber die sind nicht on-Col. Nein, die sind nicht on-Col. Es geht auch so, dass die Leute die On-Col sind, in der Regel sich nicht auf Projektarbeit fokussieren, können weil halt so viel immer irgendwie dran ist.

[SPEAKER_01]: Und dann, wenn man so wie so die Kontextwirtschaft, wenn man sich so nicht auf lange Zeit freiburgt, aber auch die Bakterieerschmacht, das machen ja nicht jeden Tag, oder nicht sofort, wenn eine Barreinkompte und irgendwie ein oder zwei mal die Woche am Anfang und am Ende der Woche oder ähnliches. [SPEAKER_01]: Ich meine, die Benefit sind relativ klar, ne? [SPEAKER_01]: Also ich meine, man kommt relativ schnell in neue Themen rein.

[SPEAKER_01]: Akka und Bording, Knowledge Sharing, weil man kommt mit neuen Bereichen automatisch in Kontakt und jetzt kommt das guter eigentlich. [SPEAKER_01]: Wenn man Dokumentation hat, die Person, die dann die ganze Triage macht, ließ natürlich die Docs. [SPEAKER_01]: Man ärgert sich, dass diese Autofdates sind und dann abtädte man diese. [SPEAKER_01]: Also wenn man diese kontinuierliche Kultur der Verbesserung hat, dann bleiben die docks natürlich erlaubt zu dead.

[SPEAKER_01]: Es ist natürlich so, manchmal kommt Backstrain, die kann man nicht nicht körpern, da hat die Person ganz wenig anruhen, die werden dann ich nens mal eskaliert, dann werde ich in dem ticket gemenschend oder die Projektmännergerin oder ähnlich sind, dann gucken wir rein. [SPEAKER_01]: Aber das ist dann nur noch ein 15 Prozent der Fälle.

[SPEAKER_00]: Aber wenn da jetzt ein klassischer Backgreinkommt, irgendwann ein Produkt hat ein kleines Problem, dann wird da einfach ein ticket erstellt und dann geht es in der normalen Prozess hier ein und wird dann am Montag diskutiert oder product manager übernimmt es dann. [SPEAKER_01]: Ja genau, dann ist es abhängig was es ist und ob da jetzt gerade auf diesem Produkt Fokus ist und so, ne?

[SPEAKER_00]: Also es ist eigentlich eine Annahme Stelle oder wenn es ein high-private Back ist oder ein incident wird es mal fast nennen, dann übernimmt die Person auch wirklich sofort. [SPEAKER_01]: Ja, genau, also du musst halt zblitten, da kommt was rein, okay, wie wichtig ist das jetzt gerade, müssen wir das jetzt kaffern oder nicht und dann.

[SPEAKER_00]: Also, es sind eigentlich zwei Funktionen in einer Person, einerseits des klassische Encore incident, Management oder Annahme und die Backannahme und da halt die Träerstreff. [SPEAKER_01]: Ganz genau, und dann teilweise auch die Preuser oder Kategorisierung, wenn man jetzt in Putt braucht, also wir haben als Plattform Team. [SPEAKER_01]: Ich sag mal, hinter einer Produkte und die werden dann auch geläbelt und komponenten Zuf all das, was man halt so braucht.

[SPEAKER_01]: Wir sprechen aber die ganze Zeit über Backs und eine Sache nehmen wir immer an, das Backs einfach da sind. [SPEAKER_01]: Das Backs vielleicht auch wiederkommen, weil wir hatten auch das Wort Regression öfter schon mal genannt. [SPEAKER_01]: Wir sprechen auch ziemlich viel über Backmanagement für meine Backs an dem, was da benötigt wird und so weiter und so voll. [SPEAKER_01]: Wir haben aber noch gar nicht darüber gesprochen, wie man Backs eigentlich ordentlich fixt.

[SPEAKER_01]: denkst du, das ist ein Thema, das sollten wir mal kavan oder denkst du, was du logischer sind, so fair, fair, fair, fair, fair, fair, fair, fair, fair, fair, fair, fair, fair, fair, fair, fair, fair, fair, fair, fair, fair, fair, fair, fair, fair, fair, fair, fair, fair, fair, fair, fair, fair, fair, fair, fair, fair, fair, fair, fair, fair, fair, fair, fair, fair, fair, fair, fair, fair, fair, fair, fair, fair, fair, fair, fair, fair, fair, fair, fair, fair, fair, fair, fair, fair, fair, fair, fair, fair, fair, fair, fair, fair, fair, fair, fair, fair, fair, fair, fair, fair, fair, fair, fair, fair, fair, fair, fair, fair, fair, fair, fair, fair, fair, fair, fair, fair, fair,

[SPEAKER_01]: Naja, also das so ein Back reinbekommen hast und das ist eigentlich gar nicht ein High priority Back, das ist wirklich ein Nincident, wo ist der Unterschied? [SPEAKER_01]: Der Unterschied ist relativ einfach ein Back, also ich mir geben falls Zeit den zu fixen, fixen auch und ich bin im Incident, hol ich erst mal das Gaffer-Tab raus, löst das Problem erstmal und schon und später hab ich das richtig nachhaltig fixen.

[SPEAKER_01]: Also in Südent steht für dich von der Priorität noch mal über der höchsten Backprioritit. [SPEAKER_01]: In Südent heißt, ich lasse alles liegen, all hinsen und deck und kümmere mich darauf. [SPEAKER_01]: In Südent ist wenn ich vom Klogo holt werde und jetzt daran muss. [SPEAKER_01]: Und ein hohen Back es für auf gut, dann ist ein high priority back, aber dann fix mal jetzt und dann.

[SPEAKER_00]: muss denn bei dir die Kränze dann zwischen High-Priety-Buck und Incident, weil wenn du jetzt sagst, das ist ein Back der Betrifft, 5,40 Prozent meiner User, die können die Arbeit nicht mehr verrichten und dann hast du eine andere Back, wo 20 Prozent der User ihre Arbeit nicht mehr verrichten können. [SPEAKER_00]: Was ist jetzt ein Incident? [SPEAKER_00]: Ab wann ist ein Back ein Incident?

[SPEAKER_00]: Oder ist ab 7 Prozent der User-Bas, die die Arbeit nicht mehr verrichten können, Incident? [SPEAKER_01]: Nee, da... Ich glaube, dass dein Beispiel haben Floor, weil du erwarten sie jetzt einen direkten Schwellenwert von mir. [SPEAKER_01]: Das ist glaube ich nicht das Kriterium, wo man das unterscheidet. [SPEAKER_00]: Also wenn die Plattform 100% ausfällt, ist klar ein incident. [SPEAKER_00]: Aber der ganze Bereich der Zwischen, ab wann ist denn ein High-Prol-Dibakten incident?

[SPEAKER_01]: Ich habe falsche Rechnungen rausgeschickt, ist ein incident. [SPEAKER_01]: Ich weiß, dass meine Berechnungen um Rechnungen rauszuschicken, einen Floor einen Back hat, die nächste Rechnungsstrigger ist aber erst in 25 Tagen. [SPEAKER_01]: Das erste ist ein Intellient, das zweite ist ein High Priority Back, den ich innerhalb der nächsten 25 Tage fixen muss. [SPEAKER_00]: Ich kann auch ein Low Priority Back sein, wenn es von 20 Tage Zeit ist.

[SPEAKER_00]: Sie sind auf dem, wie ich arbeite. [SPEAKER_00]: Also bei der Subjektivität, bei mir wäre es ein High Priority Back. [SPEAKER_00]: Ja, ja, aber du siehst, es halt die Frage abwann ist, was ein Intellient. [SPEAKER_01]: Ja ja, klar, deswegen frage ich ja, hat es zu schon mal einen Inzielen. [SPEAKER_01]: Ich frage dich nicht, wie definiert es, oder sich habe frage dich, wo das schon mal bei dir so behandelt.

[SPEAKER_01]: Ich frage dich nach deinem Fahrung, Wolfgang und du weich schon wieder auf diese nun konsolten, weil du willst mal natürlich wieder mehr Beratungsschunden mehr verkaufen und dann haben wir sollten und das erste Mal wieder zurückzunehmen und was ist ein Inzielen, was ist eigentlich jetzt? [SPEAKER_01]: Es kommt aus einer Beratungsfugzüren aus einer Einfahrung. [SPEAKER_01]: Ich mein, du hast gerade von einem Backfix gesprochen, wo das Ziel Level Management involviert war.

[SPEAKER_00]: Das kann man jetzt mal ein Low-Priority-Back. [SPEAKER_00]: Ja, das ist wie der Wasser. [SPEAKER_01]: Das ist aber schon anders. [SPEAKER_01]: Aber das sind wir ja schon mehr. [SPEAKER_01]: Da bin ich schon mehr. [SPEAKER_01]: Weil es wenn das Ziel Level schon mit der drin hängt, dann würde ich versagen, Low-Priority weiß ich nicht, ob die Kategorie sind. [SPEAKER_00]: Wenn du richtig gesagt hast, war eine politische Sache.

[SPEAKER_00]: Aber ich würde mal sagen, dass ganz viele Box dann irgendwann zu einem incident werden, weil ganz oft wird dir was reportet, dass irgendein spezielle Funktion nicht geht. [SPEAKER_00]: Und für den User ist es halt nur für den User gerade ein Teil. [SPEAKER_00]: Und wenn man dann aber mag, du kenne es betrifft aber vielleicht alle User und dann gewissen Prozentsatz meiner User oder 90% meiner User können jetzt einen gewissen Schritt nicht mehr machen.

[SPEAKER_00]: Dann ist es wahrscheinlich in den incident automatisch. [SPEAKER_01]: Ich hatte halt schon etliche Wachs, die kam als Kastuma Support Ticket rein, man hat sich auch drum bekümmert, hat eine Geneerein gearbeitet und als dann mal klar wurde, was für ein Impakt dieser Fehler hat. [SPEAKER_01]: Also man hat dann eine Impakt-Analyse gemacht, dann hat man vielleicht meine Datenwahl geführt gemacht. [SPEAKER_01]: Wie viel Kunden haben dieses Setting denn eingeschaltet?

[SPEAKER_01]: Oh, dann merkt man, oh, das sind ja 90% aller User, die dieses Feature nutzen. [SPEAKER_01]: Und dann hat man nach drei Tagen und nach vier Tagen in den Inzidenen gelorgen, weil man ein besseres Verständnis von diesem Packard. [SPEAKER_01]: Ja. [SPEAKER_01]: Okay, deshalb bin ich noch nie erlebt. [SPEAKER_01]: Das ist so lange gedauert hat.

[SPEAKER_01]: Auch das kommt, das öfter und vor besonders meist Software-Assasservice-Kompanis, wo du halt, weil du halt erst ein besseres Verständnis von den Back haben musst. [SPEAKER_01]: Aber wer entscheidet dann, ob es ein incident ist in der Regel das Software-Engineer.

[SPEAKER_01]: Weil das Software-Engineer macht ja die Analyse, der kümmert sich ja um den Back, der kümmert sich darum und der deckt irgendwann oh, das Problem ist viel größer, ich sprech mal mit meinem Manager, ich sprech mal mit meiner Produkt Manager oder ähnliches, aber was hat es denn für ihn? [SPEAKER_00]: Oder für Sie, für Folgen, also warum muss sich sich in sich daraus lösen? [SPEAKER_00]: Ist das, wenn ich zusätzliche Hilfe brauche?

[SPEAKER_00]: Support, weil ist ja jetzt egal, ob wir gerade einen High-Prol-Di-Back fixe oder es offizieren in sich dorthin und die auch nur alleine daran weiterarbeiten. [SPEAKER_00]: Also geht es um Ressusen, dass sie mehrere Leute drauf setzen darf oder kann. [SPEAKER_00]: Also warum muss ich überhaupt auf dem Inzident wechseln? [SPEAKER_01]: Okay, erste Annahme, wenn nun insiedend lohnt, aber das du nicht mehr alleine lohnt.

[SPEAKER_01]: Wenn ein insiedend von einer Person bearbeitet wird, dann ist das kein insiedend. [SPEAKER_01]: Weil dann ist das nicht so wichtig. [SPEAKER_01]: Das bedeutet, wenn ein insiedend in der Sache hat genau das zur Folge, was du auch gesagt hast, ich hole mehr Leute an Deck. [SPEAKER_01]: Ich hole... [SPEAKER_01]: auf einmal, den Kastemaw Support und Deck der vielleicht aktive Kommunikationen alle betroffenen Kunden macht.

[SPEAKER_01]: Ich hohe Management und Deck, die vielleicht jetzt gerade nandieren, abschließend wollen, bezügliches Features und so weiter und so fort. [SPEAKER_00]: Aber ihr habt da keine Definition abweichen Impact, so etwas passiert. [SPEAKER_00]: Das ist dann schon noch in Nens jetzt mal Bauchgefühl Erfahrung. [SPEAKER_00]: Also ihr habt da jetzt keine Metrikte für in dem Sinne, oder?

[SPEAKER_01]: Ja, das geht halt nicht, weil es ist ähnlich wie ein Projekt jeder Inzident ist, ja im besten Falle Juniq. [SPEAKER_01]: Und wenn du ein Inzident hast, hast du Prövent-Ticket, die den Inzident dann verhindern soll, und so meträt dieser natürlich nicht mehr auf, weil du natürlich ein ordentlicher Engenier besonderes Pröventziges hat, du dich machst. [SPEAKER_01]: Und deswegen ist jeder incidention Nico und deswegen sind generell eine Kriterien natürlich unglaublich schwierig.

[SPEAKER_01]: Aber sich dir aber sagen möchte ist, dass die Arbeitsweise dann zu fixen das Backsich ändert. [SPEAKER_01]: Beim incident machst du eher gaffertab dran, dass du den Back irgendwie eindäms und kümmert sich dann später um eine nachhaltige Lösung. [SPEAKER_01]: Wo hingegen bei einem Hyper-Earer, die Back du prie mir an der nachhaltigen Lösungarbeit ist, da die natürlich schon zeitkritisch ist wegen der Hyper-Earer, aber du drehst in der Regel nicht mehr der Interaktion.

[SPEAKER_01]: Das Problem ist jetzt, oder die mögliche Herausforderung, das ist abhängig von der größte der Organisation und einer Inzidenkultur, dass den Prozess nicht gerade beschrieben hat, kann natürlich dazu führen, dass aber zu Inzidenklaunch werden, die dann später gar kein Inzidenz sind, weil die Einschützung des Resentwicklers oder der Entwicklerinnen oder von wem auch immer falsch war.

[SPEAKER_01]: Es kann natürlich auch dazu führen, dass man eine Inzidenfantik hat, dass zu viele Inzidenz zu früh gelohnt werden.

[SPEAKER_01]: Und dass dann niemand mehr Inzidenz ernst nimmt, das ist so wie auch ja uns das hier ISIS-Tem, das ist schon seit zwei Wochen rot, das ist immer so, ja das hast du bestimmt auch schon mal im Leben ständig, ja das kann natürlich auch auf Inzidenzidenzidenzidenzidenzidenzidenzidenzidenzidenzidenzidenzidenzidenzidenzidenzidenzidenzidenzidenzidenzidenzidenzidenzidenzidenzidenzidenzidenzidenzidenzidenzidenzidenzidenzidenzidenzidenzidenzidenzidenzidenzidenzidenzidenzidenzidenzidenzidenzidenzidenzidenzidenzidenzidenzidenzidenzidenzidenzidenzidenzidenzidenzidenzidenzidenzidenzidenzidenzidenzidenzidenzidenzidenzidenzidenzidenzidenzidenziden

[SPEAKER_00]: Okay, also jetzt als möchte gern Feuerwehrmann an die du siehst der überall nur, dass es Brent und du siehst sogar in den einfachen Box irgendwo insiedens, komm mal zurück jetzt zu dem Box, wie löst du Box hast du da auch ein Modell an der Hand, wie kann man Box besser lösen oder besser bearbeiten? [SPEAKER_01]: Ja, ja, habe ich. [SPEAKER_01]: Und zwar lustigerweise auch, also mehrere Ideen, schwerem mit einem Kopfgruppen.

[SPEAKER_01]: Auf der einen Seite natürlich auch wieder eine sehr nahen Inzidenz und zwar Rudkors an der Nähen. [SPEAKER_01]: Ja, ich bekomme den nicht mehr weg von diesem Feuer. [SPEAKER_01]: Ja, ja, der Punkt ist eigentlich, du musst ja halt mal fragen, woher kommen diese Bags eigentlich? [SPEAKER_01]: Und ab und zu ist es ja so, dass du Bugsgruppieren kannst. [SPEAKER_01]: Oder bzw. [SPEAKER_01]: eine Gruppierung von Bugskanda bei Helfen.

[SPEAKER_01]: So sagen, okay, ist das vielleicht eine globale Klasse-Anbox? [SPEAKER_01]: Ebenlich wie beim Juni testen, aber Juni testen hast du ja auch verschiedene Testpettern, wie zum Beispiel Rand-Tests, ja, dass du werte Bereiche immer an den Rändern-Tests ist, weil da ist oft meist und oft bei Wann-Erroh, so ähnlich hast du das natürlich dann auch bei Gruppierungen von Box.

[SPEAKER_01]: Jetzt kommt es, aber wir hatten gerade um diese Zero-Backpolisie gesprochen, die natürlich in der Theorie sich super schöner gehört.

[SPEAKER_01]: Das Problem ist aber immer, wenn du einen Back reinbekommenst und den sofort fixst, wie kannst du eine Gruppierung eine Klasse-Fizierung machen? [SPEAKER_01]: Die kannst du natürlich nur Retrospektiv machen. [SPEAKER_01]: Das bedeutet, dass wir so einen negativer Punkt, warum eine Zero-Backpolisie auch nachteile haben, kann, weil die die Sichtbarkeit auf die Rudkors verhindern kann.

[SPEAKER_01]: Wenn du jetzt aber dein Verhass wo dein Backback lock einfach super groß ist, dann kannst du ja durch die Bugs gehen und du kannst dann immer wieder labels oder kategorien dran packen, dass du sie so grobieren kannst und dann kannst du natürlich viel einfacher die Sichtbarkeit auf eine Gruppe von Bugs erstellen und dann natürlich eine komplette Gruppe von Bugs in dem du einfach zwei Schritte zurückgeht, so ein Chance, was ist denn wirklich das Problem?

[SPEAKER_01]: Ein deiner Submaschine könnte man fragen, ist die Klassifizierung der Daten ist das Extracting oder die Semantik der Daten oder Stemmeng vielleicht viel auf. [SPEAKER_01]: Oder oder oder oder. [SPEAKER_00]: Also das kann man schon machen. [SPEAKER_00]: Also deshalb er eigentlich auch mit der Lebtes.

[SPEAKER_00]: Das natürlich dann auch sehr hilfreich ist, wenn das Team gemeinsam drauf blickt und nicht nur irgendwie im product owner, weil die Teams dann natürlich auch Gemeinsamkeiten sehen. [SPEAKER_00]: Also wenn du Entwicklerin bist von irgendeinem System unter Systembar Backstern weißt, okay, die sind zusammenhängend, die haben vielleicht sogar einen ähnlichen Gutkost, dann kannst du die zusammenfassen und sagen, hey, den nennen wir gleich mit den Back.

[SPEAKER_00]: Oder wir schauen das mal dem Detail an, weil das klingt so, als wenn diese fünf Backs [SPEAKER_00]: Verbunden mit denselben Routcars oder vielleicht mit einem neuen Kutblock oder mit einer neuen Library-Divierger der eingeführt haben und da ist dann natürlich auch wichtig, dass das Team mit eingebunden ist, weil da hat man dann einfach dieses Zusatzwissen was man wahrscheinlich auf einer höheren Ebene auf der Product Ebene vermutlich nicht haben kann.

[SPEAKER_00]: Und was da auch noch ganz wichtig ist, dass die Entwickler in der das wollen und des Produktverständnis haben, dass die nicht nur auf einem Backsprängen und sagen, die löse diesen einen Back, sondern dass die eben sehr wohl im Blickfeld haben, da gibt es mehrere Backs und das breitere Bild natürlich auch im Kopf haben und sich auch darum kümmern und nicht nur in ihrem Tunnel sind, um einen Back zu lösen, sondern den gesamten Routeskoss.

[SPEAKER_01]: Und wenn wir jetzt mal eine Rudkorsanalyse machen von Bugs generell, dann ist es natürlich klar, worum wir Bugs beheben. [SPEAKER_01]: Aber was wäre noch besser, wenn diese gar nicht auftreten. [SPEAKER_01]: Wenn wir diese von vorne herreien, vorhin. [SPEAKER_00]: Wir schaffen die Entwickler in den Ab, dann haben wir auch keine Bugs mehr.

[SPEAKER_00]: Sehr gut, Edel. [SPEAKER_01]: Eher, ich glaube, die Sao wird seit zwei Jahren durchs Dorf geschrieben mit AI und KI und Generative AI und Co. [SPEAKER_00]: Und sie hat ja die machen ja auch Bugs am besten. [SPEAKER_00]: Man kodet nicht, dann hat man auch keine Bugs. [SPEAKER_00]: Ich probiere das auch immer. [SPEAKER_00]: Was kommt diese vor, denn in den Sinn, wenn es darum geht, Bugs von vorne rein zu verändern.

[SPEAKER_00]: Ja, ob man sie verhindern kann, bin ich mir nicht ganz sicher, da gehen wir jetzt schon in Klinen, Kodigen und solche Dinge hinein. [SPEAKER_00]: Aber was man durch schon machen kann, ist sie sehr früh zu erkennen. [SPEAKER_00]: Also, dass sie gar nie in Produktion gehen. [SPEAKER_01]: Da bin ich andere Meinung. [SPEAKER_01]: Weil das was du ja sagst, ich teste die ganze Sache durch.

[SPEAKER_01]: Vielleicht durchs Manuelles Testing, Explore-Tivistesting oder automatisiertes Testing. [SPEAKER_01]: oder automatisiertes Testing. [SPEAKER_01]: Ich meine, das sollte man tun, aber die Frage ist ja dann auch wann habe ich genug getestet. [SPEAKER_01]: Also da wieder die bei Langs muss ich das, muss es nur 100% die gekoat coverage sein. [SPEAKER_01]: In Medifekt verzüger ich er den Wert des Features.

[SPEAKER_01]: Also ich verzüger er bis der bis das Feature Wert beim Kunden liefert. [SPEAKER_01]: Natürlich kannst du Juni und den Degrationen entweder enttessigen macht und vielleicht, wenn du irgendwie insohsegmenten wie Black Friday und Cyber Monday bist und du hast in IKOMOS schoppt dann sollte da vielleicht auch performen zu los der Load Testing dabei sein und aber muss es Test-Drift und Development sein zu borscht. [SPEAKER_01]: Ja? [SPEAKER_00]: Ja, muss es gar nicht.

[SPEAKER_00]: Aber Testing ist sicher kein Fehler und die habe ja auch, wie du am Anfang schon erwähnt hast zum Beispiel Code Reviews. [SPEAKER_00]: Das ist zwar höchstwahrscheinlich hoffentlich zumindest nach deinen automatischen Tests, die du geschrieben hast, aber da hast du ja auch noch mal eine Möglichkeit, Backs zu finden, bevor sie wirklich produktiv gehen. [SPEAKER_01]: Also ich glaube und ich bin auch fest davon überzeugt, dass du testes haben solltest, was ich aber wertvoller finde.

[SPEAKER_01]: Als jetzt die Regel zu schaffen, mein Code muss 80% coverage zu haben, weil ich hab auch schon mal das Einwander Team gesehen. [SPEAKER_01]: Das ist sowieso bullshit, aber darüber haben wir ja schon öfters in test Episodeen darüber gesprochen. [SPEAKER_01]: Hab ich aber immer wieder gesehen, was ich viel wichtiger finde ist, wenn du ein Back hast, dass du erst den Test schreibst, dieser Test dann viel schlägt und dann den Back fixst.

[SPEAKER_01]: Und das sogar, wenn du das vielleicht nicht machst, sondern wenn ein Back wieder kommt, ne manja Regression, dass du dann für die Regression einen Test schreibst. [SPEAKER_01]: Es sind wir da beim Backs verhindern und du kommst wieder wie man Backs richtig fixt.

[SPEAKER_01]: Ja, also ich meine, ich meine, das ist der erste Teil und der zweite Teil ist natürlich dann, dass du die ganzen Backs auch bei jedem, die ganzen Backs, die ganzen Test bei den ganzen Pull-Request und bei jedem die Playlaufen ist. [SPEAKER_01]: Ja, also Kontinus, Integration, Kontinus, Deployment, Kontinus, Delivery und so weiter. [SPEAKER_01]: Denn nur du sagst ja auch, wenn du verhinders das ein Großteil der Backs-Improduktion gehen, dann sind die nicht mehr so kritisch.

[SPEAKER_01]: Die Problematik ist bei diesen Tests immer. [SPEAKER_01]: Je nachdem, was das für Test sind, können die enorm pläkig sein, die, wenn du sehr viele Tests das kann, die Runtime, die Tests sehr hoch sein, wenn du ein komplexes Set-Up hast zum Beispiel Integrationstest mit Datenbanken, Integrationstest mit fremder Infrastruktur, Nevermarklaub, Provider oder ihnen nicht ist. [SPEAKER_01]: Stell dir mal vor, du baußt ein Terraform-Proweider, um Infrastruktur zu steuern.

[SPEAKER_01]: Diesen als Integrations-Zests zu laufen, zu lassen, bedeutet, du fährst Cloud Infrastruktur und muss sie danach wieder zerstören. [SPEAKER_01]: Jetzt denkst du dir, ja, kannst du ja machen, ist da kein Problem. [SPEAKER_01]: Das Problem ist aber, wenn du mit einem Cloud-Proweider arbeitet hast du auf Great Limits da drin und so weiter, dann kannst du nicht so viele Tests auf einmal hochfahren.

[SPEAKER_01]: Die Test-Runtime, bis die Cloud-Node, mal hochgefahren, ist dauert fünf Minuten, et cetera, et cetera. [SPEAKER_01]: Auch die Zeit, die Test-U zu fliegen oder sogar größere Refact-Rings an Deiner Code-Bes zu machen, die dann vielleicht sogar die Exzene API an Fasten oder du hast sehr viele Internet der API getestet. [SPEAKER_01]: Dann kannst du die ganze Test-Fast-Une wegschmeißen.

[SPEAKER_01]: Also es gibt halt auch enorme Down-Zeits abhängig von dem Bass-U-Tests, sondern wie komplex eine Test-Sin. [SPEAKER_01]: Natürlich muss man auch zugeben, dass du mehr Test-U-Hass um so größer ist, dann sicherungsnet. [SPEAKER_00]: Ich sehe da aber auch jetzt gerade aktuell so den Fluch der AI, weil du da ja immer ganz viele Dests mitbekommenst.

[SPEAKER_00]: Die beste Geschichte, die gerade kürzlich erlebt habe, ihr habt so einen Fitscher entwickeln lassen von der AI alles schön gemacht, mehrere Interationen und so weiter hat mir Tests erstellt, hat dann die Tests natürlich auch ausgeführt, bei mir auf der Command-Line alles grünen, alles perfekt, Fitscher ist fertig.

[SPEAKER_00]: G auch in die Destin ein, dann waren da ungefähr 30, 40 Dests, aber jeder Dest war mit Du Du vor Sinn, das heißt da war kein Kotrin, das war alles grüne Dests, aber jeder Dest hat einfach immer grün zurückgegeben, das ist die eine Seite, das sollte man natürlich im Auk haben, aber die andere Seite, was viel schwieriger zu handeln ist, meiner Meinung nach ist, dass mit jeder kleinen Änderung die Eil gerne ganz viele Dests,

[SPEAKER_00]: macht und deine Testwitz so groß wird und so unübersichtlich und du wahrscheinlich auch so eine Vertieg entwickelt, jeden Dests durchzuschäcken, ob der wirklich stimmt. [SPEAKER_00]: Dass du um Ende so viele Dests hast und so eine unübersichtliche Situation, dass sie dir danach mehr Schaden als sie dir helfen.

[SPEAKER_00]: Und da muss man glaube ich auch gut aufpassen, dass man nicht zu viele Tests hat und die richtigen Tests, die sinnvollen Tests, weil damit das nicht flakey wird, am Ende und ständig fehlschlägt. [SPEAKER_00]: Und darauf muss man wahrscheinlich dann beim Coach Review oder beim Reviewen von dem AI-Code oder von anderen Personen, die mit AI das ganze erstellt haben, schon auch einen Aut darauf werfen und da bin ich ganz bei dir zu viele Tests. [SPEAKER_00]: können auch schädelig sein.

[SPEAKER_01]: Das soll jetzt kein Aufruf sein, dass du gar keine Testverschreibung soll. [SPEAKER_01]: Also bitte, wenn du uns zuhörst, der Einruhander testes mach, glaube ich, ganz sinnvoll. [SPEAKER_00]: Und es gibt auch einfach Tests die Farsch sind. [SPEAKER_00]: Also AI wie beim Code auch gibt es auch Tests die einfach Farsch sind. [SPEAKER_00]: Die Lauffendar zwar grün durch, aber irgendwann endest du eine Kleinigkeit und dann sind die rot obwohl sie eigentlich grün sein sollten.

[SPEAKER_00]: Also da kommt teilweise auch Bullshit um die Ecke. [SPEAKER_00]: Muss man wirklich im Detail sich ansehen. [SPEAKER_00]: Jetzt bin ich natürlich ein riesen Fan von Testing-Production. [SPEAKER_01]: Und ich sage jetzt nicht, lasst die ganzen Testen sein. [SPEAKER_00]: Ich weiß, du wollte es dir schon die Tester an die Kunden auslagern, bzw. [SPEAKER_00]: deine Kunden zu testen machen. [SPEAKER_00]: Also es schlägt jetzt in die Silberkabe. [SPEAKER_00]: Wach noch weiter.

[SPEAKER_01]: So hast du pässt, ihr müsst die ganze Sache formuliertes richtig. [SPEAKER_01]: Aber was meine ich denn, wenn ich sage, Testing-Production? [SPEAKER_01]: Ich rede dann natürlich auf der einen Seite von Canary-Deployments auf der anderen Seite von Featureflakes. [SPEAKER_01]: Also was bedeutet das? [SPEAKER_01]: Du weißt nicht, ob deine Software-Bucks hat?

[SPEAKER_01]: die Hälfte des Server oder wie wir in der multimodanten Episode gehört haben für die Hälfte der Kunden oder für einen Viertel der Kunden. [SPEAKER_01]: Danach beobachtest du deine Business-Metrigen.

[SPEAKER_01]: Sind die alle gesund läuft das also du man nennt das in der Industrie sogteim, du du lässt [SPEAKER_01]: Die neue Version mal ein bisschen auf den Produktion Server beobacht ist, das guck's aber irgendwie Kunden-Tickets reinkommen, guck's um die Businessmetregen, sich positiv oder negativ verhalten, guck's um die Features genutzt werden.

[SPEAKER_01]: Das bedarf natürlich einer guten Observer-Wildetie, auch nicht nur auf technischen Metregen, sondern wirklich auf Businessmetregen, also werden Artikel noch gekauft, wird ein Service noch benutzen zu weiter. [SPEAKER_01]: Und wenn das alles positiv aussieht, dann rollzt du das Feature auf mehrere Kunden aus [SPEAKER_01]: nachdem du auf immer aufdolst.

[SPEAKER_01]: Und so kannst du natürlich auch sicher gehen, dass deine Software a wertliefert, dass du b sehr gutes Produktions Feedback schnell bekommst und c, dass du natürlich den Blastradius von dein Backstatt natürlich in Grenzen hältst. [SPEAKER_01]: Natürlich kommt immer auf die Norns an, auf die Details, wenn dein Schan schätzt ganz viele. [SPEAKER_01]: Datenbankänderungen hat dann witzert natürlich immer ein bisschen schwierig.

[SPEAKER_01]: ganz klar, was so beaufmachen, also Alternativen sind Feature Flags, das bedeutet, du schippst den neuen Code auf all deine Server und dann hat deines Attributs, weil sich nicht Browser, Land, Sprache oder ähnliches, sagst du nur Kunden aus Österreich bekommen dieses neue Feature. [SPEAKER_00]: Der große Vorteil an dem ist ja auch, dass man sich Zeit erkauft, weil ich kann dieses Ding einfach wieder abschalten.

[SPEAKER_00]: Ich bekomme den Back, der aktiviert ist, die Fitsche Fleck und habe dann Zeit zur Behebung von diesem Back ohne, dass meine Kunden sauer werden und frustriert sind. [SPEAKER_00]: Und da sehe eigentlich den größten Vorteil, dass es kann auch helfen, auf der Backbehebung Seite, dass sie einfach diese Möglichkeit haben in Fitsche Fleck abzuschalten. [SPEAKER_01]: Da geht es einer riesen Herausforderung. [SPEAKER_01]: Zwei ist das nämlich die Kombinatorik.

[SPEAKER_01]: Wenn du nämlich sehr viele Feature Flex hast, dann könnte es sein, dass Feature Flex 1, Feature Flex 2 beeinflusst. [SPEAKER_01]: Und dann eine neue Art oder eine neue Klasse von Backsträger, die du so nicht auf dem Schirm hat, um so mehr Feature Flex zu hast, desto großartig die Kombinatorik. [SPEAKER_01]: Und die zweite Dematik ist, das kann auch sehr hilfreich sein, in generelle Operations, dass du sehr viele Operationen hinter einem Feature Flex hast.

[SPEAKER_01]: dass du sagst, okay, wenn meine Plattform unterlast ist, dass du bestimmte Features deaktivierst, um dann die Schabilität der Plattform zu erhalten, sobald du teure Datenbankvielst oder so. [SPEAKER_01]: Mein kleines Beispiel, wenn du bei den Totenhosen, Konzertkarten kaufen möchtest du im Online-Shop, wenn die wir dann vorverkauf haben, dann deaktivieren die automatisch, die übersicht danner historischen Bestellungen, um einfach die Datenbanklast zu reduzieren.

[SPEAKER_00]: dass wir uns sehen, wie oft du die dorten Hosen oder Taylor Swift Ticket Story ausbuckst. [SPEAKER_00]: Ich glaube, wir hatten die im letzten Monaten schon fünfmal. [SPEAKER_00]: Aber sie eigentlich sich natürlich, dass sie immer sehr schön zu erklären. [SPEAKER_01]: Ja, jetzt haben wir aber die ganze Zeit über Bugs Management, Bugs Fixen, Bugsbehemen, Bugs von vorne ein Verhindern gesprochen.

[SPEAKER_01]: Jetzt muss ich dir, als da ein getriebener Mensch, hat sich die Frage stellen. [SPEAKER_01]: Hat sich diese Episode jetzt eigentlich gelohnt? [SPEAKER_01]: Also wie schauen wir denn, ob sich der ganze Aufwand, dem wir hier in den letzten zwei Stunden besprochen haben, ob der überhaupt irgendein positiven Impact auf mich, mein Team, meine Firma, mein Produkt hat.

[SPEAKER_00]: Man merkt, dass du ein guter Manager bist, du probierst jetzt, dass was du gerne hätte, ist nämlich Metriken und Visibilität auf dein Team, auf mich, um zu leiten, als Team member, um eigentlich deinen Team members mehr Visibilität zu geben, was sie für tolle Arbeit geleistet haben, obwohl du eigentlich nur überwachen bist. [SPEAKER_01]: Immer wenn du das Wort über Wachung in den Mund nimmst, wo sich sagen, also wir hatten ja man österreicher von euch.

[SPEAKER_00]: Also, ich weiß, okay, dann probiert es zu drehen, was du ja überwachen willst, ist eigentlich die Kultur und die Qualitätskultur in deiner Firma und da eignen sich natürlich matriken, um das auf einem höheren Level auch sicht darauf zu haben.

[SPEAKER_01]: Was, was, was ich eigentlich mache möchte, ist ich möchte die generelle Frage beantworten, befindet sich unser Team, wir sind jetzt bei der Andi Wolfgang Corporation, ich weiß ja schon vergelassen. [SPEAKER_01]: Ja, ja, top team, top team, best team ever. [SPEAKER_01]: Okay. [SPEAKER_01]: Befinden wir uns auf dem richtigen Weg. [SPEAKER_01]: Das ist die Frage, verbessern wir uns. [SPEAKER_01]: Das ist die Frage, die wir uns beantworten.

[SPEAKER_01]: Und ich denke auch, dass du Motivationen schöpft, wenn du weißt, dass den Aufwand, den du betreipst, ein positiven Impactas. [SPEAKER_01]: Also. [SPEAKER_01]: Was messen wir? [SPEAKER_01]: Was messen wir? [SPEAKER_01]: Das ist die Frage. [SPEAKER_00]: Was würdest du messen? [SPEAKER_00]: Ich sprene zurück auf ganz den Anfang, was ihr wähnt habt. [SPEAKER_00]: Und zwar hab ich da wähnt, dass es schlecht ist, der ist, wenn der Kunde den Back entdeckt.

[SPEAKER_00]: Und genauso wurde ich auf meine Metrickin zum Beispiel aufbauen. [SPEAKER_00]: Also wo wird ein Back entdeckt? [SPEAKER_00]: Auf der Kundenseite weiter der Vor. [SPEAKER_00]: Das wäre mal eine Metrick, die checken würde. [SPEAKER_00]: Das heißt, wie viel Backsschippen wir nach außen. [SPEAKER_00]: die Box beim Kunden ankommend.

[SPEAKER_00]: Das wäre für mich eine wichtige Metrik, weil davon ausgehen muss, wenn ein Kunde im Back entdeckt, ist es eher schlecht, als wir wenn ihr den früher entdeckt in meiner Pipeline. [SPEAKER_01]: Ich finde die Metrik eigentlich ziemlich smart, woher kommt der Back und wie viel Prozent der Box wurden von Kunden entdeckt?

[SPEAKER_01]: Das finde ich super smart, denn diese Metrik, oder wenn du auch mehrere Städte hast, okay, beim Unit Test, MPR, beim Code Review, das zeigt auch wirklich die Wirksamkeit, [SPEAKER_00]: Und sonst würde ich eigentlich sagen, ist das immer eine relativphymetrik. [SPEAKER_00]: Also, würde ich nicht sagen, irgendwie die Anzahl der Box ist entscheidend, ist mehr so ein Rolling average.

[SPEAKER_00]: Hab ich dann eine Verbesserung, hab ich weniger Box über die Zeit mehr Box, dass sie einfach so eine Kontrolle im Groben haben, wobei man dann durch auch immer aufpassen muss, was das wirklich bedeutet.

[SPEAKER_00]: kann sich auch in das Toktur, was verändert haben, dass man Box klein Deiliger erfasst oder das sind automatisch im Pipeline automatisch, erstellt werden, die man früher eher man schneller stellt, dann wird das natürlich auch automatisch anwachsen, also das muss man durch immer im Kontext 10 aber grundsätzlich um so eine grobe Métrik zu haben geht, was noch oben geht, was noch unten ist sicher hilfreichend.

[SPEAKER_01]: Also ich denke schon, weil das ist einfach schon ein bisschen fast im Tool drin, dass man halt die offenden und die geschlossenen Backstracken sollte. [SPEAKER_01]: Was ich aber auch interessante finde, wie viel Backs wurden geschlossenen ohne einen Pull-Request? [SPEAKER_01]: Weil das was zeigt ihr die Semitrik? [SPEAKER_01]: Na ja, oft Indicate, often in die Kanto von dieser Back war ein volles Positive, also ein ein falscher Back report.

[SPEAKER_01]: Oder... [SPEAKER_01]: Wie jemand hat die Intention des Features nicht verstanden oder falsch wahrgenommen? [SPEAKER_00]: Ich weiß nicht, was ich mir werde, ist auch eher eine Eux-Volgerung. [SPEAKER_01]: Das eigentlich die Eux schlecht ist. [SPEAKER_01]: Ja, aber es gibt ja ein Signal. [SPEAKER_01]: Es gibt ja ein Signal, es kommt ein Backrhein, da hat sich einen Software-Entwicklerinnen oder Software-Entwickler mit Beschäftig und deshalb hat kein Code-Chains stattgefunden.

[SPEAKER_01]: Man müsse nicht natürlich dann gucken, was sagt. [SPEAKER_01]: Aber ich finde, das eine interessante thematik-Nanautomatik, die ich sehr interessant finde ist. [SPEAKER_01]: Wenn du dieses Vorgehen verfolgst, dass du jedem Back eine Art Deadline gibst, was wir besprochen hatten, wie oft reißt du diese Deadline? [SPEAKER_01]: Also wie viel Bags werden nicht in der zugewiesene Deadline behoben? [SPEAKER_01]: Natürlich ist das jetzt kein Korkritärium, aber es lag dir aus.

[SPEAKER_01]: Wie ernst zu diese Dettler nimmst oder wie oft du Crunch Times hast oder wie oft du dein eigenes Regelwerk, was du für dein Team und deine Struktur gesetzt hast, selbst bricht. [SPEAKER_01]: Und das kann natürlich dann zu guten Prozess optimierungen man später führen. [SPEAKER_01]: Wenn du das sagst, okay, 90 Prozent meiner Backsee, wo ich eine Dettlein zuweise, die Breche ich und kann ich nicht halten, da sieht die Dettleins vielleicht so knapp.

[SPEAKER_01]: Oder du bist aber auf den Crunch Times oder du sagst, ah, immer alles ist wichtig. [SPEAKER_01]: Also, da kann man nur noch sehr viel simplifizieren oder verbessern. [SPEAKER_00]: Wie immer Matrixen sehen ein Datenpunkt, man muss sich dann das sowieso immer im Kontext ansehen, weil nur weil irgendein Rathen nach oben geht, heißt es noch lange nicht, dass das Team schlecht funktioniert.

[SPEAKER_00]: Kann ja auch damit zu tun haben, dass das Team eine neue Technologie einsetzt, wo sie das Neulet schnicht hat. [SPEAKER_00]: Also, es ist ein Datenpunkt und da muss man einfach in die Defekin, um zu analysieren, wo man liegt, das Ganze.

[SPEAKER_01]: Ich denke, wie du die Mehlfrägen interpretierst, hat auch sehr viel mit der Kultur zu tun, die Kultur, weil die ganzen Backprozessing, die wir das besprochen haben, ist auch sehr wichtig, weil oft es ist natürlich so man investiert, irgendwie zwei Wochen um den Back zu fixen und der Outcome, der Output ist vielleicht nicht so immer gedacht hatte, oder man schafft es nicht den Back zu fixen oder oder oder oder.

[SPEAKER_01]: dass man vielleicht nicht immer nur das Backfixen selbst anerkennt, sondern auch den Aufwand, den jemand da reingesteckt hat. [SPEAKER_01]: Und das Qualitätsemproofments und Backfixing halt auch Arbeit ist, die auf dem Liederschipplevel anerkannt wird.

[SPEAKER_01]: Also diese ganze Tematik hier, ich bin mir nicht sicher, ob man die allein im Team vorantreiben kann, weil dann echt man nämlich sehr oft an, also Engineering Manager, Project Manager, echt dann sehr viel mit den Partnerteams an oder Teams, die irgendwie aus von Nebrauchen. [SPEAKER_01]: Ja, wir haben keine Zeitverwachsfixen müssen. [SPEAKER_01]: Ich denke, das muss schon dieses Mindset von dem wir hier sprechen. [SPEAKER_01]: Schon im Leadership irgendwie verankert sein.

[SPEAKER_01]: Das muss schon ein gutes Verständnis dafür da sein, warum ihr das macht. [SPEAKER_01]: Und das ist auch an der Kennung. [SPEAKER_01]: Und das man ... [SPEAKER_01]: Vielleicht sogar gar keine Erlaub in das Brauch nur ein Back zu fixen, sondern dass man einfach das richtige tut.

[SPEAKER_01]: Das bedarf natürlich auch sehr erwachsenen und sehr sinjurigen Teammitgliedern, die dann auch wieder Wolfgang auch schon mal sagte, ein gutes Businessverständnis haben, damit die bei langs auch gegeben ist.

[SPEAKER_01]: Nur weil ein Back ist und man hat so ein kleineres Monk vorhält, ich bin auch so einer, ich fokussieren mich sehr viel auf Backstab mit dir Backfree sind, ja, aber ich weiß ganz genau okay, dieser eine Back, der bringt uns jetzt hier nicht weiter, also da muss man schon ein bisschen differenzieren.

[SPEAKER_00]: Ganz allgemeinen vielleicht noch Metricken sind sowieso immer nur in der richtigen Kultur sinnvoll, weil sonst wird einfach passieren, dass alle probieren, diese Metricken irgendwie auszutricksen und dann werden halt backs nicht mehr so erfasst, wie sie erfasst werden sollen und dann wird halt probiert einfach drumherum zu arbeiten. [SPEAKER_00]: Also es muss irgendwie immer ein positiven Impact haben, wenn solche Metric hin zum Beispiel fallen.

[SPEAKER_00]: Also es darf nie irgendwie ein Blaming-Kultur angewandt werden. [SPEAKER_00]: Was sonst wird, ist nie funktionieren. [SPEAKER_00]: Zeiß, jetzt auf Team Ebene oder von einer höheren Ebene, noch schlimme, es werden wir dann Teams vergleicht und sagt, hey, die lösen die Box, aber um zwei Tage schneller als das andere Team, [SPEAKER_00]: Das ist dann so richtig toxisch, wenn man sowas anwendet.

[SPEAKER_00]: Also da immer möglichst in der Sinnvollen Kultur, mit einem Fingerspitzengefühl und immer mit einer root-Course-analysis an solche Metriken dran gehen oder an den Folgerungen, die mal aus diesen Metriken zieht. [SPEAKER_00]: Ganz wichtig, meine Meinung nach. [SPEAKER_01]: Eine Philosophische Folge und ich glaube, ich kann das Wort Back jetzt nicht mehr sehen oder aus sprechen.

[SPEAKER_01]: Kette das, wenn man nur ein Wort 35.000 mal ausspricht und da gar nicht mehr weiß, wie du es wirklich richtig ausspricht oder was es bedeutet, das Gefühl hatte ich hier. [SPEAKER_01]: Treibugstab und du weißt schon, wie ihr da nicht mehr wem als ihr ausspricht. [SPEAKER_01]: Aber [SPEAKER_01]: Ich glaube, wenn es ein paar Takeways für diese Episode gibt, dann ist es auf der einen Seite. [SPEAKER_01]: Es gibt nicht den Einprozess, der überall funktioniert.

[SPEAKER_01]: Exfonantiere einfach mal ein bisschen mit den verschiedenen Wegen, verschiedenen Modellen. [SPEAKER_01]: Wie zum Beispiel auch macht das Sinn alte Back zu fixen oder solltest du die aktuellsten Problemen beheben? [SPEAKER_01]: Ja, also spielen wir mal ein bisschen rumgeschriff mit einem Team darüber.

[SPEAKER_01]: Und dass ihr kleine Experimente fahrt und ich glaube, was man immer festhalten kann, je älter, der Back ist, es so länger dauert, es diesen zu fixen, weil einfach der Kontext fehlt und natürlich bei die Software sich weiterentwickelt. [SPEAKER_00]: Aus zum Beispiel, die dann einfach klar ist, ist wieder schnell. [SPEAKER_00]: Umso länger er offen ist, umso schneller ist er dann geschlossen, wenn man nichts macht.

[SPEAKER_01]: Was wichtig ist, kommt wieder oder man hätte doch Back insolvenz aber noch gut. [SPEAKER_01]: Aber Wolfgang, um dich jetzt noch mal am Ende zum Lachen zu bringen. [SPEAKER_01]: Ich hab nochmal ein Witz für dich. [SPEAKER_01]: Bist du bereit? [SPEAKER_01]: Also, die Wahrscheinlichkeit, dass sie lach über deine Witz ist, eigentlich sehr niedriger, aber versuchst wieder mal. [SPEAKER_01]: Die Hörin und Hörer sehen, dass er nicht, aber du fängst sehr oft anzugränden.

[SPEAKER_01]: Obwohl du es nicht zugeben möchtest, so man merkt, du wärst dich dagegen. [SPEAKER_01]: Die Bagging ist wie direktivarbeit, bei der du selbst der Mörder bist und ich nicht mehr eine in Ost war rum. [SPEAKER_01]: Gute so kein Witz ist noch wie ein Witz, aber ich steh mit ihr zu, ja. [SPEAKER_01]: Gut, man könnte auch sagen, der Tester sagt, ich hab 100 Box gefunden, der Entwickler sagt, cool! [SPEAKER_01]: Ich hab 120 Box behoben, der Tester, warum hab ich jetzt 24 Box?

[SPEAKER_00]: Das ist auch der Grund, warum entwickler in ein weniger True Crime-Hournen, weil die einfach dagdäglich selber mit viel True Crime zu tun haben. [SPEAKER_01]: Wahrscheinlich. [SPEAKER_01]: Fehler Fehler Fehler macht euch nicht nie da, damit ihr so viel Fehler habt, das ist ganz normal. [SPEAKER_01]: Das nächste Feature kommt bestimmt bei dem Übersprassert. [SPEAKER_01]: Wir verabschieden uns bis bald, bye-bye.