Ich möchte heute was von meinem Betriebsort schaffen, es testpersiert,
wir perpieren den noch, erzählen. Mich treibt das Thema gerade ein bisschen ungerlich,
mich unter anderem an dem Buch Softwarequalität ist die Apelitenbecken beteiligt habe,
von dem ich eine der großen Fragen von Sebastian Blattmann und Stefan Triebsch,
die auch vorhin dieses Buch ist, war halt,
ja, jetzt wissen wir, wie gute Qualität gilt,
aber die Themen werden das eigentlich weiterverkauft.
Also so kriegen wir jemandem gesagt, dass wir gerne so handeln möchten.
Und anlässlich deshalb habe ich dann mal angefangen, das,
was ich doch mal so weiß und wie ich an diese Fragestellung fangen, die aufzuschreiben.
Und wenn man die aufgefangen hat, das aufzuschreiben,
dann fängt man auch an, darüber zu erzählen.
Manchmal ist die Reihenfolge andersrum. Also diesmal ein erstes Buch,
dann der Vortrag. Und ich bin da auch angewiesen,
dass ihr ganz viele Fragen stellt,
weil ich habe ja nur bestimmte Ideen mitgebracht.
Und wenn ihr das Gefühl habt, dann wolltet ihr mehr drüber wissen,
dann müsst ihr mal so ein bisschen reingrätschen, okay?
Sonst sind wir ja ganz schnell durch. Und ihr denkt,
okay, das war jetzt alles so angestupst, aber wie geht es eigentlich?
Da ich nicht genau weiß, wo eure Interessenlage ist,
fragt nach an den Stellen,
wo ihr denkt,
das war jetzt
irgendwie zu oberflächlich
Wenn ich, für die Dinge, die man nicht kennen,
ich bin du, die da im Lesen, ich bin Projektcoach.
Ich mag funktionierende Projekte. Und mir ist ziemlich egal,
ob da Strum kann man XP, unsere Projektmethode, CMMI,
Prinz, Tu, irgendwas draufstehen oder vielleicht auch gar nichts, Hauptsache es funktioniert.
Also wenn Leute ihren Spaß haben und gut liefern,
dann bin ich zufrieden und das ist das,
wo ich versuche zu helfen, dass man da hinkommt.
Für diese Präse gilt da unten, da gibt es immer mal so Dinger,
die man eigentlich lesen kann, das kann man später,
wenn man die Präse lachen liest, da kann man draufklicken,
da sind da links drauf, die irgendwie im Ball dafür eine Literatur geben.
Für diesen Vortrag will du, ich glaube,
hier muss ich das gar nicht mal so deutlich sagen,
aber es gibt immer mal die Situation,
dass mich ITler sitzen, das tut total weh,
das ist die unhöflichste Art einer Frau zu sagen,
dass sie alt geworden ist.
Also das geht echt nicht. Also bitte beim Stuhlbleiben.
Also ich fühle mich sonst echt scheiße an. Genau,
und wer das dazu twittern will, der gerne Judith Andresen,
da findet man mich Zwischenfragen, wie gesagt, gerne,
was ich hier nicht hinkriege, ist Sachen,
im Detail, also im Sinne von Coaching zu klären.
Also vielleicht sage ich dann mal an der einen oder anderen Stelle,
das können wir hinterher gerne noch bespenden,
aber man kriegt es ja nicht als bewusst.
So, fangen wir an dieser Vortrag. Also das erste ist,
was mir mehrfach begegnet ist, dass Leute sagen,
ich würde gerne testbasiert irgendwie oder Tests bestützt oder wie auch immer arbeiten,
aber jedenfalls mit vielen Tests.
Und dann sagt jemand, ehe Alltag, das ist ja
viel teurer als vorher. Oder das dauert viel länger.
Was willst du? War das vorher auch gut? Und
in dem Zusammenhang gibt es dann auch gerne den Vorwurf,
also wenn man sagt, ja,
ich würde gerne mit Tests arbeiten, ja wie,
habt ihr vorher eine Qualität und ohne Tests gearbeitet?
Und dann kommt man in so einem blöden Erklärungsmodus, wo man auch irgendwie ganz schlecht rauskommt.
Also schlechtes Gewissen und Dokutation und so. Und deswegen würde ich gerne,
dass ihr so ein bisschen Zahlen und Gutesten kennenlernt und vielleicht auch eine Argumentationshilfe,
wie man da durchkommt, aber bevor wir zur Frage kommen,
testen rechnet sich, würde ich gerne ein bisschen darüber sprechen,
warum man eigentlich testen möchte und warum das so eine gemeinsame Zielsetzung aufgeht.
Und außerdem kannte ich dabei euch noch erklären,
warum Ole hier so begeistert geschanken hat.
Also ich mache jetzt vielleicht ein bisschen Analyse von Ole
Oh, Alter. Und zwar, erzähl. Das wiederum hilft euch vielleicht,
aber auch euren Arbeitsalltag ein bisschen zu verstehen und auch zu verstehen,
an welchen Stellen es vielleicht noch hapert, was man da macht.
Du solltest öfter zusammen machen wahrscheinlich. Das habe ich
auch ja abgesprochen. Nee, ich war nicht.
Ich habe da hinten gesessen und gefipst.
Dass er hier so sich so gefreut hat.
Okay. Erste Aussage. Kein Manager kann motivieren.
Also es gibt so einen Mythos oder klassisch hierarchischen Managern,
dass man seine Leute nur motivieren muss,
sondern wird alles super
Also als würdest du Motivationspillen geben. Und es gibt auch noch die Ideen,
das ist eine Motivationsspille gibt, nämlich das ist Geld.
Also man hält jemandem so eine Möhre hin und sagt,
wenn du das machst,
dass du ganz viel Geld und beim stellen wir fest,
die Leute greifen das womöglich noch ab oder arbeiten total egoistisch auf dieses Ziel nimmt,
aber motiviert sind die immer noch nicht.
Sieht man mit dem HSV. Ja, deswegen. Das wäre möglich an
der Gültige Analyse, da weiß ich leider zu wenig.
Also kein Magics Verkamm motivieren, das funktioniert nicht.
Da gibt es auch große Untersuchungen drüber,
dass du gerade Geld gaben, einmalige,
viele einen kleinen Moment beglücken und dann ist das Villa weg.
Also das ist keine dauerhafte Motivation, sondern das ist mal
zwischendurch so Chaka und dann ist es halt wieder weg.
Aber mit einmal Chaka kriegt man halt nicht ein gutes,
qualitätsvolles Projekt hin. Also du willst nicht allen Managern absprechen,
dass sie auch anderes machen. Also ich, nein.
Der Erklärungsmodus. Der Erklärungsmodus mit dir. Wie meinst du
das? Also ich, ehrlich gesagt habe ich
die Frage nicht richtig verstanden
Ja, also Manager kann mich nie bei mir entscheiden zu.
Die Manager kann auch sein. Nein, im Manager kann.
Genau. Aber die klassisch viel irrakische alte Sicht funktioniert sehr stark
über Geld. Da gibt es dann in den 70ern,
kam jemand und sagte immer,
wir müssen mal über die gewissen Teams arbeiten und über Sinden reden.
So, da kamen so die erste Bewegung.
Die ist aber in dieser Managementtradition noch nicht sehr alt.
Also die agile ist noch jünger,
aber ich würde es mal fragen,
kann ein Manager mich motivieren oder kann er
eine Umgebung schaffen,
die motiviert
Ja, ja, ja. Das ist auch eine Umgebung
. Also ich glaube auch immer,
dass man nur noch Parameter schaffen kann, wieder zu führen,
dass Leute motiviert sind, aber dazu kommen wir später noch.
Was aber Manager in jeder Zeit schaffen kann, er kann demotivieren.
Also das kriegt jeder Manager sofort hin. Also da reicht manchmal
nur ein halber Satz. Und es gibt eine Erklärung,
warum das so ist,
Daniel Lage Pink hat eine ganz falsche Richtung geschrieben,
das heißt Drive,
what you really
monty ways
Und ich habe wahnsinnig stark an dieses Buch gedacht,
während ich, ohne da so spannend, weil man merkte,
da waren wir cashen und wirklich drippen dabei und um
uns zu erklären, was man KHP eigentlich cool ist.
Und man hat sich fragt,
wo das herkommt und warum ein Source eigentlich auch gut funktioniert,
dann sagt Daniel H. Thing, es gibt drei Faktoren,
die wichtig sind.
Das Ärzte ist, ich fange mal von unten an,
wir hören autonom handeln können in dem, was wir machen.
Also man braucht einen Bereich, in dem man so
sein Spielfeld hat und sein Ding machen kann.
Und das nächste ist, wir müssen Dinge tun,
in denen wir wirklich gut werden kann. Also ich weiß nicht,
wer von euch spielt eine Gitarre oder überhaupt ein Instrument?
Und wir erinnern uns alle an diesen Moment,
wo wir so bestimmte Griffe stundenlang geliebt haben.
So, da kriegt man kein Geld für, ne?
Aber man macht es trotzdem, man macht es für diesen Moment,
wo man merkt, ey, ich kann das jetzt.
Und das ist Masturbieren, das ist das, da kommt Leidenschaft hier.
Da bekommt Geisterung hier. Und eigentlich wünschen wir uns ja
auch ein Arbeitsgefeld, wo wir Mastery erinnern können.
Einfach gut sein in dem, was man macht.
Und dann braucht das, was wir tun, einen Sinn. Also irgendwas, so was wie,
also ich will natürlich die Welt besser machen mit dem,
was ich mache, weil ich Leuten ein Arbeitsumfeld besser machen möchte,
aber keine Ahnung, dass euer Sinn ist in dem,
was wir in der täglichen Arbeit spielt, Geld verdienen ist übrigens meiner Meinung nach keinen Sinn.
Also das muss halt irgendwas haben, wo er sagt,
das ist dann, daran glauben wir, da wollen wir hin.
Das ist uns wichtig. Und daraus leiten sich im Normalfall
auch die Geschäftszeele ab, sollten sie jedenfalls im besten Falle.
Und Wenn man da so drauf guckt und sich fragt,
wie ist das eigentlich in meinem Arbeitsumfeld,
dann wird das meistens relativ schnell ziemlich dünn für jemanden.
Also ich kenne nur wenige Firmen, die Mitarbeitern wirklich ein autonomes Spielfeld lassen.
Ich kenne wenig Unternehmen, die einem die Chance geben,
gut zu werden, in dem, was man eigentlich machen möchte.
Viele Leute lösen das,
indem sie gezielt Karriereaufstiege in andere Firmen machen, weil sie sehen,
dass sie da eine Chance haben, ein Stück zu wachsen.
Aber es ist selten, dass das Firmen in sich bürgen werden.
Und das Letzte ist, es gibt selten etwas,
wo Leute gemeinschaftlich wirklich dran glauben
Und die wesentliche Frage ist,
wenn ihr jetzt in einem Kontext seid, wo Softwareentdeckung macht,
nicht was allein geht, Ziel der Firma ist,
sondern wo es noch eine Marketingabteilung und andere Firmen gibt,
die haben ja genau dieselben Fragestellungen.
Die wollen gut sein in dem, was sie machen.
Die wollen besser werden in dem, was sie machen.
Sie wollen absolut handeln und sie glauben an etwas.
Und die große Frage ist, glaubt ihr an dasselbe?
Also wollt ihr dasselbe? Und wenn ihr das nicht
zusammen wollt, dann werdet ihr auch nicht zusammen in
dem Gut
Und dann ist das mit der Qualitätsgesicherten Arbeit,
auch relativ schwer zu erklären, weil womöglich hat jemand einen vollkommen anderes Ziel,
aus dem sich gar nicht ableiten lässt,
dass das jetzt Sinn machen würde, vernünftige,
gute Software zu bauen, was eure Mastery ist.
Also die Frage ist,
was teilt ihr gemeinschaftlich und was lässt sich daraus ableiten,
wie dann die Software hier laut aussehen muss.
Und das ist was anderes. Also es gibt manchmal diesen Selbstzweck
der guten Software. Also wir glauben alle ans Völlet,
wir haben eine Idee davon, wie man performant,
die sichere, schöne Systeme baut.
Das ist ein Selbstzweck in sich, das ist mastery in
der Softwareentwicklung
Aber wie sind die Mastery in einem Unternehmen aus,
das einen bestimmten Ziel folgt, das hier mit jemandem teilt?
Und da kommt womöglich etwas raus,
was nicht ganz so perfekt ist, alleine aus diesem Software-Blick fällt,
aber das in dem Kontext total richtig ist.
Seid ihr noch bei mir? Ja. Gut, ihr
seid so schnell. Ja, das war eine Frage.
Das war eine andere Frage. Okay, das war alles
nicht raus. Gut. Schweigen heißt zu stur.
Und ganz, ganz blöde Regeln. Sofort. Schweigendes Zustimmung
führt dazu, dass die Schüchternen sich nie melden werden
Schweigendes Zustimmung ist eine Regel,
explizit oder implizit in vielen Firmen gilt und die dazu führt,
dass bestimmte Leute nie zu Wort kommen.
Sofort abschaffen, sofort. Zu wegfüllen, das habe ich gelesen.
Ja, wie schön. Okay. Ich schreie auch nicht.
Also nach jedem zweiten, jawohl. Genau. So,
wenn man sich fragt, die teilt ihr das Ziel.
Also meine These ist ja, dass es leichter ist für einen Entwickler,
Geschäftssprache zu lernen, als für ein Business-Menschen, Entwicklungssprache.
Deswegen glaube ich, dass ihr das,
was ihr macht, in irgendwas übersetzen müsst,
was Geschäftssprache ist
Das ist jetzt meine persönliche These. Also wenn mir jemand
das Gegenteil beweist und mir den Weg erklärt,
wie das in seinem Unternehmen funktioniert, hat das quasi andersrum zu vermitteln.
Da habe ich so große Ohren. Meine Idee ist,
zu sagen, übersetzt das, was ihr an Themen
habt in Geschäftssprachen und dann habt ihr eine Idee davon.
Also dann könnt ihr euch irgendwie auch schon erst mal auf einem Maßnahmen-Niveau unterhalten,
dann aber auch, was ihr als Ziele erreichen wolltet.
Das ist etwas, was ihr teilen kann.
Das wäre ich jetzt nicht im Detail aus dem Nordpolen,
aber da gibt es eine ganz tolle mit Methode Atta.
Das habe ich hier schon mal erzählt.
Ich werde das so lange erzählen, dass das alle
von euch machen
Atham ist ein Weg,
technische Themen in fachliche Anforderungen zu übersetzen und das durchzupriorisieren.
Und dann kann man sich zusammen auf Szenarien einigen.
Und das, was man dabei schafft, ist,
technische Themen so zu übersetzen, dass das anfassbare Justkäses werden.
Das ist für viele Menschen im Marketing oder überhaupt nicht technischen Regionen
leichter zu fassen. Also ich kann das nur empfehlen,
sich da mal mit incentiv auseinanderzusetzen
Und das nächste, also wenn man das schon mal gemacht hat,
dann kann man sich auch noch mal fragen,
was können wir denn eigentlich für Risiken?
Und viele Projekte leben davon, dass Risikonalysen getrennt voneinander gemacht werden.
Also da werden die Teams mit alle ganz kleinen.
Also Marketing fragt sich, was schiefgehen kann. Der Vorstand fragt sich,
was schiefgehen kann, die Technikfazit, was schiefgehen kann.
Die QAF hat sich auch noch was hingehen kann.
Aber es fragt sich keiner zusammen. Und dann wird es
voraussichtlich an irgendeiner Schnittstelle knallen. Also insofern finde ich,
das lohnt sich und das ist jetzt, war der Ton,
also der der eigentliche Auftakt zur Zielsetzung mit Sinn und Verstand,
bevor ich zum Thema Testen rechne, dich kommt.
Und wenn man rauskriegen will, ob Testen sich gerade rechnen,
also es gibt, glaube ich, auch Umstände,
in denen eine stark qualitätsgesicherte Software, die über alle Ebenen,
die man so haben kann, abgesichert ist,
relativ wenig Sinn macht.
Also wenn man so eine Marketing-Ente rausknallt,
die nach zwei Wochen eh wieder runtergerockt wird,
dann muss man sich nur fragen,
wie ist die Last auf dem System in der Zeit und danach ist es auch Wumpe.
So, es sei denn,
man möchte das irgendwann mal wieder benutzen,
gehen nicht
Je nach Anwendungsfall nicht, wenn es die Frage ist,
wie viele Testen ich eigentlich machen muss, sehr unterschiedlich zu beantworten.
Und dafür braucht man vorneweg mal so ein paar Fragen.
Wenn ihr uns witzigerweise relativ selten unterhalten wart.
Also die erste Frage ist, worum geht es hier eigentlich?
Also was wollen wir eigentlich damit erreichen?
Und wenn man das hat, dann sollte man fragen,
wie lange wird denn das System voraussichtlich leben?
Die Antwort darauf ist normal verfalscht, weil das alle unterschätzen.
Also so ein Faktor zwei oder drei ist dann meistens realistisch
Es hilft manchmal auch, das Vorgänger vielleicht anzugucken.
Die leben meistens schon viel länger, als man glaubt,
dass sie ein Problem haben.
Und dann findet man halt mit einmal Pi-HP-Projekte im Ding VP-Kerne sind.
Wo komische Dinge passieren. Aber eigentlich alle nur wissen,
dass irgendwie VP-Kern-Variablen nach maximal vier Zeichen lang sein können.
Und man hat das dunkle Gefühl, man müsste das da drinnen
irgendwie mal ablösen. Weil man eigentlich auch keinen mehr hat,
der das macht, nicht anders. Und dann weiß man,
die Lebsauer war relativ lang und dann weiß man auch,
wenn man das jetzt neu baut, muss man es so bauen,
dass es dann unmöglich auch zehn oder 15 Jahre nicht.
Also, die einfache Schätzung mit einem guten Faktor versehen oder
mal gucken, wie lange das Vorgängerprojekt gelebt hat.
Da muss man sich fragen, wie wichtig sind uns eigentlich Sicherheit und Performance.
Bei Performance lohnt es sich, wenn man zumindest,
wenn man Selbstsysteme baut, sich da so typische Peaks anzugucken.
Also, da hat ja jeder so seinen eigenen Use-Case.
Wenn ich irgendwie Home-Delivery mache,
dann ist sicherlich die Halbzeitpause in der WM irgendwie mal ein Use-Case,
damit Weihnachten nicht so viel losweilen.
Andere sind dann halt drei Tage vor Weihnachten.
Das sind die Schuhpersender, die sind dann halt anders dran
Aber es lohnt sich da echt mal zu gucken,
für was man eigentlich baut. Und dann sollte man die
Frage bestellen, wie viel wollten wir eigentlich anpassen und erweitern?
Und viele sind sich nicht darüber am Gnaden,
wie viel Anpassungsdruck sie eigentlich haben. Also gerade,
wenn man so ein System hat, das du fünf,
sechs Jahre gelebt hattest, lohnt sich echt mal reinzugucken,
wie viel haben wir eigentlich released.
Was ist denn da eigentlich so angewachsen? Und das unterschätzen
auch viele. Also man redet halt den ganzen Tag über
Bugs und Ärger und dabei liefert man aber fröhlich Features aus.
Und das übersehen viele. Und das lohnt sich echt
darauf zu gucken, damit man dann für das Richtige arbeitet
Okay. Darum man hin möchte, schöne Studien drüber ist,
wenn man sich so Standardnormalentwickler anguckt,
dann möchte man eigentlich dahin,
dass der seinen Großteil der Zeit darin damit verbringt,
einfach coole neue Features zu bauen.
Also das ist halt produktive Zeit. Und ja, es wird
Bugfixing geben. Und ja, man hat auch noch interne Ansprachen.
Und das ist auch wichtig und das hat seinen Platt.
Aber da kommt man eigentlich hin. Hast du da
die ganzen Zwischenzeiten auch hin,
um so intern das zu machen
Switch-Falten wären für mich internes, ja. Und Switch-Zeiten ist ja
schon mal ein schönes Thema. Es gibt Studien darüber,
dass wir maximal zwei Aufgaben zurzeit gut handeln können,
danach eine Produktivität in einem Maße ab.
Das ist echt brutal. Ich weiß,
dass euer Arbeitsalltag oft anders ist, dass wir zwischen vier,
fünf, sechs Projekten hin und her springt.
Auch da lohnt es sich mal vorzurechnen,
wie viel Zeit man eigentlich verbrennt. Und für so Leute,
die, also bei vier Projekten weiß ich die Zahl,
da geht halt 25 Prozent der Zeit nur in Switchen
So, das ist ein teures Vergnügen. Das kann man
mal einen Mann tragen, ausrechnen, wenn man dann weiß,
wie viel Feature muss man pro Manntag im Schnitt baut.
Also da kann man halt mal ausrechnen, wie teuer das ist.
Das hilft meistens. Und im Normalfall lohnt sich dann
auch eine Umstrukturierung oder zumindest ein Arbeiten in Timewaxing.
Also man kann halt auch die Idee kommen, zu sagen,
wir machen jetzt mal drei Tage das und drei Tage haben wir das.
Ja, da muss jeder Einzelne darauf warten, bis er
wieder dran ist. Aber insgesamt werden die Teams dann produktiver.
Und das ist eine reine Prozessveränderung, das hat nichts mit
dem Inhalt zu tun,
sondern eine reine Prozessveränderung
Die dann im Normalfall auch dazu führt, dass Leute motivierter sind,
weil die haben natürlich in drei Tagen mehr Zeit,
Master Reality aufzubauen und da ihr Ding nur zu machen,
als wenn man gehetzt in zwei Stunden irgendwas zu uns ranfrigelt,
weiß,
das ist eigentlich nur so halb und es wird auch unter bestimmten Umständen umkippen,
die man eigentlich auch schon so halb kennt.
Und da lohnt es sich einfach mal vorzurechnen, zu sagen,
komm, lass uns das ändern. Okay,
wenn man sich jetzt anguckt, wie jetzt dann realistischerweise ist,
dann steigt man halt fest, die interne Zeit,
die nimmt schon viel Zeit. Es gibt auch viele,
bei denen das schon 20 Prozent sind,
Und dann stellt man halt fest,
die Zeit in die neue Plementierung von Features ist viel,
viel geringer, sondern wir verbringen einen Großteil unserer Zeit mit Backfixen.
Und hier ist eine Folie an der Fälscherstelle. Ich würde
jetzt einmal vorklicken, ob ich die üblich um einvertan habe.
Wo ist meine da? So. Das ist eine Untersuchung von
Barry, würden mich sehr empfehlen kann.
Er hat sich mal damit beschäftigt. Was kostet uns eigentlich
ein Backfix
Also... Und er hat halt sich angeguckt in lustigen Einheiten,
Manntagen, Euros, also Dollars, was Backfixing im relativ zur gesamten Projektzeit kosten.
Und das hat er durch diverse Studien durchgemacht, Megastudien,
sagte, rausgekriegt, kommt es halt raus,
wenn ich vorne bei den Fire-Mans einen Fehler gemacht habe,
okay, der verdoppelt halt echt die Zeit mäßig,
ich falle mir einfach Marschall an,
wenn ich das erst im laufenden Betrieb rauskriege,
verbrate ich das 1050 Kabeldessen.
Also, und wenn ich vorhin gesagt habe,
wir verbringen 30 bis 60 Prozent unserer Zeit im Backfixing,
Und dann rede ich im Normalfall von dem,
was da hinten ist.
Also vielleicht noch auf der Ebene der Tierremove bei den Akzeptanzteste oder
halt tatsächlich im Leichtsystem. Das ist ein teures Vergnügen.
Also da verbringt man halt richtig Zeit und Aufwand. So,
und ich finde, das ist schon relativ schnell zu rechnen.
Also das sagt halt, ich möchte hier vorne kommen.
Hier, da bin ich die Fehlerfetten.
Nicht dahinten. Kann ich mir die Zahlen suchen?
Nee. So. Ich kann mir... Das heißt,
wenn du das kritisierst, das ist aber ein Fehler,
der in dem Rekordland gemacht wurde
Nee, das sind relative Kosten für ein Bugfix,
warum auch immer der entschrankt ist.
Also das ist gerechnet auf einen Reflyer-Fehler. Das ist sozusagen
die Relation, die die bauen. Es kann aber auch sein,
dass Software halt eben so ein Seitenumfalldienst ist, das später auftaucht.
Aber es ist halt, die Idee ist,
wir haben halt versucht, mit Redaktion zu nehmen,
eine Qualität zu bauen, um überhaupt eine Bezugsgröße zu haben.
Und haben dann halt sich angeguckt, was kostet uns das Spaß?
Und da kriegst du halt raus, wie später ich in
der Kette bin, dass du härter ist es.
Und das ist halt exponentiell, ist da der Kneipe.
Aber ähnliches war eigentlich, ist doch eher so,
in den letzten Minuten Fehler, die Brick Waititz ist,
und dann das erst zum Schluss wäre, Das ist am teuersten.
Genau, also das geht jetzt davon aus, hier wird er gefixt,
dann habe ich die doppelte Zeit, also ne?
Achso, der Bull kann nicht erst entwickeln. Ja. Sondern wenn ich den Fehler hier aufdecke,
kostet mich das einmal in die Zeit,
wenn ich den hier mache, dann schon fünfmal,
weil ich dann halt, dann muss ich den zurückgeben,
dann müssen die mir überqualmationell gebaut werden und ich muss die Abhängigkeiten rauskriegen und je später ich einen Fehler finde,
desto mehr Abhängigkeiten habe ich mit zu lösen.
Also wo auch immer die sind,
in der Fachlichkeit deiner Technikperson, auf der technischen Seite,
aber es wird halt immer härter und es wird,
also ist ja offensichtlich explizit.
Also insofern Lohnt es sich, Bugs früh zu finden?
Lass mich schon wieder zurück. So, was sind eigentlich
Bugs? Also Fehler. Fehler sind negativer Beitrag zum Geschäftsführer,
weil ich verbringe Entwicklerzeit damit, Dinge zu lösen, die eigentlich gelöst sein sollten.
Also das ist irgendwie kontraproduktiv. Und das,
was uns guten fällt, sind irgendwie Zeit da reinzubringen,
neue Features zu bauen in die Energie, was zu machen,
neue Produktion zu bauen, ist das irgendwas Gutes?
Das andere muss auch gemacht werden, aber das zählt erstmal
gegen die Zeit
Und das Ganze gibt es noch im Unsichtbaren,
dann bin ich so Grundlagenfostionen, die man mal bauen muss.
Also, das ist ja halt auch eine Form von Funktionellität.
Und auf der anderen Seite gibt es technische Schulden, die man aufbauen kann.
Also etwas, was nicht gut gelöst ist,
das wahlweise zur Komplexität in der Anwendung führt, die es schwerer macht,
die zu bearbeiten im Hund oder später irgendwann mal zu Fehlern führen wird.
In Diskussionen beim Business, es ist so,
dass die immer am besten diesen Teil hier sehen.
Also, man kann gut mit Managern darüber sprechen,
auch mit Produktwinittern, mit fachlichen Anforderungen, Performern,
die funktionieren eigentlich die Funktionen im Guten
Deren Erwartung, dass man möglichst keine Fehler macht, also, ne?
Und das, was hier in dem Unsichtbaren teilt, passiert,
ist relativ schwer zu greifen. Ich kann da nur empfehlen,
dass tatsächlich mal so als Matrix hin zu malen und jemandem
zu erklären, was eigentlich euer Job ist. Also,
ihr wollt Fehler vermeiden, wenn ihr Fehler vermeiden wollt,
wollt ihr eigentlich auch technische Schulden vermeiden,
weil die erhöhen die Gefahren der Fehler danach.
Und es hilft, dass man zumalen Grund,
jemandem zu erklären, ganz konkret in seinem Projekt,
was das eigentlich heißt
Also, weil das, ich kann nur darüber etwas sprechen,
was der andere auch versteht. Und das ist,
also gerade wie der Begriff technische Schulden,
und über den reden wir ja ganz häufig,
also Qualitätssicherung ist auch ein Weg, technische Schulden zu minimieren.
Das muss man halt mal klarmachen und auch an Weite,
die aus der Vergangenheit klammern.
Das ist ganz wichtig. Und es ist ein Riesenproblem,
was du auf dem Kreuz, und gerade der Grafiker,
das links, oben rechts, aus der Zusammenhänge,
wenn du von außen auffährst.
Dass Leute die technischen Schulden verlassen trotzdem
Vier neue Peters und wo ich heilkrank werde,
wo ich genauso die vielleicht mal so verstrickt von,
wo auch nichts unten gegangen sind,
für die zehn Prozent dort wieder mag, hätte umgehoben.
Klar, also ich habe das ja schon mal extra hellgrün überlegt,
weil das das ist, was man am ersten wahrnimmt,
also auch als positiven Beitrag und als guten Entwickler, die,
die darüber reden, dass wir erstmal die Verhinderer und die Nein-Saga.
So. Umso wichtiger ist es klar zu machen,
dass das im Sinne eines gemeinschaftlichen Geschäftsziels genau das Richtige ist, darüber nachzudenken.
Also zu sagen, wenn ich mich darum nicht kümmere,
dann werden wir die acht Jahre,
die wir uns vorgenommen haben,
einfach nicht durchhalten
So. Und da hilft es halt tatsächlich mit Beispiel,
also jeder kennt diese War Stories,
also wenn man so ein richtig beknacktes Ding,
so nach zwei Jahren auch gefallen ist und dann haben die Sauer im Geschehen gestanden.
Also jeder hat so ein Ding in Kantur. Sollen wir
das nochmal raus und erklärt das mit dieser Matrix und sagt,
das wollen wir nicht nochmal.
Deswegen müssen wir uns darum kümmern. Was relativ klar ist,
in diesem ganzen Verfahren bleibt dabei nicht technisch,
gerade mit dem Business, echte Effizienzgewinne sind immer ein Prozesspunkt,
also überhaupt zu suchen und nicht am Technischen Detail
Also wenn ihr über Qualitätssichernde Maßnahmen nachdenkt, dann fragt euch,
wie er das im Prinzip löst und was jeder,
was sie als Prozess anstoßt, auch vielleicht interdisziplinär.
Und das löst euch mehr Probleme, als wenn ihr versucht,
im Kleinen irgendwie rauszufringeln, damit umzugehen.
Macht das mit Blick dabei auf die Bugs mit technischen Schulden zu lösen.
Und dann in dem Zusammenhang noch einen Hinweis, damit das schon,
also das alles mache ich getrieben von dem agilen Gedanken,
nicht,
dass Businessleute und Developer
jeden Tag zusammenarbeiten sollen
Das tun wir selten. Wir bauen die Mastery in unserem Bereich auf,
also ein Marketing-Mensch versucht, sein Ding durchzuziehen,
seine Kampagnen durchzudrücken, seine Zahlen zu kriegen.
Und ihr versucht, euer Code möglichst gut zu bauen.
Das ist Mastery der eigenen Disziplin. Es ist kein Gemeinsames
. Und hier steht aber was anderes. Hier steht,
macht es zusammen. Und dann findet ihr zusammen draus,
wie das funktioniert. Da muss man sich als nächstes fragen,
wie funktioniert eigentlich angemessen Testen?
Und da kann man halt von der Eintrag in Klasse
hochgehen müssen,
die Geschäftsprozesse
Und da kann man sich fragen,
wie viel Zeit ist eigentlich auch unser geschäftliches Ziel ein?
Und dann gibt es so ein paar No-Brainer,
also relativ leicht zu testen und einen hohen Geschäftswert,
den nehmen wir schon mal mit.
So, dann kann man sich sicherlich auch um eine
niedrige Komplexität und mittleren Geschäftswerts kümmern.
Dann sollte man sich bei hoher Komplexität und hohem Geschäftswert fragen,
wie weit testen wir das wirklich automatisch ab,
bis wo rechnet sich das noch
Also was verhindere ich hier gerade? Ich erinnere noch mal die gemeinschaftliche Risikoanalyse,
da noch mal drauf zu gucken, um sich zu fragen,
wenn das jetzt schnallt, was passiert uns eigentlich?
Und kriegen wir das mit einem akzeptablen Aufwand
durch Test abgesichert oder ist nicht eher die Frage,
wie eher eine gute Gegenmaßnahme im Risikofall haben?
Und das ist eine Frage, die muss man zusammen beantworten.
Also das nicht zu testen heißt, ja,
ich riskiere im hohen Geschäftswert, aber gleichzeitig weiß ich halt,
es tritt wahrscheinlich nicht so häufig auf.
Und was ist dann eigentlich das Richtige? Und das,
da kommt man wieder auf diese Grundwagen zu,
Da gesteht das System eigentlich, was müsstest du eigentlich ausheilen?
Und wie groß ist das Risiko, dass ich eigentlich gehen kann?
Das ist eine Frage, die könnt ihr nur zusammen beantworten.
Aus Developer-Sicht, also das war eine Entwicklungssicht,
macht es Sinn, möglichst viel davon vollständig abzutesten?
Dann seid ihr tot. Dann seid ihr zufrieden.
Aber die Frage ist halt, ist es das,
was bei zusammen nach vorne geht?
Also an der Stelle, es gilt einfaches Rechnen.
Risikoanalyse gegenhalten und dann weiß man,
was man möchte und macht es bitte zusammen
Und in diesem Sinne wünsche ich euch viel Erfolg und für alle die,
die es nochmal genauer darleben wollen, ich verstehe einfach auch mit dem Buff da.
Okay. Danke. Ich möchte nur sagen, und zwar,
ich glaube, der ganze Kamm ist der Wert zwischen dem
Akzept oder dem Akzeptanztest oder du hast ein bisschen blöd,
als das Environment nicht klar ist, ist so,
ja, wenn man hey, die Füße,
die Adresse,
aber eigentlich ist viel wichtiger,
die Akzeptanz
Testgeschichte aus unseren Kindern und Laufen, wie auch immer.
Schöne Geschichten in den Zweifeln, einmal auf der Ebene.
Ich habe eine Spezifikation gegessen, was ist eigentlich gut, was ich darüber anbaue.
Wenn es da erobern sitzt, merke ich, das ist krass,
das kaputt geht und einfach runter, egal, ist dann nur eine Sprache. Das Zweite ist,
dass die, wenn man diese Akzeptanzkriterien richtig ausstellt,
das heißt, auch polarot hat,
das war ja wieder nur auf dem Projekt, denjenigen Zusammenhang,
und wird dem den Hundemoment im Betrag viel planen,
was er eigentlich haben will, weil meistens ist das so nicht,
ich will das da, aber er weiß,
dass reiche Schaden aus der Armee und der,
wenn er Spezifizierung sendet, ich in meiner Armsatzung zu überbrechen will,
so auch extrem.
Und 5, ein Bild, dann soll da der 3 rauskommen.
Und dann muss er das einmal komplett durchdenken und wird ihm
dann auch da oben reingebracht. Und das ist auch genau diese Profi,
die du hattest, weil wir arbeiten nämlich total viel,
ganz schnell am Anfang da, was wir wirklich eigentlich hatten.
Deswegen habt ihr da auch gleich noch einen Chaos in Produktion,
Es war noch keiner verwendet,
aber andere haben Max da und alle hexen geseatured,
aber eigentlich verwendet es ja keine Ahnung, was das ist.
Ja, genau. Frühauffahrung. Also ich glaube,
wenn man an das Prozessverbesserung ganz oft,
der eigentliche Schlüssel zu einem Effizienzgewinn sind und gerade der wechselt auf,
das testen auch Akzeptanz-Ebene, führt dazu,
dass man sehr gut Business integrieren kann.
Ich habe mehrere Projekte, wo Leute ernsthaft mit Göttin arbeiten.
Das führt automatisch dazu, dass die User-Stories kleiner werden,
also weil man das dann ja selbst formulieren muss,
was man abzutesten hat aus Business-Sicht.
Die werden viel klarer dabei, beide Seiten,
die sind genauer in dem,
was sie tun
Verstehen ihre Probleme viel mehr, da kommen,
ich sag mal, verdaulichere Happen bei raus.
Also insofern ist das ein toller Protest. Es braucht manchmal
ein bisschen, um das anzuzuschieben, weil sie gerade,
also dieses Leben in Börg ist ja erstmal sehr formal, so.
Und ich habe dann auch schon arme Manager gesehen,
die dann zum ersten Mal von den Geclips ausgesetzt werden,
wie jemand sagt, hier sind diese ganzen Copy- und Case-Dinger drin.
Und das schiebst du da so rein und die sagen natürlich,
was ist das denn? Warum nehmen die Clips natürlich,
damit man es auschecken kann und dann das,
was automatisch an Tests daraus gebaut werden kann,
gleich durchzubauen?
Das ist natürlich
eine coole Sache
Dann dazu, dass man da ein neues Tool noch mal einführen muss.
Hilft aber ungemein, weil es Business und Development viel, viel nehereinander bringt.
Und ich habe in diesen Prozessen auch häufiger erlebt,
dass man auch einfach Features viel kleiner bleiben, viel schlanker werden,
viel klarer werden und diese Folgen brauchen wir das eigentlich.
Viel häufiger gestellt wird. Also das fokussiert alle Beteiligten und bringt Leute dazu,
eine gemeinschaftliche Mastery,
nämlich eine Mastery für ihr Produkt zu entwickeln und nicht ein,
ich brauche hier 23.000 Features aus fachlicher Sicht und
ich brauche hier goldene Locken aus technischer Licht
Also ich finde, das ist ein ganz starkes Instrument,
um sehr unterschiedliche Disziplinen zueinander zu bringen.
Der Weg dahin ist zum Anfang schwer. Also weil beide
Seiten nicht so richtig wissen, wovon sie eigentlich reden.
Also da fangen halt Leute an, so eine Geschäftssprache rauszubrüllen
und etwas, die so ein Features brauchen.
Man denkt so, was ist das denn jetzt?
Und umgekehrt ist man jemandem sagt, also du musst jetzt
ein Szenario aufbauen und sagen, auf welcher Seite du dich findest.
Und dann sagt er dir, wieso,
ich will einfach, dass es geht, so.
Und das braucht ein bisschen, dass die beideneinander sind.
Aber wenn sie da sind, dann macht es echt Spaß.
Und wenn man dann noch seine Testumgebung schnell genug gebaut hat,
das ist dann nämlich, also diese Also Bihead hat ein paar,
es gibt da so an der einen Wartenanstelle ein bisschen Schwierigkeiten,
dass man das schnell zum Rennspiel, ich glaube,
wenn man es hingekriegt hat, dass das dann auch vernünftig schnell durchläuft,
wenn es integriert, dann macht es Spaß.
Ja, dann soll das ja auch bei uns sein. Das ist ja,
wenn die wachsenden Menschen fest, aber das Gleiche,
je später ich bekannt habe,
das einführe oder gehe ich wieder in ein Wankletse oder gehe vielleicht ein automatisierter Akzeptanz,
erst arm und hüllt, dass immer schwere Leute,
das haben wir und was auch sehr selbstauflich gemacht haben.
Genau, und es gibt ja erstmal so einen Drang,
dann alles in die Akzeptanz, Tests zu schieben,
weil alles toll finden, dann kriegt man irgendwann raus,
oh scheiße, Da fange ich halt irgendwie wild intimieren.
Kommen wir zu, brauchen jetzt erstmal zehn Minuten, bis was zusammenkommt.
Das ist ja keine Arbeitsumgebung, da muss man sich
halt einigen. Was packen wir eigentlich in die Unit-Tests?
Also was ist ein Test, der auf Unit-Lite-Tests-Ebene einfach reicht?
Und was ist tatsächlich eine Akzeptanz für Themen,
dass sich auf der Ebene prüfen möchte.
Aber das ist natürlich auch ein Lernweg für Beisein.
Womit wir jetzt stehen oder nicht persönlich sind, in meinen Augen.
Das sind Leute, die sehen außen im Bereich dann wenig Technisches,
die über tieferliche Themen heruntergearbeitet haben und uns zwischenzeitlich immer verfolgt haben.
So klassisch die Late-Ops-Mentalität, ich habe die Leute aus dem Bereich Operations,
in dem Team mit drin sitzt und hat dann abgesucht,
zwei Welten, die leider dazu übersetzen.
Das kann, weil bei der initialen Annäherung, unheimlich hilfreich sein,
der kann ja auch noch mal Zeit mit aus dem Team verschwinden,
weil die Leute irgendwie gelernt haben, miteinander zu sprechen.
Das kam gerade von der Größenkarte, die wunderbar funktionieren.
Also ich habe es auch oft erlebt, dass es total hilft,
gerade bei Relaunches von Systemen wissen ja ganz viele Leute nicht,
was eigentlich drin ist.
Also ich weiß nicht, ob ihr dieses Problem kennt,
man hat irgendwie eine Software jetzt über sechs oder acht Jahre gewachsen.
Irgendwann hat mal irgendeiner aufgehört zu dokumentieren, fachliche Anforderungen,
stehen womöglich in irgendwelchen Tickets, aber vielleicht auch in irgendwelchen Mehlen von Mitarbeitern,
die schon gegangen sind.
So eigentlich weiß man gar nicht,
was das kann
So. Und da muss man halt jetzt irgendwie anfangen.
Und da gilt es total, Teams zu bauen, wie die Antwort aufnehmen.
Und da nicht klassisch vorzugehen und zu sagen,
da schreibt man lieber die Anforderung auf,
da ist der Finger relativ schnell da zu sagen, ja,
da soll ein bisschen mal aufschreiben, was die wollen.
Und das bauen wir da genau. Tatsächlich hat da ein Softwareentwickler einen echten Vorteil,
weil da kann man einen Code gucken, kann sagen,
das, was wir hier gerade, warum steht hier drin,
aber ich hacke hier noch einen Fall mehr.
Und an der Stelle den Interdiszipten leere Teams zu bauen,
die zusammen Akzeptanzkriterien aufschreiben, das ist ein echt cooles Ding.
Und das kann ein ganz toller Start,
ein sehr ein Quiz und gutes,
interdisziplinäres Vorgehen sein
Die brauchen auch so ein bisschen, bis die beideneinander sind.
So. Aber dann ist es echt cool. Und dann kann
man halt möglichst breit Leute zusammenführen. Und die haben hinterher
dann auch ein Produkt, denn das ist ihr Produkt,
das sie beschrieben haben, das sie haben wollen.
Und dann bauen sie auch zusammen was und dann passen sie auch wieder.
Wir wissen ja alle, dass Bug und Fieldshot,
das sind gewisse inneren Revolutionsspielraum, in irgendeinem Problem ausdrücken.
Weil ja auch die Koschieden eineinhalb Geld ist.
Und du würdest auch gerne bestimmen, wenn dieser menschliche Faktor,
wie würdest du damit dazu umgeben
Also, ich glaube, deine Frage ist irgendwie im Dienstleisterverhältnis zu interpretieren. Also im Unternehmen,
genau, also in einem Unternehmen würde ich halt sagen,
da gibt es halt nicht die Seite, die auf dem Weg ist.
Ja, das Unternehmen ist das Plau, ja. Ich meine,
jetzt irgendeine Dienstleistung für Gegenweiten ab VG und ja,
eben auch, wenn das Geld hat, die bemüht,
dass man richtig die Geldausgabe zu ziminimieren,
die Leute untersuchen, viel Schuss als Backzielen konvertieren.
Also, ich glaube, da hilft mir Haltung gerade rück,
gerade Rücken und sehr deutlich zu formulieren,
mein Verständnis ist Folgendes und...
Jetzt soll der Backe zu Beatle
Ja, aber an der Stelle, also was ja Leute versuchen,
dann so einen großen Druck aufzubauen, zu sagen,
wenn sie das nicht machen, dann suche ich mir den Nächsten,
dann kann ich nur sagen, ja, dann mach das.
Also ich bin nicht erpressbar. Und in meinem Verständnis
haben wir folgende Dinge vereinbart und das habe ich gebaut.
Und wenn ihr Verständnis ein anderes ist,
dann müssen wir jetzt irgendwie gucken, dass wir zusammenkommen,
können sie nochmal ihren Standpunkt genau auseinanderpoolen.
Und wenn der wirklich darauf beharrt und diese Geldkarte so zieht,
dann würde ich mich immer fragen, ist das der richtige Kunde?
Also wir sind Menschen und wir wollen,
glaube ich, Spaß an dem haben.
Wir wollen coole Sachen machen
Also ich finde, es hat keiner das Recht,
einen in der Form nicht wertzuschätzen,
nicht anzunehmen und zu versuchen, an der Stelle so zu drücken.
Ich finde, da hat keiner das Recht. Und wenn sich jemand so verhält,
dann muss man sich halt fragen, ob man an der Stelle richtig ist.
Und wenn man das im Kopf hat,
also nicht damit droht, sondern das im Kopf hat,
dann kriegt man die Schultern durchgedrückt und sagt,
egal was wir nicht schriftlich vereinbart haben,
mein Verständnis unserer mündlichen Vereinbarung oder das, was wir gemacht haben,
ist genau das, was hier drinnen steht oder ungefähr das,
was hier drinnen steht.
Und da muss man halt gucken,
wie man zueinander kommt
Und wenn man mal wissen will, so gesehen lasten,
dass wir jetzt ein bisschen so ein Lastenheft, Pflichtenheft,
Problem gewesen. Und allgemein fangen wir an,
welche Anforderungen so gesehen eher für trotzdem sind und wer ein Lühnentest ist,
dem empfehle ich Software Engineering einzelne HW,
ruinen und Handstudier, da waren wir eigentlich ziemlich genau.
Also eine nähere Aufschlüsselung dessen, was in dem Vortrag ist,
ganz, ganz kurz so.
Also es gibt ja auch immer noch was zu hören.
Also kann man das empfehlen. Genau,
also wenn man schriftlich hat, dann hat man da eine Chance,
das Problem bei vielen Anforderungen ist ja,
dass es immer dieses Ungesagte gibt
Wo man hinterher auch denkt, am Mist,
da hätte ich auch selbst drauf kommen können.
Und an der Stelle kriegen wir ganz schnell ein schlechtes Gewissen.
Und dieses schlechte Gewissen versuchen, andere Leute zu monetarisieren.
Und ganz ehrlich, die müssen aber ein genauso schlechtes Gewissen haben,
weil die haben es auch nicht gesagt. Und ich finde,
das offen zu legen und dann zu sagen,
wir kommen jetzt zusammen, wir sind ja beide nicht drauf gekommen,
aber sie haben recht, die Idee ist eigentlich gut.
Dann kann man halt gucken. Also ich finde halt diese impliziten Erwartungen,
was man hätte tun können,
wenn man ein bisschen drüber nachgedacht hätte, ja,
dann hätte er auch auf die andere Seite nachdenken können.
Also das ist ja nicht
eine Einwandstraße
Ja, weißt du, was ich meine, wenn man
geholfen hat? Also. Aber ich bin zur Kommunikation,
Matze, dann machen wir auch viel zu einfach,
weil auch so ein Stück des Weges gehen und da auch zu weg inkompliziert werden.
Ja, klar. Wo du so lange hin willst,
bin ich ein bisschen stammig und in zwei Wochen kann ich immer noch drüber nachgedacht haben,
wo sagen, ja, eigentlich mache ich das aber anders.
Jetzt muss ich uns gehen, weil ich es genauso als nicht so gut funktioniert,
dann meinte ich es doch ein bisschen anders.
Aber mir war das ja klar,
also das klingt ja genau dieses Werkzeug, dass du sagst so,
ja, dann lass uns jetzt selbst,
muss der Weg uns nicht mal sagen, ja,
wie würdest du jetzt gefangen, auch was aufzuschreiben,
sondern sagst mir einfach,
ja,
lass uns doch mal eben
einen Kurs
Und zehn Minuten noch mal in dieser drei Schritte, du handelst auf beiden.
Weil dann hast du, ah, was Schrittliches, da kann derjenige,
der auch genug in den Norderschlupf runterköpfen will, ins Leben raus.
Und Beas war die Absicherung, dass er auch wirklich das,
was er gemeint hat, dann auch wirklich explizit genannt hat,
wenn wir wahrscheinlich das gleiche Mannschaften von 19 Prozent haben.
Und wenn man genau in so einer Verfahrnung auch fair ist,
also sagt, manchmal ist es ja auch so,
dass wir eine Fitscheranfrau bekommen,
die auch berechtigt ist und dann sagt, ja,
schlimm, hätte ich eigentlich machen sollen.
Also wenn man an der Stelle auch mal sagt,
also nicht Dinge zu sagen Vorteil ausnutzt,
sondern an der Stelle fair ist,
dann kommt man meistens auch mit einem
auch wieder fairness begegnen
Also ich habe es erlebt mit Kunden, wo ich so,
ich schreibe ganz viel handschriftlich auf, wo ich was aufgeschrieben habe.
Und ich habe es halt hinterher nicht in ein Leben fixiert.
Und wir haben es halt so gebaut. Und das war nicht so,
wie der Kunde sich das vorgestellt hat,
wo ich dann aber gesagt habe, aber hier steht es in meinem Buch,
ich habe es so aufgeschrieben, dann sagt er,
okay, haben Sie offensichtlich so verstanden,
dann ist das jetzt so, das glaube ich Ihnen.
Also und das ist halt, also meine handschriftlichen Notizen sind
überhaupt nicht rechtssicher. Aber wenn man diese Formen der Fairness,
diese Offenheit und dieses, wir wollen auch gemeinschaftlich wohin erreichen,
dann gelten auch irgendwann
handschriftliche Notizen
Aber dafür muss man an der richtigen Stelle auch sagen,
da haben wir jetzt einen Bock geschossen, den kriegen sie jetzt, ne?
So, können sie sich jetzt drüber freuen. So,
dann hat sie sich nur so eingekillt,
wenn man so ein bisschen verhieß, auch in der Situation,
dass meine Kunden halt gut strukturiert sind.
Und einfach fragen nicht mal am Morgen.
Herr Lage oder sowas. Der eine oder andere mag das
schon mal gehört haben. Oder ganz schlimm sind auch Leute,
die so ihr eigenes Projekt auf die Bahn bestellen.
Du hast doch völliger noch einen Anspruch. Das einzige,
was hilft, eigentlich sind die reif, da hättest du
nichts zu sehen oder so. Da hast du aber auch Projekte,
weil du früh mal so ein Einzelteam und die musst du
gleich klären und dann Letztlich kann man lernen,
wie man das auch klärt zu lassen.
Genau. Also ich habe beide Dinge angesprochen, zwei Software-Prozesse vom Moverlandesgericht.
Bei dem Grund, wobei zwei Kunden, die wilder waren,
kann man dann rechtsfettig zu Mover mittlerweile rauchen.
Aber das ist genau, wenn ich als Dienstleister darf,
dann habe ich ihm keinen Dreck,
der eigentlich diese Rolle irgendwie mal ausfüllen kann.
Das ist das Problem. Also ich finde,
da muss man auch an der Stelle,
muss man auch sehr bewusst mit seinen eigenen Hoffnungen umgehen.
Also wir neigen dazu, Projektkrise nicht sehen zu wollen
Also der Bauch sagt relativ früh, hier läuft gerade mal
schief und hier ist ehemalig klar in dem, was er macht.
Und dann hofft man irgendwie, wenn man jetzt erst mal
das macht, dann kommen wir schon da durch.
Und das ist so eine Kette von Selbstwilligung.
Und eigentlich ist in der Projektkrise immer die Frage zu stellen,
brechen wir jetzt ab, weil es nicht funktioniert?
Oder was müssen wir ändern, damit es besser funktioniert?
Und wir hoffen auch, dass es besser wird.
Und das ist meistens auch der bequemere Weg zu hoffen.
Und damit wird das Problem nur größer. Und ich kann
dazu nur auffordern, wenn der Bauch sagt, ich glaube,
wir haben eine Krise,
man hört den Bauchzug
Ja, kann der Kopf fünfmal sagen, nee, das ist hier alles,
also wir müssen nur das machen und damit ist hier alles super,
hört nicht auf den Kopf, hört auf den Bauch,
da weiß das besser.
Und dann muss man halt den zweiten Teil auch mal früh aussteigen und sagen,
unter diesen Bedingungen rede ich nicht alles zurück, auf null,
Kunden zur Passmotte und Analyse einladen und also bei mein gutes
Verhältnis hat und über Neustart nachdenken oder intern die Postmordlunganalyse machen,
um rauszukriegen, wie man unmöglich beim nächsten Mal nicht wieder in Synäk reinhilft.
Noch konkurrete Fragen, muss ich sagen, ich glaube,
muss ich noch ein bisschen wieder,
vielleicht auch, kann man beim Bierchen
Es soll ja Ernsthaft, Entscheidungsträger geben, die in der Ansicht sind,
und nicht zu weniger Max, wenn du ein Projekt hast.
Weißt du da irgendwelchen Plasttformen verhalten sind? Es gibt eine Microsoft-Studie,
die deutlich nachgelesen hat, auch eine Quertien-Studie,
diverse Projekte und verschiedene Sprachen, die deutlich gezeigt hat,
dass sich die Softwarequalität durch Hundentests signifikant heben lässt.
Da ist der entsprechende Hinweis in dem Buch drin,
das ich dafür gezeigt habe. Und sonst muss ich,
ich kann es auch nochmal rauspulen,
also da gibt es einen Hinweis auf die Spiele,
das ist so ein, ich weiß nicht,
so ein 20-Seiter,
das sehr interessant zu lesen
Ansonsten auch einfach mal aufs Solardrübe da kommen,
suchen da mal ganz gut sehr viel Zeug dazu,
also auf das Wasser laufen die ganzen Schulen vermeiden für die Liegen und so.
Aber man kann nachweisen, selbst was, die fliegt schon
im Hunde-Test, architektonisch Kurseneinfluss haben. Also ist klar,
es gibt halt Sachen, die kann man nicht testen,
dann fängt man an, irgendwas zu bauen,
was testen kann und das hat halt schon signifikant Einfluss darauf,
dass Architektur besser ist.
Also auch die Studien gibt es, ich meine,
es ist auch irgendwie klar, so.
Ja, genau. Dann weiß ich,
viele Abhängigkeiten seiner Klasse hat, dann wird das mit
dem Test noch kompliziert so
Also sortiert man mal ein bisschen, zack,
jetzt gibt es auch ein Beständnis aus.
Gut, dann würde ich sagen, danke an Jübel,
Sajan Ode, dann kann er euch.