Ja, habt ihr. Irgendwie gibt es irgendwelche Anforderungen daran, was ich berücksichtigen soll? Na ja, das was es können soll, aber so richtige Anforderungen haben wir noch nicht und dann kommt das, was immer sehr gefährlich ist. Die werden aber noch kommen, ja. Coating Bodys dein Podcast rund um Softwareentwicklung und aktueller Technews herzlich willkommen.
Halli Hallo und herzlich Willkommen zur neuen Folge vom Coding Buddies Podcast. Schön, dass du wieder eingeschaltet hast und schön, dass wir alle wieder hier zusammen sind. Ich natürlich der Fabi und auch der fantastische Tino Tino sei gegrüßt. Hallo. Na na, wie geht's? Wie steht's? Geht ab. Ich habe schon auf was geht ab gewartet, aber hallöchen. Ja, ich hab gute. Laune heute ist ein schöner Tag,
das ist gut, das freut mich. So ist es richtig gute Laune beim Podcast. Das erhält die Stimmung für alle hier. Mal gucken, wie lange die Laune anhält. Genau direkt im Keller. Tschüss war's gut ne Pass auf, lass uns mal das Thema starten und zwar möchte ich das Thema noch nicht ganz verraten, ich möchte am Anfang erstmal ein kleines Gedankenexperiment machen. Was heißt Gedankenexperiment? Ich weiß nicht, ob man das so nennen, aber.
Ich möchte jetzt auch, dass du, liebe Zuhörer, lieber Zuhörer, auch mitmachst und du natürlich auch Dino. Und zwar geht es einfach nur mal ganz kurz darum, um sich vorzustellen, wenn ich einfach nur sage. Stellt euch bitte vor. Oder was würdet ihr sagen? Was ist ein großes Haus? Jetzt kann man einmal ganz kurz drüber nachdenken und jetzt sag du doch mal, Tino, was ist für dich ein großes Haus? Ein großes Haus, ja. Mhm. Tja, das ist eine gute Frage.
Also großes Haus hat auf jeden Fall mehrere Etagen, OK. Wohnfläche würde ich sagen. Die Frage ist halt was für n, was für n Haushalt ne, also entweder viel Wohnfläche oder viele Wohneinheiten, also irgendwas ja was halt groß treffen würde. Also ich würd jetzt einfach sagen mehrere Etagen wäre jetzt so das erste. Und jetzt kann, ja kannst du Liebe zuhören, lieber Zürcher, ja mal abgleichen, wie es zum Beispiel was Tino gesagt hat, ob das sozusagen deine Gedanken trifft oder nicht.
Ich hätte zum Beispiel auch gesagt, so was wie es muss, weiß ich nicht, keine. Ahnung. Für mich ist ein großes Haus vielleicht sowas wie es hat 7 Zimmer, 2 Etagen und muss mindestens weiß ich nicht 200 bis 250 Quadratmeter mal als Beispiel so also. Wenn du es jetzt so zum Beispiel auf Wohnhäuser beziehst, also so ein Einfamilienhaus wäre, es wäre ein sehr großes Einfamilienhaus zum Beispiel, dann wäre es auch nach meiner Definition groß. Genau so.
Und jetzt kommen wir zu dem spannenden Teil, weil du hast gerade gesagt, kommt es jetzt darauf an, es ist ein Einfamilienhaus, es ist ein Mehrfamilienhaus und. Vielleicht stellen sich manche Leute auch darunter vor, dass n großes Haus ein Haus ist, was quasi wirklich von der Höhe her groß ist und nicht von der Fläche her.
Beispielsweise ne, das heißt n großes Haus könnte wär für manche vielleicht nicht, wenn es weiß nicht 500 Quadratmeter hätte aber nur eine Etage, aber vielleicht wenn es mehrere Etagen hätte, was auch immer, also von der Höhe her, es gibt viele Interpretationen davon und wenn ich jetzt zum Beispiel sagen würde, Tino Pass Aufbau mir doch mal bitte ein Haus, ein Großes. Dann wird es schwierig. Weil du ja offensichtlich nicht wissen kannst, was ich zum
Beispiel von dir möchte. Was ist groß, verstehst du genau und einfach nur mal, um? Mit diesem Aufhänger würde ich gerne in die Folge starten und in das Thema der Folge und zwar geht es um Anforderungen und warum Anforderungen in der Software Entwicklung und vielleicht auch nicht nur in der Softwareentwicklung wie wir gerade gesehen haben, also unglaublich essentiell sind. So genau, und da können wir ja vielleicht einfach mal n bisschen gucken.
So, warum ist das so? N bisschen haben wir es jetzt schon mal in einem Beispiel demonstriert. Und was sind vielleicht auch unsere Erfahrungen dabei? Und was passiert, wenn es halt ja nicht ordentlich, also wenn man nicht ordentlich die Anforderungen an die Software stellt? Was hältst du davon? Ja, ist ein ganz cooles Thema ist glaube ich auch ein Thema, was viel diskutiert wird, wo auch viele wahrscheinlich von der Theorie her wissen, wie es sein müsste.
Aber in der Praxis ist doch ein unglaublich schwieriges Thema ist. Sowohl also von beiden Seiten aus würde ich sagen, es ist halt n schwieriges Thema, sowohl für den, der die Anforderung stellt, also beispielsweise irgendein Kunde oder Stakeholder der Software und natürlich für den Implementierenden diese Anforderungen, also zum Beispiel wenn es ein Feature request ist, denn auch wirklich umzusetzen, was sich gewünscht wird, wie du es ja gerade ganz cool an dem
Beispiel klar gemacht hast. Wenn jetzt der Wunsch wäre. Bau mir ein großes Haus und ich würde sagen okay, das reicht mir, ich brauche nicht mehr Anforderungen oder genauere Anforderungen. Würde jetzt anfangen ein großes Haus zu bauen ist die Wahrscheinlichkeit ja ziemlich groß, dass Unmut am Ende aufkommt, weil es einfach nicht deinen Erwartungen entspricht, richtig, und das ist eigentlich eine ganz coole Analogie, die gefällt mir sehr gut shoppen.
Dankeschön, Dankeschön. Ja, also ich ja. Also ich möchte einfach mal n bisschen über dieses Thema reden, weil ich weiß ja, dass du und auch ich in der Vergangenheit auch einfach. Auch damit zu kämpfen haben. Einfach weißt du das man. Anforderungen bekommt und diese Anforderung halt nicht. Leider nicht immer klar genug definiert sind. Ne. Und genau diese 2 Punkte, die du gerade auch schon angesprochen hast, sind ja unglaublich wichtig. Weil natürlich kannst du eine Anforderung definieren.
Und vielleicht ist diese Anforderung per Definition für
dich klar. Aber die Frage ist natürlich, was kommt bei der anderen Seite. Also wenn man jetzt sagt, der Stakeholder stellt die Anforderungen und der Stakeholder sagt, für mich ist die Anforderung klipp und klar, manchmal sieht man ja den Wald vor lauter Bäumen nicht, du kannst ja zum Beispiel, wenn wir beim Beispiel bleiben, wenn für mich definitiv klar ist, was ein großes Haus ist, manchmal hinterfragt man seine eigenen Gedanken nicht mehr.
Das ist so klar und wie ich meine, man sieht den Wald vor lauter Bäumen nicht mehr. Dann ist es eben schwierig oder kann schwierig sein, diese Anforderungen weiterzugeben, weil die andere Seite sagt dann also im optimalen Fall, an dieser Stelle würde ich mir denken, dass die entwickelnde Seite sagt, Moment, da sind noch einige Fragen offen, aber ich fand die Idee von dir auch gut zu sagen, ja okay, aber was ist denn, wenn die andere Seite einfach sagt?
N großes Haus, klare Sache, mach ich dir, hab ich genaue Vorstellung von, also beide Seiten sehen den Wald vor lauter Bäumen nicht. Find ich auch nicht schlecht und das wär natürlich. Das ist natürlich worst case, ne. Ja genau, da fehlt dann halt einfach diese klare Kommunikation dazwischen. Und das meine ich halt immer mit Theorie und Praxis.
In der Theorie weiß jeder, OK, es muss klar kommuniziert werden, was sich gewünscht wird, es muss detailliert aufgeschrieben sein, sodass quasi der Entwickler genau weiß, was zu tun ist und die Realität ist ja oft so.
Der also der Anfordernde klingt komisch, also der Stakeholder sagt, Ich hab's klar definiert, ich denke, das ist absolut klar, was ich mir wünsche, der Entwickler denkt sich, liest einmal drüber ja okay alles klar, ich hab sofort eine Vorstellung was das beinhalten soll und im Worst case wie du schon meintest Match das aber nicht, dass beide eigentlich in dem Moment zufrieden sind und loslegen, also was heißt loslegen das Stakeholder kümmert sich vielleicht um andere
Themen, weiß nicht blenden wir mal kurz aus gehen wir mal auf die Entwicklersicht und du denkst dir. Ja gut, dann entwickle ich das jetzt, weil ich weiß ja, was zu tun ist. So, und dann kann es entweder sein, während der Entwicklung denkst du dir so. Ja Moment mal, mach ich das jetzt so oder so?
Also warte jetzt bin ich mir unsicher, wie soll das jetzt eigentlich sein und da fällt dann erst auf so vielleicht es doch nicht so genau spezifiziert, das ist im Prinzip ein Case, der aber noch OK ist, weil dann kann es ja nach spezifizieren der absolute Worst case ist ja wenn du auch diesen Moment nicht hast und am Ende sozusagen.
Sagst hey, ich bin fertig hier, bitte schau es dir an und dann ist es komplett an den Anforderungen vorbeigegangen und das klingt zu utopisch oder unwahrscheinlich, aber das ist nicht unwahrscheinlich, dass man stark an Anforderungen vorbei implementiert, das geht halt schnell in solchen Fällen. Ja, richtig. Also ich meine, ich finde, ein
gutes Beispiel ist tatsächlich. Wenn wir jetzt mit Git unterwegs sind und du sagst zum Beispiel okay, ich möchte gerne automatisiert einen Brunch in den, also einen lokalen Branch in den Remote Branch Mergen, da könnte man vielleicht am Anfang sagen, ja gut, das ist total logisch, macht sehr einfach, es geht schnell. Also du sagst einfach okay push.
Ne Push dein dein Änderung von deinem Branch einfach Remote synchronisiere den und alles ist gut so, das könnte ja vielleicht sozusagen die Anforderung sein und und auch die Erwartungshaltung sein, dass man sagt, OK passt auf, es gibt Änderungen auf dem lokalen Branche, Du möchtest Änderungen auf nem Remote Branch pushen und das ist die Anforderung, es muss einfach nur hochgeballert werden, so nach dem Motto.
Und dann kann es ja durchaus einfach nur mal um das vielleicht mal so versuchen, ein kleines Beispiel zu generieren. Du kannst ja durchaus sein, dass du verschiedene Edge Casts hast, die du dann entweder mitbekommst wie du meintest oder eben nicht. Also wenn du jetzt zum Beispiel sagst, du kriegst es mit und
denkst dir warte mal. Aber was ist denn eigentlich, wenn ich meine Änderung pushen will und es gibt einen Merch Konflikt so und du denkst nicht daran so also solche Sachen können ja auftreten und dann ist eben die Frage anforderungstechnisch wie geht man damit um, sagt man einfach Push Force Haue ich einfach meine Änderungen ganz klar drüber und ich. Was soll passieren?
Und das ist genau der Punkt, der zum Beispiel mich auch in in mich als Softwareentwickler sag ich mal in meiner Laufbahn öfter mal n bisschen begleitet hat, das Anforderungen gestellt werden, die erstmal sag ich jetzt mal. Den Happy Pass abbilden im Sinne von du möchtest irgendetwas machen und also die Software soll irgendetwas tun, ne aber was passiert wenn es zum Beispiel zu Konflikten kommt?
Ne in diesem Happypass also wir von diesem Happypass abweichen, also es ist nicht alles gut, es funktioniert nicht alles so, sondern es kommt vielleicht mal zu einem Fehler, zu einem Problem. Und da habe ich zumindest persönlich die Erfahrung gemacht, dass oftmals an dieser Stelle solche Anforderungen vergessen werden, weil das gehört meiner Meinung nach mit zu den Anforderungen. Dieses, nennen wir es mal Feature mit dazu.
Weißt du, weil das schwierige an der Stelle ist, finde ich, wenn du jetzt genau diesen Punkt hast und sagst, Na ja, gut, pass auf, wir sollen ja wirklich den Branch, den lokalen Branch zur Änderung des lokalen Branches auf Remote pushen, das ist die Anforderung. Und wenn es jetzt vielleicht so ist, dass man irgendwie merge Konflikte hätte. Die Anforderung ist ja offensichtlich, dass im Endeffekt das einfach. Ja, hochgeschoben werden soll.
Also mach ich n. Push Force und Bügel alles über und am Ende sagt der Stakeholder Moment, hier sind Änderungen verloren gegangen und das ist halt das Problem, weil dann denkst du dir so. Na ich denke wir sollten das so machen. Ja. Und da kommt es halt zu. Problemen. Ja OK, also verstehe ich das Beispiel. Ich hoffe Liebe zur Geburt, du hast das mit dem Git auch verstanden, das Beispiel. Genau also was du meinst ist im Prinzip, dass der. Der Stakeholder quasi eine
Vision im Kopf hat. Also so ein Wunschverhalten der Software diesen sogenannten Happypass, wie du das formuliert hast und. Dann im Prinzip nicht berücksichtigt, was alles auf diesem Weg passieren kann beziehungsweise denkt. Er hat alles berücksichtigt und dann kommt trotzdem Cases. Die quasi, wo er denn selbst noch nicht weiß, wie er das eigentlich haben möchte.
Das ist ja auch so n so n Fall, der öfter mal auftritt wie du schon meintest, so na ja gut, er möchte ja scheinbar immer das was lokal liegt, ich greif das Beispiel noch mal kurz auf auf dem Server Remote zur Verfügung stellen und das ist immer der Stand der zählt, also bügeln wir quasi immer alles über das heißt wir überschreiben die Änderung und er denkt sich so Moment mal, jetzt ist ja ein Fall eingetreten, dass da Sachen waren. Die unterschiedlich waren.
Und die werden jetzt quasi überschrieben, dass da den Fall habe ich gar nicht berücksichtigt, dass das zustande kommen kann. Ich dachte, es kommen immer nur neue Sachen drauf und nicht, dass Sachen quasi durcheinander kommen und dann überschrieben oder verworfen werden. Das ja, das ist ein ganz klassischer Fall.
Quasi. Ja. Mir ist gerade ein Beispiel eingefallen, weil du meintest, hoffentlich konnte jetzt jeder folgen im Sinne von diesem Gipfel. Spiel, aber stell dir mal vor, ich sag jetzt zu dir Tino, kannst du mal n bisschen Milch holen fahren so ne weil wir keine Ahnung wir wollen heute Abend irgendwas kochen und wir brauchen Milch du kannst mein Fahrrad nehmen, fahr damit einfach zum Supermarkt du darfst sagst ja alles klar ich soll Milch holen. Fährst mit dem Fahrrad zum Supermarkt.
Du hast n Platten, ne denkst dir OK, dann lass ich das Fahrrad halt hier stehen und lauf halt mit der Milch nach Hause, kommst an und sagst hier ist deine Milch und dann sag ich OK wo ist aber dein Fahrrad und dann sagst mein Fahrrad und dann sagst du ja das hatte n platt ich hab es einfach stehen lassen so ich hab nicht die Anforderungen gestellt zu sagen wenn das Fahrrad einen Platten hat dann bringt es bitte trotzdem wieder mit zurück also
weißte oder es hätte ja auch sein können, dass du dir sagst ich bring das Fahrrad mit nach Hause weil der will ja bestimmt sein Fahrrad wieder haben und ich sag aber. Du solltest die Milch mitbringen, aber wenn du Platten hast, dann lass das Fahrrad doch da liegen. Das ist doch kaputt, will ich nicht mehr haben. Also die Frage ist halt, du kannst dir nur denken ja gut wahrscheinlich möchte. Er, dass ich das Fahrrad mitbringe und wahrscheinlich wird es auch die richtige
Intuition sein, die du hast. An der Stelle, aber unter Umständen, wenn man jetzt auf das in der Softwareentwicklung ist, kann es halt sein, dass es nicht immer das ist, was man sich denkt, was es ist, wie es sich verhalten soll. So. OK. Jetzt wusste ich kurz mal selbst mitkommen. Ja, genau, also man man, man setzt halt quasi oder setzt Sachen voraus, die nicht beschrieben sind, weil man die quasi so von von sich ausgeht. Meinst du das damit, dass du
gewisses Verhalten voraussetzt? Aber dann lass uns doch noch mal auf das Hausbeispiel gehen. Wie würdest du das denn besser finden? Also mal angenommen, das war jetzt, wir schreiben jetzt eine Anforderung an einen Entwickler oder bzw dann. An die Handwerkerbauarbeiter. Wie auch immer. Ich möchte ein großes Haus haben. So, das ist natürlich super unpräzise und kann einfach alles rauskommen.
Das heißt, es muss ja mehr spezifiziert werden, dann könnte man ja jetzt beispielsweise im nächsten Schritt sagen. Das Ganze soll eine Wohnfläche von so und so viel Quadratmeter haben. Auf Xetagen und mit x meine ich jetzt, das kann jetzt jeder für sich einstellen, da sollte natürlich eine Zahl drin stehen. Sagen wir mal keine Ahnung. 200 Quadratmeter auf 2 Wohnetagen ja. So. Mhm, wäre das denn jetzt präzise
genug? Es. Also ich würd sagen, das ist noch nicht präzise genug, weil du natürlich vielleicht auch noch definieren müsstest an diesem Beispiel. Wie sollen die beispielsweise die Zimmer, wieviel Zimmer sollen pro Etage hinkommen, wie sollen die Zimmer gelegen sein? In welche Richtung sollen vielleicht sogar die Türen öffnen? Wo sollen die Türen sein von den Zimmern und wo kommt beispielsweise ein Badezimmer hin, wo kommt zum Beispiel die Küche hin? Solche Sachen ne.
Also es ist natürlich schon wichtig. Möglichst präzise diese Anforderung auszuformulieren, ne. An der Stelle kann man ja zumindest vielleicht auch noch sagen, dass das Beispiel mit einem Haus als einzelne Anforderung natürlich recht groß gewählt ist, ne? Wenn wir jetzt in der Softwareentwicklung unterwegs sind, ist es natürlich schöner, wenn man vielleicht kleinere Pakete schnürt. Ne ist auf jeden Fall sehr empfehlenswert. Sodass halt die Anforderungen möglichst Kleinigkeiten
umfassen. Ne, also sagen wir mal, man würde zum Beispiel diesen dieses dieses Zaun hauen bauen von dem Haus würde man jetzt zum Beispiel unterteilen in mehrere Aufgaben. Ne, dass man zum Beispiel sagt, OK, was ist denn die Anforderung an die Grundfläche? Ne, was ist denn die Anforderung an zum Beispiel? Die Etagenzahl ne, was ist die Anforderung an die?
Zimmer, wie sie gelegen sind, also dass man das so sukzessiv aufbaut, weil du könntest ja anfangen und sagen, OK, ich leg erstmal den Grund. Grundriss, wie man das nennt, ne also den das Fundament bau dann sozusagen die am Fundament die. Das Haus drumherum, die wie nennt sich das? Das Grundgerüst auf. Und so weiter. Man merkt, wir sind ja auf jeden Fall die absoluten Handwerker. Die kommen nur auf Fachbegriffe hier um die Ecke.
Das ist aber, um dann die Softwareentwicklung zu kommen, um vom Handwerk weg, weil das auf jeden Fall nicht unser Steckenpferd. Das ist nämlich ein wichtiger Punkt, was du gerade gesagt hast, wo halt auch schon sehr oft dran kränkelt, sage ich mal, dass diese Features oder diese Anforderungen einfach viel zu viel umfassen, weil das genau die Wahrscheinlichkeit enorm steigert, dass Sachen vergessen
werden. Also wenn die Anforderung ist, bau mir bitte ein Haus, dann ist da so viel Spielraum drin, dass alles Mögliche passieren kann, was quasi an der eigentlichen Vorstellung dran vorbeigeht und selbst wenn man jetzt anfängt, deswegen habe ich das mal so ein bisschen eingeladen.
Zu spezifizieren, wie dieses Haus aussieht, die Wahrscheinlichkeit immer noch sehr groß, dass Sachen vergessen werden, weil du die vielleicht im Kopf wieder voraussetzt, dass ja Unstimmigkeiten auftreten, also quasi wieder Abweichungen zwischen deiner Vorstellung und der realen Umsetzung am Ende. Ja, und da hast du ja schon einen guten Punkt gebracht, dass es immer von Vorteil ist. Diese Aufgabenpakete nenne ich es jetzt mal, also diese Anforderungen oder Feature
wünsche. Klein hält, weil man sie einfach besser überblicken kann und besser analysieren und spezifizieren kann und dann quasi sukzessiv darauf basierend dann nach und nach zu dem Gesamtziel kommt und. Halt wirklich ein sehr entscheidender Punkt, den ich so erfahrungsgemäß festgestellt habe. Beispielsweise hatte ich mal. Ein Ticket beziehungsweise das hatten wir beide sogar, das war in der Zeit, seitdem wir wieder
zusammenarbeiten. Das war relativ umfangreich, hat aber auf den ersten Blick nicht so gewirkt. Und. Da war nämlich genau der Fall, dass beide Seiten der Meinung waren, OK, hier ist alles spezifiziert, so wie es sein müsste und wir haben quasi angefangen es zu implementieren. Und dabei hat sich dann doch immer mehr herausgestellt, dass es wesentlich größer ist als anfänglich gedacht. Und das wär halt auch der Punkt, wo man sagen müsste, OK das das wird so wahrscheinlich nicht
funktionieren. Man müsste das entweder noch mal runterbrechen oder ja halt splitten.
Ne, diese ganze Anforderung. Und das ist jetzt wieder Realität und Theorie. Es ist aber anders gelaufen als gedacht, sondern es lief im Endeffekt so, dass man immer nachspezifiziert hat, weil man dachte, na ja, gut, das ist jetzt vielleicht noch so ein ein Ding, was fehlt, das schreibe ich jetzt mal bei uns, in dem Fall noch ins Ticket rein, ja gut, alles klar, dann wissen wir jetzt für den Fall, was zu tun
ist. So, und das ist x mal passiert und das beinhaltet natürlich auch, und das ist eine große Gefahr, um mal so auf negative Aspekte einzugehen. Wir haben auch viele Sachen doppelt gecoded, weil wir dachten, okay, es müsste jetzt nach Schema A laufen haben das
implementiert. Dann wurde festgestellt, Herr, nee, nee, nee, das ist eigentlich gar nicht, nee, das wird so nicht funktionieren, jetzt, wo ich noch mal drüber nachdenke und das Ausprobieren, das wird so nicht funktionieren, wir brauchen Schema B, alles klar, dann reverse du das bzw implementierst Schema b und sagst dann wiederum so jetzt aber jetzt haben wir es doch oder?
Ja, aber jetzt ist irgendwie. Jetzt fehlt mir n bisschen was aus Schema a. Also wir müssen jetzt irgendwie gucken, dass wir das irgendwie noch zusammenfügen. Und wenn du in diesem Hamsterrad drin bist. Ja. Dann Gnade dir Gott. Also dann ist halt wirklich n Teufelskreis eröffnet, weil keiner mehr am Ende wirklich weiß, was will ich hier wirklich, was brauch ich, was muss ich tun und dann wird es
halt richtig. Richtig tricky und vor allem frisst es Zeit. Also es ist dann kein effektives Arbeit mehr in meinen Augen. Na du bist ja dann, und das ist. Halt keine Seltenheit, dass sowas passiert. Und du bist ja dann irgendwann in so einem. Wünsch dir was. Zirkel gefangen, wo dann irgendwie am besten kommt noch noch jemand anders mit rein und sagt ja das wär aber auch noch gut. Eigentlich muss es so sein und dann? Dreht sich alles nur noch kreuz und quer durch die Gegend?
Aber ja, du. Verlierst halt das Ganze aus den Augen so. Ne genau, und das fühlt genau das ist halt wirklich schwierig, weil im Endeffekt bringt es halt nichts, weil du verlierst. Halt Zeit und du verschwendest halt Geld. So und schwierig wird es dann und das ist halt meine Erfahrung, die ich öfter mal gemacht habe. Ich sag nicht, dass das immer so ist, aber ich habe durchaus die Erfahrung auch gemacht.
Dass im Endeffekt du vielleicht Zeitdruck hast und wenn du Zeitdruck hast, habe ich die Erfahrung gemacht, dass. Die Anforderungen zusätzlich sogar schwammig formuliert werden, weil Leute es schnell haben wollen. Leute wollen schnell Feature X haben, machen sich aber aus Gründen der vielleicht zeitprobleme noch weniger Gedanken darüber, wie sich Feature X irgendwie verhalten soll. Genau das zum Beispiel hier mit diesem Milchhohe Fahrradbeispiel.
Da wird dann nicht über Eventualitäten nachgedacht, über Sachen, die eventuell passieren könnten und wie man damit umgehen soll. Und dann kommt es genau zu dem Punkt, dass du schnell was implementierst, das dann halt
eben nicht ganz vollständig ist. Du wieder eine Runde drehst, dann noch mal in die Gespräche kommen musst, überlegen muss, was passiert denn hier, es wird wieder schnell, schnell, schnell gemacht, du implementierst es wieder, schnell, schnell, schnell und am Ende drehst du halt, anstatt eine ordentliche Runde 3. Runden, die einfach nur Waste waren und hast am Ende aber doppelt so lang gebraucht und das sieht man aber am Anfang vielleicht nicht so ne.
Also es wird am Anfang gerne mal übersehen. Meiner also meine Erfahrung nach ich sag nicht, dass es immer so ist und dass es bei jedem. Auf dieser Welt, so ist aber es ist halt die Erfahrung, die ich dabei gemacht hab und das ist halt schwierig. Ja. Bearbeiten möchte also mal als kleines Beispiel ne, wenn sagen wir mal du hast n irgendein System ne Anwendung wo du dich
als User registrieren kannst. Ne dann ist es erstmal ja überhaupt gar kein Problem zu sagen du hast vielleicht Anforderungen an die Systemen die sich sukzessiv aufbauen, es ist ja kein Problem zu sagen, ey du kannst dir ein user Profil anlegen, das ist die erste Anforderung die wird gemacht in einer Iteration sage ich jetzt mal ne wenn wir jetzt.
Einem agilen Umfeld sind aber du hast einen gewissen Zeitumfang, vielleicht wo du sagst oder eine gewisse Planung und sagst in diesem Planungszyklus sage ich mir jetzt, ich möchte gerne, dass man sind jetzt sehr kleine arbeitspakete oder sehr grobe, grob gefasste arbeitspakete User anlegen kann. So, dann möchtest du zum Beispiel okay du möchtest, dass du noch ein Bild anlegen kannst, also ein User Profilbild anlegen
kannst. Dann als nächstes sagst du noch, ich möchte auch noch, dass der User sein Profilbild ändern kann, das sind ja. Klare Anforderungen, die nach im. Im Nachhinein sag ich jetzt mal sukzessiv formuliert werden und die kannst du auch super abarbeiten und deine Software im hoffentlich im Normalfall gut erweitern, ne? Alles kein Problem.
Schwierig wird es eher, wenn man sagt, OK, wie soll die Anforderung für das Profilbild denn sein, ne, und du sagst zum Beispiel ja, das Profilbild darf nur die und die Größe haben und es wird auf jeden Fall nur ein Bild sein. Und das ist wirklich eine feste Anforderung an diese Software. Und dann kommt aber vielleicht sowas wie übrigens eine Sache wäre dann doch noch ganz wichtig, vielleicht auch ein bisschen später. Das Profilbild müsste jetzt doch
ein Video sein können. So, und da könntest du halt unter Umständen Teufels Küche sein oder kommen, weil klar kann man jetzt sich hinstellen und sagen, naja gut okay, du hast aber jetzt es ist auch eine sukzessive Änderung, es kann aber durchaus auch sein, dass also das ist finde ich dieser kleine Unterschied zwischen es ist eine sukzessive Änderung oder du legst von vorne herein wirklich Grundpfeiler fest und das ist jetzt vielleicht nicht ein starkes Grundpfeiler, sowas
kann man ändern dieses Beispiel. Aber je stärker sich quasi oder je stärker diese Grundpfeiler im Boden verankert sind, desto schwieriger wird es halt eben diese Änderungen zu machen. Und das ist halt schwierig. Ja. Und in unserem Halt mit mehr Aufwand wieder verbunden. Genau, genau und prinzipiell klingt das jetzt erstmal an sich jetzt nicht, nicht nicht schwer. Ne du sagst OK ne Speicher anstatt n Bild halt einfach n. N Video kann man natürlich auch
machen. Es kommt vielleicht n bisschen drauf an, wie wie man sozusagen die Speicherung von dem Profilbild oder Video dann am Ende gewählt hat. Ne kommt dann n bisschen drauf an, aber im Endeffekt ist es ja jetzt auch ne Änderung, die durchaus möglich ist. Aber ich sag nur mal rein theoretisch könnte es ja
vielleicht auch. Unter anderen Umständen dazu kommen, dass bestimmte Änderungen reinkommen, die vielleicht wirklich einschneidend sind, so dass du dann nicht mehr so einfach in der Lage bist, diese Anforderungen zu ändern, weil sie halt eben in dem Grundgedanken dieser Anforderungen vielleicht auch verankert sind. Ja, und das also was was du
meinst. Damit ist quasi wenn im Vorfeld das schon weiter oder konkreter überlegt worden wäre, dass dann halt so Breaking Changes vermieden werden könnten, genau oder worauf möchtest du da mal hinaus? Ja also du kannst natürlich, du kannst dich natürlich hinstellen und sagen, gut ich also du ich find das ist ja.
Da spielen ja 2 Sachen ineinander, finde ich, weil auf der einen Seite hast du die Anforderungen, die vielleicht nicht gut gestellt wurden, ne oder beziehungsweise vielleicht auch im Vorfeld nicht gut überlegt worden, weil ne man könnte sich auch hinstellen und sagen naja pass auf. Lass uns mal ein Bild und ein Video machen, weil wenn du gerade vielleicht dabei bist und das fertig.
Gerade in dem Moment fertig hast und dich dafür entschieden hast und eine Rückfrage gestellt hast, soll es wirklich nur ein Bild sein? Ja, es soll nur ein Bild sein und du gehst davon aus, dann musst du ja vielleicht nicht deine Software dafür auslegen, dass du auch ein Video speichern
kannst. Ist ja nicht notwendig und wenn du wirklich mit Sicherheit weißt vom Stakeholder, das muss nur ein Bild sein, alles gut, dann kannst du dich genau darauf auch einigermaßen anpassen, vielleicht auch speicheroptimierung, was auch immer, aber wenn du jetzt und wenn wenn du dann sagst, ist es wirklich so. Ja es ist wirklich nur ein Bild, dann machst du das.
Das Feature ist fertig und dann kommt weißt du was eigentlich doch ein Video, das ist halt blöd, weil dann drehst du wieder diese Runde musste es noch mal umändern und. Längst halt Zeit, weil wenn du das im Vorfeld gewusst hättest, so, ich mein jetzt ist es n Unterschied, wenn jetzt nach n Jahr später jemand kommt und sagt Ey der Markt gibt es her, wir müssen das ändern, es ist unglaublich wichtig jetzt n Video als profilbild auch zu haben ist das find ich auch ne
andere Geschichte ne? So ja ist n wichtiger Punkt. Ich würd mal noch mal an unserem Haus weiterbauen, damit man sich das besser vorstellen kann. Das ist ja genau so, als wenn du sagst, OK, ja gut, ich spezifizier jetzt weiter meine Anforderungen und übrigens ich würde gerne ich möchte gerne heizen in den Räumen. Und du sagst du ja okay kann die Heizkörper an die Wand machen können Fußbodenheizung machen was du möchtest. Ja du ich glaube so Heizkörper
ist cool. Ich brauche keine Fußbodenheizung. Gut, dann wird das Haus gebaut, so bodenestrich wird alles gegossen, fertig, Bodenbelag drauf, was auch immer, ist nicht spezifiziert. Und dann sagt der Kunde auf einmal. Aber weißt du, so eine Fußbodenheizung ist doch ziemlich geil. Komm, das machen wir noch. Und dann fängst du an zu schwitzen und denkst dir so ja
okay. Aber wir haben doch jetzt schon, der Boden ist fertig, ich muss das jetzt alles wieder rausreißen, um da diese Matten oder was auch immer zu verlegen. Why fällt dir das jetzt erst ein? Das ist n riesen Umbau, ich glaub der Mitarbeiter kommt da reinzuschwitzen. Der wirft sein Leis Werkzeug in die Ecke und das nie wieder gesehen. Ich bin raus, baust doch selbst. Nee, aber um das mal quasi so in den in alltägliches Beispiel zu kippen. Das für Schweiß und Arbeit bedeuten könnte.
Dann und vor allem auch finanziell, das ist ja auch immer in so Projekten ein riesen Punkt, weil Zeit ist Geld und wenn du da lange brauchst, um das geben wir jetzt mal nicht von den Materialien aus, jetzt wie beim Handwerk, aber in der Softwareentwicklung was das an Geld kostet das denn alles wieder umzubauen, nur weil am Anfang sich die Anforderungen nicht genau überlegt wohnen und du siehst ich mag dein Hausbeispiel, da kann man gut dran erklären, das ist ja aber
auch genauso. Auch noch mal das Hausbeispiel, das ist nämlich gar nicht so so so unrealistisch. Ich habe sehr oft überlegt, dass ein Projekt gestartet wurde, es gab ein Big Picture, das heißt, es gab eine Vision, was das Tool oder die Softwarelösung am Ende können soll. Das wurde sozusagen gepitcht. Ja. Und los. Und du denkst dir so. Und los. Dann werde ich jetzt anfangen, das zu implementieren. Ja, ja, fang an los, ja habt ihr irgendwie gibt es irgendwelche Anforderungen daran, was ich
berücksichtigen soll? Na ja, das was es können soll. Aber so richtige Anforderungen haben wir noch nicht. Und dann kommt das, was immer sehr gefährlich ist.
Die werden aber noch kommen, ja, wir haben sie jetzt noch nicht aus Zeitgründen, aber wir werden die Anforderungen nachreichen und mach erstmal ohne Anforderung implementier doch erstmal ohne Antwort, du weißt ja wo es hingeht soll und ich schwöre dir in vielen Projekten in denen ich gearbeitet habe, war das der Fall und auf Twitch hatten wir da auch mal eine Diskussion und ich fand es so krass, dass es anderen Entwicklern genauso geht, dass sie sagen, welche Anforderungen
kann es froh sein, wenn du überhaupt Anforderungen hast. Ich meine, dann braucht man sich doch auch nicht wundern. Dass es so oft an den potenziellen späteren Anforderungen daran vorbei geht, ja, das ist doch, das ist ja eigentlich, das ist doch so logisch, und da haben wir wieder Theorie und Praxis, es ist so logisch in der Theorie, dass das
nicht gut gehen kann. In der Praxis wird es doch oft so gelebt, ja genau, also dass das Ding ist, man will sich ja nicht hinstellen und sagen, also mein Klemmer an der ganzen Geschichte. Ist das oftmals von Anforderungen. Seite jetzt aus meiner Entwicklersicht eine Anforderung kommt und gesagt wird, mach das mal so, dann hast du vielleicht zu wenig Informationen.
Du fragst vielleicht noch nach, es dauert, es ist alles nicht klar, du entwickelst vielleicht, dann war es das doch nicht so, wie wie es gedacht worden ist, weil die Anforderungen falsch gestellt worden sind. Mal als Beispiel kann ja auch passieren, jemand sagt Anforderungen so und so und merkt dann. Mal.
So wollte ich das ja gar nicht. Ist ja irgendwie blöd gelaufen so, aber wenn du dann an diesem Punkt kommst, wo du dann sagst okay, jetzt habe ich es aber irgendwann fertig, dann kommt von sag ich mal vom von Stakeholder sich kommt dann um, dort ist alles so lange so und dann denke ich mir so es ist halt ich lehne mich jetzt mal aus dem Fenster, das ist eine Frechheit weil man schiebt die Schuld von sich weg und sagt Pass mal auf Leute ja was dauert bei euch so lange aber ich
möchte gerne ein großes Haus aber was dauert das so lange so und das ist halt das das sowas nervt mich persönlich halt einfach. Weil es ist ja wichtig, dass man halt einfach also ne, wenn die eine Seite das Beste geben soll, dann sollte die andere Seite genauso das Beste geben und dann kann da was draus werden. Es ist ja auch nicht so als würde man ne. Es kann natürlich auch durchaus sein, dass die Anforderungen perfekt gestellt werden.
Das softwareentwickelnde Team aber sich denkt, wir bauen jetzt unsere Software so blöd, dass sie überhaupt nicht gut erweiterbar ist, nicht gut wartbar ist. Man kann mit dieser Software eigentlich überhaupt nichts mehr machen. So, wenn also changes reinkommen, ne. Und das ist natürlich auch blöd, ne, weil es ist, es ist ja, es ist ja wichtig, dass man sagt, OK, es ist n Unterschied zwischen fehlende Anforderungen oder Du hast Anforderungen die sich im Verlaufe des Projektes
ändern. Ne das ist das ist das ist n. Feiner, aber feiner Unterschied, der unglaublich wichtig ist, weil wenn wir in einem agilen Softwareentwicklungsumfeld unterwegs sind, können sich die Anforderungen ändern. Das ist gar kein Problem, sag ich jetzt mal.
Ne, also es kann durchaus sein, dass dass sich, dass sich Sachen verändern, aber nicht während einer Feature Entwicklung, also oder nicht um 180 Grad, das ist halt ein kleiner Unterschied und das ist halt ein absoluter Struggle, weil du kannst dich natürlich auf der anderen Seite hinstellen und sagen Wir sind hier im agilen Softwareumfeld alles cool, ich kann machen was ich will, ich kann meine Anforderungen ändern. Wir reagieren doch ganz agil und schnell darauf.
Ja, das ist. Weißt du was? Ich weiß halt auch schwierig, also ich, ich weiß absolut was meins ist. Das Thema dabei ist, wir sehen das natürlich viel aus Entwicklersicht, weil wir ja auch Entwickler sind. Ich möchte da nur anmerken, es ist aber auch nicht einfach. Ich denke, das hat man auch jetzt hier in der Folge schon herausgehört, vernünftige Anforderungen zu definieren oder ein Feature Wunsch so klar zu definieren, wie man es gerne hätte, weil man halt vieles
berücksichtigt. Man muss auf fairerweise sagen, und das ist auch dann nicht mehr die Aufgabe des Stakeholder, sag ich mal. Dass man ja auch nicht weiß, was das für die Software alles bedeutet. Also ich, ich definiere ja auf oberster Ebene quasi ein eine Funktionalität beispielsweise, die ich gerne noch on top hätte in der Software. Ja. So bin aber ja nicht derjenige, der unter der Haube weiß, wie das alles entwickelt wurde und was daraus resultieren könnte.
Also es ist ja schwierig, quasi den Einblick zu haben, geht das überhaupt so richtig, so einfach wie ich das hätte, wie ich das mir wünsche oder oder was bedeutet das, das ist ja auch nicht mal die Anforderung, weil du entwickelst das ja auch nicht, das Tool. Spezifisch zu sagen, welches Verhalten soll denn wann wie eintreten oder wie soll sich das Feature verhalten, das liegt ja schon in deiner Verantwortung und da muss ich sagen, wenn ich zum Beispiel so eine Anforderung
definiere, fällt mir das auch schwer, das immer sehr präzise zu machen, weil du halt vielleicht Sachen voraussetzt, die gar nicht gegeben sind, oder oder. Einfach, dass man einfach Cases vergisst, wie du ja meintest. Zu einer bekannten Edge Cases, die einfach sehr selten auftreten, aber auftreten können und dann nicht klar ist oder undefiniert ist, wie das Verhalten sein soll. Und da muss ich sagen, es ist halt für beide Seiten schwer.
Und das spricht wiederum dafür, dass es eine sehr gute Kommunikationsschnittstelle da geben muss in meinen Augen. Definitiv. Also stimm ich dir total zu. Ich kann auch noch mal. Mir fällt gerade ein kleines Beispiel ein, also ich hab auch mal an einem Projekt gearbeitet. Wo? Es gab eine Phase, wo Anforderungen, also sagen wir mal User Stories gestellt worden von den Stakeholdern an unser Entwicklerteam.
Und wir haben dann diese Stories besprochen, also überlegt ok, bevor man sie richtig bearbeiten kann, werden diese Stories einmal besprochen. Team und das wurde dann quasi
von unserem PM gepitcht. Er hat uns dann das vorgestellt, weil er in meinem Austausch mit den Stakeholdern war und hat uns dann gesagt Okay Pass auf das und das wird gewünscht so und dann haben wir im Team diese Aufgaben besprochen und dann hatten wir eine Phase, wo es sehr oft dazu kam, dass wir uns dann überlegt haben, ja, aber was ist denn im Fall XY, das ist ja hier überhaupt nicht definiert, ist aber unglaublich essenziell für die Software. Weil wir sonst unter Umständen
für irgendwelche Einheiten, die wir sozusagen gehalten haben in unserer Software undefinierte Zustände hätten. Und das durfte halt einfach nicht passieren. Demzufolge waren das sozusagen waren die Anforderungen nicht klargestellt, was an dieser Stelle überhaupt nicht schlimm
ist. Wie du auch meintest, weil wir haben das geklärt in diesem Termin, sozusagen im Team, haben die Fragen noch mal definiert, und dann ist es noch mal sozusagen zurückgegangen so, und in dem Fall hast du ja nicht das Problem, dass du schon anfängst zu implementieren und dann aber irgendwann merkst, oh mein Gott, hier ist gerade eine totale Sackgasse, das geht gar nicht, das heißt, wenn die Kommunikation stimmt, ist alles in Ordnung.
Nur wenn wir an den Punkt kommen, dass wir dann wirklich schon anfangen, eventuell merken, warte mal, hier stimmt irgendwas nicht und das hatte ich auch schon in dem gleichen Projekt. Du fängst an, du implementierst etwas, kommst selber erst an diesem Punkt, dass du dir denkst, Moment, was passiert in diesem Fall durchaus möglich und dann ging das noch mal zurück und dann wurde.
Aber ganz andere. Also dann haben sich die Anforderungen wirklich sehr, sehr gedreht, weil die sich selber dann gedacht haben, oh hey Mist, was ist das denn, das können wir so wirklich nicht machen und dann hast du halt. Wirklich. Und dann kommt halt die Unruhe rein. Ne, dann bist du wieder in den Teufelskreis. Und dann hast du aber wirklich
ne Menge Zeit auch versenkt. In dem Fall war es dann wirklich so, dass die Anforderungen noch mal durchgegangen sind, nochmal wirklich überlegt wurden und dann nochmal in unser Team kam. Wir haben das dann im Endeffekt bearbeitet, aber der Punkt an dieser Stelle ist, dass diese Entwicklungszeit, die wir vorher genutzt haben, halt wirklich waste war. Und wir hatten in dem Moment nicht großartigen Zeitdruck.
Es war soweit okay, aber wenn du jetzt dir noch vorstellst, dass Zeitdruck hinzukommt und ich vermute mal, dass einige, die auch zuhören, Liebe zuhören, lieber zuhören. Sicherlich auch mal in Projekten arbeiten oder gearbeitet haben, wo Zeitdruck da ist, weil dann wird es nämlich, dann wird es nämlich wild. So einer Stelle.
Ja, das n ganz guter Punkt auch, weswegen in der agilen Welt ja es Termine dafür gibt, sogenannte Refinements, um einfach denn noch mal sich diese Requests oder Feature wünsche sich anzuschauen, drüber zu sprechen um wirklich ein gemeinsames Verständnis davon zu schaffen und sich dann darauf festlegen zu können wie es sein soll und wie ihr dann in dem Termin gemerkt habt oder beziehungsweise beide Seiten dann gemerkt haben, sowohl der Stakeholder mit seinem Wunsch.
Der gemerkt hat, oh Moment, ich habe es mir nicht final überlegt und ihr euch schon mal Gedanken machen konntet und gemerkt habe ja, aber Moment für unsere Software, ich meine das kannst du nicht wissen von außen, aber es ist für uns wirklich wichtig zu wissen was in dem und dem Fall passieren soll und dafür ist so ein Termin ja super, dass das Ganze dann noch mal durchgesprochen werden kann um halt nicht diese Zeit zu verbrennen am Ende. Ja.
Das ist halt ein sehr essentieller Punkt und wichtig und deswegen auch bei so agilen Frameworks berücksichtigt. Genau. Also. Hast du noch was, was dir gerade spontan einfällt? Ansonsten würde ich dich einfach mal fragen. Nein, also ich denke ich denke das Ding ist es. Ist ein Thema, da kannst du sehr lange drüber reden und wir haben ja auch wie gesagt so in Twitch Sessions schon mit unseren.
Mit unserer Community drüber gesprochen und da uns ausgetauscht, weil es, was ich erstaunlich finde, aber auch nicht verwunderlich ist, dass es bei vielen zu Problemen dabei kommt. Es nie so quasi so eine heile
Welt gibt von. Also ich kriege mal Anforderungen, die sind so super, ich kann das einfach direkt runter coden, alle sind glücklich, alle sind zufrieden, so läuft es halt in den wenigsten Fällen, weil es halt einfach auch ein schwieriges Thema ist, viel mit Kommunikation zu tun hat und ja man sich, ich glaube was da hilft ist sich immer ein bisschen in die Lage des anderen zu versetzen, das heißt beim Entwickeln sich nicht denken, Oh
jetzt ist das schon wieder so Scheiße spezifiziert, ich weiß schon nicht was ich tun soll hier, sondern sich auch mal überlegen, ja gut, hätte ich denn daran gedacht?
Von der anderen Seite ja, und genauso als Anforderer, also als Stakeholder zu sagen, ja warte mal, könnte ich jetzt ganz objektiv, wenn ich dieses Ticket zum Beispiel lese oder diese Anforderung, könnte ich das entwickeln, was ich da aufgeschrieben hab, und wenn da die Antwort nein ist, weiß man ja schon, ja gut, da muss ich da wohl auch noch mal ran. Genauso ist es und dabei würde ich es.
Genau, warte ganz kurz. Genauso ist es auch wichtig, dass die Anforderungen, die gestellt werden, auch nicht in ewig langen Texten runtergeschrieben werden, zum Beispiel. Also das ist jetzt noch mal eine persönliche Erfahrung, die ich gehabt habe, die ich gemacht habe, das ist auch wichtig, du meintest ja, es muss verständlich sein und es muss irgendwie klar sein, was gewollt ist für jeden, auch objektiv im optimalen Fall, es ist aber auch wichtig, dass es auch nachvollziehbar ist.
Und wenn es ein riesen Text ist, wo man erst mal Ewigkeiten durchlesen muss, was gemeint ist und es nicht sozusagen in ordentlichen Punkten aufgelistet ist, sage ich jetzt mal, blöd gesagt einfach, dass man sich vorstellen kann.
Dann ist es halt eben schwierig. Und was ich auch sagen könnte ist, dass man zum Beispiel die entsprechenden Anforderungen, wenn sie denn auch klar aufgeschrieben worden, in welcher Art und Weise, dass sie auch, dass man aus externer Sicht die Möglichkeit hat, das zu prüfen. Mir diese Anforderungen, so wie sie gestellt ist, wirklich in meiner Software am Ende, das ist auch wichtig und den Punkt, den wir am ersten. Mal das ganze evaluieren.
Kann genau also wenn ich jetzt zum Beispiel Softwareentwickler bin und ich kriege eine Anforderung, dass ich dann ich implementiere das und sage zum Beispiel keine Ahnung, wenn ich. Weiß ich nicht. Angenommen ich, ich leg mir n user Profil an, dann möcht ich danach, dass ich sozusagen ne grüne Bestätigung habe, mein Userprofil wirklich da ist.
Ne, das heißt rein theoretisch könntest du jetzt als Softwareentwickler sagen, OK, wenn ich das jetzt mache in der Oberfläche die ich geschrieben hab.
Dann sehe ich hinterher eine grüne success Nachricht und kann vielleicht auch in meiner also Datenbank, die lokal einfach für mich in der Entwicklung läuft, nachgucken ob wirklich der User entstanden ist oder nicht nur mal als als Beispiel ne das sind wichtige Sachen die wo man einfach selbst für sich überprüfen kann funktioniert das auch und was auf jeden Fall, das möchte ich noch mal sagen, weil das ist mir sehr wichtig. Anforderungen in kleinen Paketen stellen hilft ungemein.
Ja, also da gibt es ja wie gesagt was du meintest so kurz fassend, so, da gibt es ja auch verschiedene Formate, wie man Anforderungen stellen kann oder aufschreiben kann, weil du ja vorhin schon das Wort userstory fallen lassen hast. Es gibt Akzeptanzkriterien werden oft verwendet, um zum Beispiel das auch Testbar zu machen, zu sagen, OK, was muss denn erfüllt sein, damit die Anforderungen im im Ganzen
erfüllt ist. Da gibt es ja verschiedene Möglichkeiten und Tools, die dabei helfen, das ganze Halt zu optimieren und trotzdem gibt es immer noch Probleme dabei. Deswegen, liebe Zuhörer, lieber Zuhörer, falls sich das Thema interessiert, wie kann man denn Anforderungen gut aufschreiben?
Was sind akzeptanzkriterien, was gibt es da noch so, dann melde dich gerne bei uns, dann können wir auch gerne da noch weitere Infos bereitstellen oder vielleicht noch eine weitere Podcast Folge zu dem Thema machen, ansonsten würde uns brennend interessieren, wie deine Erfahrungen, falls du da welche gesammelt hast sind. Was hattest du so für Erlebnisse, vielleicht auch witzige Fälle in Kombination mit
Anforderungen und. Dass beispielsweise komplett dran vorbei implementiert wurde, wie wir das erwähnt hatten, schreibt uns gerne, zum Beispiel auf der Podcast Mail oder auf den anderen Plattformen. Die Links sind wie immer in den Shownotes. Dort findest du alle und ansonsten würde es uns natürlich auch freuen, wenn du unseren
Podcast weiterempfehst. Falls er dir gefallen hat, so an mindestens 23 Freunde, das wäre super, um die Anforderungen mal konkret zu machen, wo jetzt war das Wort mindestens drin. Und ansonsten würde ich sagen, haben wir uns alle beim nächsten Mal wieder. N schönen Tag noch und bis dahin deine Coding Buddies gemeinsam. Besser.