Weil es ist ja nicht so. Du kommst in den ersten Tag
irgendwo in nen Team. Was macht dir XY alles klar?
Bin dabei, gib her wo IDI, ja ich hab meinen Rechner schon
mit, der ist schon, dass da schon alles eingerichtet, wir
können loslegen Coding Body Deinem Podcast rund um
Softwareentwicklung und aktueller Technews.
Herzlich Willkommen. Was?
Einen wunderschönen guten Tag und herzlich Willkommen zur
neuen Folge vom Coding Buddies Podcast.
Es geht wieder los, wir sind wieder bereit, wir sind wieder
da. Oh ja, Tino und ich, Tino, grüß
dich. Grüß dich, fabi.
Was geht ab? Alles gut bei dir?
Ja, ich würde sagen, es geht mal wieder los.
Es ist wieder Zeit. Oh ja, oh ja, wir sind jetzt
auch glaube ich, langsam schon ganz cool gestartet ins Jahr
oder so, wir sind wieder richtig drin.
Ja, das Jahr läuft schon wieder. Also eigentlich ist ja 2024
jeder hat das schon jetzt schreiend geschrieben.
Ja, also weißt du dieses typische Nein, aber dieses
typische, so das erste Datum was du im Jahr schreibst ist das
Jahr vom letzten Jahr. Weißt du also sozusagen sowas
wie 7.1. 23 nein, Scheiße. Ich finde das auch eine super
gewöhnungssache, dann erstmal sich wieder ins neue Jahr zu
gewöhnen beim Schreiben, da hast du recht, das geht mir wirklich
immer so, ist total abgefahren, aber wahrscheinlich nicht nur
mir so. Kleiner Tipp von mehreren Leuten
muss. Dir im Dezember schon ganz oft
das Jahr, also die Zahl vom nächsten Jahr sagen.
Du musst es schon verinnerlichen und dann läuft wie.
Soll das aussehen, dass man dann irgendwie durch die Straßen geht
und mit jedem, dem man spricht, sagt?
Ach übrigens, das ist bei 2024. Nein, du stellst dich in den
Garten und schreist ganz laut 2020 100 mal.
Ich hab keinen Garten. Na ja, gut, OK, dann mach ich
halt Schreibfehler auch kein Thema.
Schreis aufs Fenster? Nein, keine Ahnung.
Merk es dir. Ja, merk dir einfach so.
Wir haben 2024 los geht es, erzähl mal, was ist denn das
Thema? Du hast doch was mitgebracht.
Ja, wir wollen mal wieder eine Folge machen, und zwar eine
Mythos oder Faktfolge. Oh yeah, das war cool letztes.
Mal. Ja, und da hab ich jetzt mal
eine Aussage mitgebracht. Aussage soll einfach heißen,
wenn du mehr Leute in ein Projekt steckst, dann ist die
Entwicklung der Software, die du sozusagen entwickelst,
schneller. Mehr Leute, schnellere
Entwicklung quasi. Also.
Mehr Softwareentwickler beziehungsweise mehr
Softwareentwicklerin heißt auch gleichzeitig, ist quasi
äquivalent zu einer schnelleren Entwicklung dieser Software.
Ne, das ist quasi sozusagen das Thema, über das wir uns einmal
ganz kurz ein bisschen unterhalten wollen in einer
Mythos oder Fun Folge und dann halt mal gucken, ist das jetzt
ein Mythos oder ist das ein harter Fakt?
Was sagst du dazu? Was?
Wie könnten. Wir an die Sache rangehen.
Naja gut, also im Prinzip kann man ja nur von eigenen
Erfahrungen berichten, das würde ich jetzt auch mal machen.
Also ich hoffe, wir machen das nicht nur ich.
Weil. Ja, ich glaub das kannst du ja
jetzt nicht irgendwie mathematisch belegen oder so und
sagen ja, das ist ein Fakt oder keine Ahnung, das ist Mythos,
weil ne. Also würde ich sagen, lass uns
doch einfach mal schauen, schauen wir noch mal die letzten
Jahre zurück, so Projekte die wir gemacht haben und wie das da
lief. Also also meine Erfahrung dazu
ist, dass. Meistens.
Jetzt muss man aufpassen. Also ich will das ja auch nicht
verallgemeinern, aber meine Erfahrung nach immer ist es eher
so, immer ist immer so. Dass ab einer gewissen Anzahl an
Entwicklern es nicht mehr schneller wurde, im Gegenteil.
Da sind dann andere Probleme mit ins Boot gekommen, die teilweise
oder auch oft dazu geführt haben, dass genau das Gegenteil
passiert, also man nicht schneller wird, sondern eher
langsamer. So, das klingt ja jetzt erstmal
ein bisschen. Ihr seid doch mehr Leute, mehr
Leute, die Code schreiben und dann dementsprechend kann ja
mehr Code schneller entwickelt werden und man müsste ja auch
schneller vorwärts kommen, aber das.
Tatsächlich ist das nicht die Erfahrung, die ich gemacht hab.
Ich weiß nicht, wir können ja gleich auch noch mal so n
bisschen begründen warum, aber ich würd gern mal wissen, wie
deine Sicht ist. Vielleicht haben wir ja jetzt
quasi 2 Seiten und könnten gegenargumentieren oder
argumentieren, warum wir der gleichen Meinung sind, also hau
mal raus, wie siehst du das oder wie ist deine Erfahrung dabei?
Ja, also ich hab auf jeden Fall auch schon in meiner Karriere,
sage ich jetzt mal, Projekte ganz alleine gemacht.
Das waren dann eher kleinere Projekte und sehr.
Begrenzte Themen, die man eben halt auch alleine bearbeiten
konnte. Und ich habe auch schon in Teams
gearbeitet mit 4 Leuten bis ungefähr so bis 8 Leuten.
Also wenn es jetzt wirklich mit Leuten, meine ich wirklich
Softwareentwickler bzw softwareentwicklerin.
Und aber aber. Im gleichen an der gleichen
Software also. 8 Leute, die wirklich, sage ich mal daran.
Entwickeln genau. Also ich kenne ja.
Schon ordentlich. Ist schon, ist schon ein
bisschen. Nicht mehr so klein nennen.
Nee, auf jeden Fall nicht. Geh ich mit, aber das sind ja
auf jeden Fall, es ist halt ne Bandbreite zwischen alleine und
auch Stufen dazwischen, zwischen alleine und 8 ne so Leute.
Und ich habe auf jeden Fall gemerkt, dass zumindest in
dieser Range. Wie sagt man?
Die Goldene Mitte sagt man, also die goldene Mitte in der Mitte
lag also goldene. Mitte lag in der Mitte.
Es man glaubt ja mal nicht, dass die Goldene Mitte auch wirklich
in der Mitte ist. Nee, aber so ich, ich fand auf
jeden Fall, wenn man alleine arbeitet, ist es so der Punkt,
dass ich finde, dass es relativ schnell geht, dass man quasi.
Wenn man jetzt Leute hinzufügt, sagen wir mal, anstatt einen
alleine zu arbeiten, auch noch eine zweite Person dazu packt,
geht die Entwicklung auf jeden Fall schneller.
Also soweit würde ich eigentlich fast immer gehen und sagen, das
ist Fakt. In einem Gewissen, in einer
gewissen Range funktioniert das fantastisch.
Ich würde auch sagen, dass zum Beispiel so bis 4 Personen
kannst du ne relativ würde ich jetzt aus meiner Erfahrung
sagen, ne relativ gute Aussage oder wäre die Aussage für mich
würde ich zustimmen würde ich sagen ist OK. 4 Personen wird
auch schneller. Ich würde aber zum Beispiel
nicht sagen, dass wenn du sagst, du hast eine Person und das ist
jetzt quasi eine. Weiß nicht.
Eine Entwicklung von 1, dass quasi bei 4 Personen die
Entwicklung auch auf ich sag jetzt mal die fiktive Zahl von 4
im Fortschritt steigt? Also ich würde nicht sagen, dass
es linear ist. Ja genau, und da könnt ich würd
ich dich jetzt zum Beispiel mal fragen, bevor ich das jetzt noch
abschließe, bloß bei 8 Leuten hab ich schon gemerkt, da wurde
es auf jeden Fall schon mal wieder n bisschen träger, also
die Kurve flacht ab würd ich sagen und dann ist halt die
Frage geht sie irgendwann auch wieder runter das heißt also hat
man zum Beispiel irgendwie vielleicht auch diesen Punkt,
dass man sagt mit 16 Leuten ist man deutlich langsamer als mit 8
zum Beispiel, aber was meinst du denn was ich mit also wie stehst
du dazu, wie kannst du dir das vorstellen wenn ich sage?
4 Leute sind nicht doppelt so schnell in der Entwicklung wie
2. Ja.
Also noch mal, falls das nicht ganz rüberkam, ne, wenn wir
jetzt Projekt und Entwicklung sagen, dann reden wir ja
wirklich von einem Thema. Also natürlich ab ner gewissen
Größe sage ich mal. Wenn man jetzt wirklich n sehr
großes Projekt hat. Sind es natürlich mehr als 48
Entwickler, Entwickler, dann ist es halt zweistellig, vielleicht
sogar dreistellig, je nachdem wie riesig das Projekt ist.
Wir reden ja jetzt wirklich davon, an einem Thema zu
arbeiten, ne, also jetzt nicht, nicht ein Feature zum Beispiel,
aber zum Beispiel ein Teilprodukt des gesamten.
Oder Halt eines Standalone Anwendung.
Genau, weil da einfacher bin ich auf jeden Fall dann ganz bei
dir, dass man sagt okay zu zweit auf jeden Fall zu viert, ist
auch noch cool, dann kann man das noch sehr gut organisieren.
Wie geht es weiter? Am besten hat man denn schon
einen, der so ein bisschen. Bisschen zumindest in die Rolle
übernimmt, das zu koordinieren so ein bisschen vielleicht mit
anderen Teams redet, also dieses, Wir hatten ja auch mal
über Scrum geredet, so ein bisschen so den Product owner
macht, sage ich mal und sagt Okay Leute, ich übernehme das,
ich entwickle zwar noch mit, aber ich gucke schon mal, dass
wir die richtigen Features machen, wann müssen wir das
machen, also da muss halt Koordination rein, weil wenn
jetzt 4 Leute los sagen. Soll ich dir mal das in dem
Moment mal? Das hab ich doch schon gemacht
letzte Woche. Ja.
Oder also mal übertrieben gesagt ne oder 2 nehmen sich morgens n
Thema und nehmen sich das gleiche und reden nicht
miteinander. Also.
Das Entschuldigung, das Problem oder die die Challenge dabei ist
ja, wenn du alleine bist, kannst du machen was du willst.
Du bist dein eigener Herr, zu zweit musst du nur mit einer
Person reden, vielleicht arbeitet man sogar im Pair, sage
ich mal und arbeite. Wie immer zusammen easy 34, das
geht irgendwann nicht mehr oder macht keinen Sinn, dass alle
denn auf den gleichen Bildschirm gucken.
Dann kommt ja quasi nen nen Overhead rein an
Organisationsaufwand. Ja.
Und der ist ja noch bei 4 Leuten überschaubar.
Ach, geht auch noch, aber irgendwann kommst du ja an den
Punkt und da sehe ich halt immer oder da bin ich, werde ich dann
quasi skeptisch, ob das wirklich noch schneller macht, dass das
ja alles organisiert werden muss.
Ja. Also.
Leute ja auch quasi integriert werden müssen.
Ne, also das ist halt auch wirklich n seh ich auch so.
Es ist n. Das ist auf jeden Fall einer der
Painpoints, die ich auch identifizieren würde, wenn es
darum geht zu sagen, man packt jetzt einfach nur mehr Leute
drauf. Also das das Witzige ist ja,
dass das ich das auf jeden Fall auch schon so, ich sag jetzt mal
aus. Manager Sicht gehört habe oder
zumindest mitgekriegt habe, dass es wohl Leute gibt im
Managementbereich, die vielleicht.
Diese Auffassung vertreten, dass man sagt, OK, wir haben jetzt
eine eine Anwendung, die entwickelt werden muss, und wir
haben jetzt zum Beispiel 4 Leute und diese 4 Leute sagen ja, wir
werden wahrscheinlich in einem Jahr damit fertig und von
Managementseite heißt es, naja, aber wäre jetzt schon wichtig,
dass wir in einem halben Jahr fertig werden, also was können
wir tun, und dann werden halt verschiedene Möglichkeiten
gesehen, die meiner Meinung nach dann nicht immer ganz mit dem
Resultat deckungsgleich sind, weil wenn man dann nämlich zum
Beispiel sagt, Ja gut. Man braucht ein Jahr mit 4
Leuten, also brauche ich ein halbes Jahr mit 8 Leuten.
Die Rechnung ist total einfach. Würde ich mich halt hinstellen
und sagen, das funktioniert so nicht.
Also da würde ich definitiv mich hinstellen und sagen, das kann
so genau nach dieser Rechnung eben nicht funktionieren.
Und da kommt halt kommen halt so Punkte wie du meintest ne sowas
wie n Overhead. Du hast Absprachen
untereinander. Du musst das ganze koordinieren.
Du musst vielleicht sogar angenommen, du ramst von 4
Leuten auf 8 Leute hoch, dann hast du ja quasi noch ein
Onboarding. Du hast ein
Einarbeitungsprozess, das heißt, du hast auf jeden Fall irgendwie
Overhead, der quasi irgendwie stattfindet und das.
Da würde. Ich halt sagen, dass Slow teilt
das Ganze zumindest entweder kurzzeitig runter, aber im
Endeffekt auch durch diesen ganzen Overhead, der entsteht
eben halt auch langfristig. So heißt nicht, dass es sich
runterslobt, dass man jetzt auf einmal langsamer wird, aber man
wird auf jeden Fall nicht doppelt so schnell, weil man
doppelt so viele Entwickler oder Entwicklerinnen quasi an ein
Projekt setzt. Ja, ich glaube, das ist auch.
Also ich war nie in der Position, sowas berechnen,
bestimmen zu müssen. Also ich will mich da auch nicht
zu weit aus dem Fenster lehnen, aber ich habe halt öfter schon
in der Vergangenheit das Gefühl gehabt, dass es so ist.
OK, du hast ne gewisse Manpower, ein Entwickler kostet dich im
Jahr so und so viel, der sagt Ich brauch n Jahr jetzt um dein
Beispiel noch mal aufzugreifen, dann sind das Kosten von ja
keine Ahnung x und wenn ich jetzt aber sage ich möcht es
aber halb so schnell haben, muss ich einfach die Kosten sozusagen
verdoppeln. Ich stell noch einen Entwickler
ein und dann kriege ich die Zeit gedrückt damit.
Also dein Beispiel fand ich ganz cool weil man hat oft das
Gefühl, dass irgendwie sowas im Hintergrund gerechnet wird, was
aber irgendwie in der Praxis nie aufgeht.
Ja, das mag zwar in der Theorie oder vielleicht auch vor der
Mathematik. Keine Ahnung, irgendwie.
Sinn machen, was da berechnet wird, aber in der Praxis habe
ich persönlich noch nicht erlebt, dass das 1 zu 1 so
aufgeht. Also weil zum Beispiel ein
Punkt, ich wollte dich nicht unterbrechen, aber ein Punkt,
den ich auch super wichtig finde, ist, es ist ja nicht nur
organisatorische Aufwand, der steigt.
Ich finde, es ist auch ein zunehmender Aufwand, diesen ein
Wissenstransfer herzustellen, definitiv also sowas wie.
Jeder weiß Bescheid, was passiert überhaupt in der
Software, weil Worst Case bilden sich kleine Inseln auf einmal
selbst innerhalb des Teams, weil ja die beiden machen immer das,
die beiden machen immer das, weil das war jetzt so die Woche
und da das läuft also weißt du die haben jetzt ihr wissen da
wenn wir jetzt noch mal tauschen würden, dann wären wir ja wieder
langsam. Das können wir jetzt auf keinen
Fall machen, also schön so wie es ist.
Das läuft gerade so und dann wenn die jetzt mal ganz blöd
davon ausgehst Fluktuation einer verlässt das Unternehmen oder
wird krank was man ja nie hofft aber kann ja passieren und dann
hast du halt so deine kleinen Heros auf deinen Inseln die
wegfallen und dann geht da gar nichts mehr weiter und dann
guckst dann guckt man halt richtig blöd auf gut Deutsch.
Du musst ja gar nicht so weit gehen, dass es um Krankheit geht
oder zum Beispiel um keine Ahnung, Abgänge.
Es reicht ja schon, wenn eventuell zu einem ungünstigen
Zeitpunkt bestimmte Personen gleichzeitig im Urlaub sind.
Ja, genau, das ist. Ein guter Punkt.
Klar, man kann versuchen, sich da mal abzustimmen, aber das
klappt ja auch nicht immer, ja, aber.
Das ist ja zum Beispiel auch n Punkt.
Wenn wir jetzt gerade also so n bisschen abdriften, aber
prinzipiell ist es ja nicht schlecht, wenn man genau auf
sowas achtet, also sowas zu vermeiden, dass man eben schafft
nen guten Wissenstransfer. Zu generieren, dass man quasi,
dass jeder zumindest einen guten Überblick hat und überall
mitarbeiten kann, was natürlich jetzt wieder für kleinere Teams
spricht oder zumindest nicht dafür spricht, dass man sagen
könnte, mehr Leute, schnellere Entwicklung oder doppelt so
viele Leute, doppelt so viel, doppelt so schnell Entwicklung.
Aber wenn man dann darauf achten kann, durch diesen guten
Wissenstransfer, den man hinkriegt, dann kann man ja sich
auch selber eigentlich ein sehr viel schöneres Arbeitsklima
schaffen. Wenn man dann zum Beispiel sagt,
Ich möchte dann in den Urlaub und dann heißt es vielleicht
sorry, aber das geht jetzt leider nicht.
Also da muss man auch immer überlegen, was springt für mich
dabei raus und gerade so was, wenn man das im Hinterkopf
behält und sagt Okay lass uns doch effizient vielleicht in den
kleineren Teams arbeiten, wo jeder sozusagen.
Auch n Guten ne wissensdurchmischung gut
stattfinden kann, dann schaffst du dir vielleicht doch einfach
ne schönere Perspektive für deine eigene Arbeit.
Ja, auf jeden Fall. Das ist eigentlich ein ganz
guter Punkt. Ich hätte aber noch einen
anderen. Also ich würde gerne noch ein
anderes Date, das geht jetzt in die andere Richtung, aber was
mir gerade noch dazu eingefallen ist.
Es ist ja nicht nur so, dass ein.
Ist wieviel quasi Organisation, also organisatorisches dazukommt
oder wieviel man denn noch wegarbeiten kann, sage ich mal.
Ich finde ein Punkt, der bei diesem ganzen Thema auch ne
riesen Rolle spielt. Ist ja, wie weit ist man
fortgeschritten im Projekt, um noch mal dein Beispiel
aufzugreifen, sagt man, wir brauchen ein Jahr, wenn man das
Projekt startet oder braucht man noch circa ein Jahr und steckt
schon ein 2 Jahre in der Entwicklung, also das heißt es
geht so irgendwann auf die Zielgeraden und man merkt wir
müssten jetzt doch ein halbes Jahr vorher releasen, also jetzt
doch noch mal schnell Leute einstellen, damit wir das
einhalten können, das finde ich sind auch 2 ganz ganz
unterschiedliche Sachen. Beispielsweise wenn ich gerade
dabei bin, ein Projekt zu starten und Abschätze wie viele
Entwickler brauche ich dafür und stellt dann zum Beispiel 4 Leute
ab aus der Firma, die daran arbeiten sollen, dann können die
sich ja von Grund auf quasi organisieren, dementsprechend
das Projekt aufbauen und ja quasi dann daran arbeiten.
Ganz anders sieht es ja aus, wenn du beispielsweise ja mit 2
Leuten schon 2 Jahre an etwas arbeitest.
Zu zweit schafft man in 2 Jahren jetzt auch schon einiges.
Das heißt, das ist auch nicht mehr so wenig, was da entstanden
ist. Definitiv.
Und dann heißt es so, Ah Jungs, wir haben nur noch n halbes Jahr
hier sind noch mal 2 Entwickler, jetzt seid ihr 4.
Jetzt macht es bitte in der Zeit fertig.
Weil ich mein, weißt du, worauf ich hinaus will?
Also ja, definitiv ja auch Gefahren mit sich, wenn ich da.
Kurz einhaken kann, das ist ja auch genau der Punkt, den du
auch schon so n bisschen angesprochen hattest oder
angeschnitten hattest. Es geht ja um was man immer hat.
Also es gibt 2 verschiedene. Also das hab ich auch selber
schon erlebt. Ne du fängst zum Beispiel bei
einem Projekt an, hab ich gemacht so richtig grüne Wiese
und man kann von vornherein richtig sagen OK es geht los,
lass uns mal hier richtig geil von vorne starten, wir haben
alles in der Hand. Das macht total Bock.
Kann ich auch jedem empfehlen, dass man das irgendwie auch mal
machen kann und das ist cool, das war quasi n Team von 6
Leuten, alle hatten Bock und ja war auf jeden Fall n fähiges
Team und das hat auf jeden Fall richtig gefloht das war geil.
Nichtsdestotrotz hast du am Anfang.
Diesen diesen Effekt, dass du sagst okay man muss erstmal so
eine gewisse Art von Teambuilding machen und zwar
guckst du erstmal okay wie sprich also was für
Konventionen, Absprachen trifft man am Anfang quasi explizit und
was passiert so implizit zum Beispiel du merkst irgendwann ja
okay der eine fängt dann und dann an, der andere fängt dann
und dann an, du kannst das irgendwann, also es gibt manche
Sachen, die du von vornherein richtig per Absprache regelst
und manche Sachen finden halt so unter der Hand irgendwann statt.
Und dann gibt es ja noch den anderen Punkt, und zwar sowas
wie zum Beispiel jetzt kommt jemand Neues in ein bestehendes
Team hinein, dann hast du ja dieses ganze Teambuilding, hast
du ja fertig, das heißt, du musst eigentlich diese eine
Person und. Beziehungsweise je nachdem, wie
viele denn dazu kommen, musst du ja sozusagen Druck beschallen
und dann kommt ja dazu ne wie du meintest, wenn du dieses, dieses
dieses ganze Teambuilding schon hast.
Die Leute können gut arbeiten, das läuft, das funktioniert, das
float. Aber wenn du jetzt zum Beispiel
sagst Verdoppelst das Team, dann hast du ja erstmal, je nachdem
wieviel du auch schon geschafft hast.
Das ist ja auch was du gerade meinst, musst du ja den ganzen
Leuten erstmal überhaupt, also nicht nur das fachliche, sondern
auch noch also fachliche übermitteln.
Was passiert hier, wie läuft das gerade, sondern zusätzlich auch
noch, wie arbeiten wir hier eigentlich im Team?
Und dann kann es ja wieder zu Konflikten kommen, weil
vielleicht zum Beispiel jemand ganz, ganz anders arbeitet, als
man das vielleicht irgendwie so im Flow schon geschafft hat.
Und da kann es dann halt auch noch mal zu Konflikten
beziehungsweise auch Verzögerungen kommen.
Das war mir jetzt noch mal so wichtig, dass auch noch mal so
mit in den Raum zu werfen, weil das habe ich beides schon
erlebt, zum einen neu anzufangen, ein Projekt sowie
jemand kommt dazu, aber auch ich gehe in ein neues Team rein.
Ja, so ne. Also.
Das ist auf jeden Fall, ja, das ist das, finde ich.
Also die Erfahrung habe ich auch gemacht, das ist ja im Prinzip,
wenn du sehr fortgeschritten bist in deinem Projekt und dann,
dann kommen neue Leute dazu. Musst du ja Entwickler abstellen
um quasi die neuen Entwickler zu onboarden.
Das heißt zu erklären, wie sieht denn die Infrastruktur aus, was
macht das Produkt überhaupt, weil es ist ja nicht so, du
kommst in der ersten Tag irgendwo in ein Team.
Was macht dir xy alles klar, bin dabei, gib her wo ide ich habe
meinen Rechner schon mit, der ist da schon alles eingerichtet,
wir können loslegen. So läuft es ja nicht.
Getrunken. Keine Witze, wenn jemand trinkt.
Aber es ist ja doch eher so, dass man erstmal quasi so ein
Onboarding macht. Was machen wir hier, was ist das
Ziel, was ist der Projektplan zum Beispiel, also je nachdem,
wie agil das Ganze läuft und. Dauert das doch, bis so ein
neuer Entwickler seine Manpower wirklich einbringen kann.
Zusätzlich wird die Manpower eines bestehenden Entwicklers
reduziert, weil er sich ja um den Neuen kümmern muss, was ja
auch richtig ist. Keine Frage, ist ja nicht.
Damit nicht sagen, Lass den im Regen stehen, der wird schon
irgendwann klarkommen. Das ist natürlich auch Quatsch,
aber du musst ja trotzdem mal ehrlich sein und sagen, der
Entwickler kann erstmal nicht in voller Leistung
weiterentwickeln. Ja und dann ist die Frage,
rentiert sich das hinten raus, wenn dann beide quasi wieder
dran arbeiten können, würden ja jetzt viele sagen ja auf jeden
Fall ich meine eine Woche einarbeiten, danach 2 Leute die
durcharbeiten aber das ist ja nicht gegeben, dass es so läuft
plus. Gesagt haben, dieser
organisatorische Aufwand, irgendwann musst du ja Leute
abstellen, die nur noch managen. Und dann fällt diese Leistung
auch wieder weg und ich finde, dann kommt man relativ schnell
in den Hamsterrad und Frust kommt auf.
Zum Beispiel angenommen Du bist ein Entwickler von also
Vollblutentwickler und auf einmal bist du mehr mit
organisatorischen Themen beschäftigt als zu entwickeln,
dann dann kommen ja auch so Frust Faktoren schnell ins
Spiel. Gut unterbinden muss also
unterbinden im Sinne von irgendwie lösen muss und das
sind das ist halt so er das kann halt ein richtiger Teufelskreis
werden. Aber man sagt ja auch, es gibt
ja auch. So ein Spruch, der da heißt, so
bevor es sag ich mal schneller wird, wird es erstmal auf jeden
Fall langsamer und ich glaube zwar schon, dass man sagen kann,
also in unserem Beispiel unserem Szenario, dass wir gerade mal so
ein bisschen gebildet haben, dass man sagt, okay, man möchte
jetzt zum Beispiel aus einem Team von 4 Leuten, das möchte
man vielleicht verdoppeln, weil noch mehr Sachen zu tun sind,
dann würde ich sagen, ist am Anfang definitiv erstmal Fakt,
dass die der Fortschritt der Entwicklung.
Was auch immer da entwickelt wird, sagen wir mal irgendeine
Software n Produkt wird erst mal langsamer und danach kann ich
mir durchaus vorstellen, dass zum Beispiel von wenn du von 4
auf 8 Personen gehst, dass es danach sozusagen schneller
voranschreitet. Das heißt, die Entwicklung kann
durchaus schneller werden, ich würde aber nicht sagen, wenn du
jetzt zum Beispiel von 4 auf 8 Personen gehst, dass du dann
sozusagen deine Entwicklungszeit halbierst.
Das ist zum Beispiel, das sind 2 Punkte, die ich, glaube ich,
einfach mal so jetzt in den Raum stellen würde und sagen würde,
ich vermute, das ist so. Aber das ist, das ist wirklich
eigentlich schon fast eine coole Zusammenfassung von dem, was wir
besprochen haben, weil natürlich, wenn ich mehr
Entwickler habe und das irgendwann eingespielt ist und
jeder einen guten Job macht, kriege ich ja mehr Manpower
zusammen und kann schneller entwickeln.
Die Frage ist aber beziehungsweise das Problem an
der ganzen Sache ist, dass sowas ja oft entschieden wird, wenn
Not am Mann ist, also sprich Zeitdruck aufkommt.
Und wie du schon meintest, man wird erst langsamer um dann
schneller zu werden. Ist ja quasi gegeben dadurch was
was ich zum Beispiel gerade meinte mit dem Einarbeiten, dass
du erstmal Leute abstellen musst um neue Leute einzuarbeiten, das
ist ja quasi die, also daraus resultiert.
Ja, dass man langsamer wird. Und meistens ist es so, bevor
man dann richtig Fahrt aufnehmen kann, ist die Deadline doch dann
schon gerissen. Ja, also das ist ja genau der
Punkt, man ist da nicht im halben Jahr fertig, nein,
vielleicht ist man auch nicht viel schneller als ein Jahr wie
es ursprünglich war. Man muss dann halt langfristiger
denken und sich also sich überlegen.
OK, aber wenn ich diese Leute dabei hab, kann es zukünftig
schneller werden. Ja, aber ich glaube auch nicht,
dass du das linear sehen kannst im Sinne von na ja, jetzt 2 und
dann sind wir. Also doppelt so schnell.
Ja, das funktioniert halt auf keinen Fall meiner Meinung nach,
nee. Also das denke ich auch, dass
Lini also linear wird es nicht sein.
Ich würde auch sagen, dass es irgendwann einen Punkt gibt, wo
es wieder schlimmer wird, deswegen würde ich auch zum
Beispiel schon sagen. Eine gewisse Anzahl teamgröße,
da sollte nicht unbedingt überschritten werden.
Wenn man sich jetzt hinstellt und sagt, Na ja, komm, aber wir
haben jetzt zum Beispiel n weiß nicht n Riesen.
Projekt, wo ganz viele Leute mitarbeiten.
Dann würde ich wahrscheinlich vorschlagen zu sagen, OK, dann
versuchen wir das in einzelne Module zu unters unterteilen,
sodass man halt sagt, man hat wieder kleinere Teams, die
miteinander arbeiten können und der, ich sag mal die
Schnittstelle zwischen den Teams sollte möglichst gering bzw
möglichst leichtgewichtig. Sein aber.
Ist ja quasi auch der agile Ansatz, der ja auch in vielen
Unternehmen verfolgt wird zu sagen, OK, wir haben wieder
kleinere Teams, zum Beispiel Scrum Teams, ja die dann halt
wirklich. Super effizient an ihren Themen
arbeiten können und. Dann sind das umgesetzt werden
kann. Das ist meine.
Frage, Da hatten wir auch ne Folge zugemacht.
Da steht wieder auf einem anderen Blatt, aber das ist ja
der Sinn dahinter im Prinzip und dann müssen halt die
Schnittstellen, wie du schon gesagt hast leichtgewichtig
gehalten werden. Zu dem ganzen Thema gibt es ganz
witzig wusste ich nicht. Das ist ein bisschen
recherchiert worden jetzt von uns.
Fand ich ganz witzig, gibt es ja das sogenannte Brooksche Gesetz,
was ja im Endeffekt besagt, dass wenn man.
Quasi Manpower zu einem Projekt, was schon verspätet ist,
hinzufügt, dass es dann noch später wird.
Und das deckt sich halt eigentlich ganz geil mit dem,
was wir hier quasi besprochen haben, weil das auch einfach
unsere Erfahrung ist. Also es ist keine Lösung zu
sagen, Oh, wir haben Zeitdruck, jetzt alle Leute da drauf, dann
dann bremst du dich selbst komplett auf 0.
Quasi dieses edding menpower to late project, make up make it
even later. Ich find, das klingt homo,
klingt so schön auf Englisch irgendwie, aber ich fand es auch
cool. Also wir haben jetzt kurz vor
der Folge, irgendwie sind wir drauf gestoßen, fand ich auch
irgendwie super interessant, das ist überhaupt solche Gesetze
gibt finde ich halt schon witzig.
Aber ich würd prinzipiell glaub ich in dem ganzen Zusammenhang
sagen, es ist also so. Zusammengefasst würd ich sagen
es ist gut, also Teams nicht zu groß zu halten, das heißt
möglichst n kleinen Rahmen abzustecken.
Ich würde so weit gehen, dass man sagt, wenn man ein größeres
Team bis zu einem bestimmten Rahmen, wie ich gerade meinte,
hat, dann kann man die Entwicklung auch erhöhen, also
die Entwicklungszeit verkürzen, dass man halt die
Geschwindigkeit erhöhen, dass man halt eben sagt, Okay nehmen
wir 6 Entwickler, sind wir schneller als 2 Entwickler, wenn
man damit startet, beispielsweise wenn man aber
jetzt zum Beispiel sagt Okay, um das noch ein bisschen
zusammenzufassen, wir sind mitten im Projekt und wollen
jetzt auf einmal mehr Leute hinzufügen, dann kann es halt
dazu kommen, dass man, bevor man schneller wird, doch erstmal
langsamer wird, wenn man sich wie gesagt in dem Rahmen eines.
Kleinen, kleinen Teams bewegt. Und was würdest du jetzt
abschließend sagen? Mehr Entwickler machen das
Projekt schneller. Mythos oder Fakt?
Ich würde sagen, it depens it. Also wenn man jetzt davon
ausgeht, dass man sagt, OK, für jeden Entwickler oder
Entwicklerin, die man ins Team hinzufügt, hast du quasi einen
linearen Anstieg der Geschwindigkeit.
Wenn man das sieht würde ich sagen, ist es absolut ein Mythos
und kann man so nicht rechnen, kann man so nicht sehen, wenn
man aber davon ausgeht zu sagen, wir nehmen eine vielleicht
maximale Teamgröße und gehen davon aus, dass wir von dem
Projekt anfangen. Hatten kann man in gewissen
Grenzen sagen. OK, mehr Leute können eine
schnellere Geschwindigkeit bringen, aber nicht linear würde
ich sagen. Ja, gehe ich mit.
Also für mich ist es auch mehr ein Mythos als n.
Fakt. Ja.
Aber wie gesagt, klar, wenn ich alleine bin und noch ne zweite
Person bekomme, gerade so am Projekt anfangen, macht das auf
jeden Fall viel schneller und dann skaliert das bis zu einem
gewissen Punkt haben wir ja besprochen, bin ich ganz bei
dir, nur dass das immer linear funktioniert ist für mich auch
ein absoluter Mythos, das glaube ich nicht und ich?
Glaube, dass viele Leute, die diese Gedanken anstellen, und da
stelle ich jetzt mal ganz frech, würde ich einfach sagen, so okay
ich glaube, dass einige denken, dass es so ist.
Na ja, das war jetzt schon ganz schön frech.
Wenn man sagen. Hören.
Sagen. Ja, ich würd sagen.
Liebe Zuhörerin, lieber Zuhörer. Teil uns doch gerne mal deine
Meinung mit. Vielleicht hast du auch ähnliche
Erfahrungen gemacht oder auch vielleicht komplett
gegensätzliche und hast festgestellt, ja mehr Leute und
alles ging völlig durch die Decke von der Geschwindigkeit
her, dann schreib uns doch gerne und melde dich bei uns entweder
auf den anderen Plattformen oder per Mail die links findest du
wie immer in den Shownotes würde uns auf jeden Fall sehr
interessieren, vielleicht bist du auch im Projektmanagement
tätig und weißt wie solche Sachen genau berechnet werden,
vielleicht werden da ja noch gewisse Faktoren berücksichtigt,
wäre auf jeden Fall auch mal sehr spannend zu erfahren also.
Sagt, melde dich gerne bei uns. Ansonsten hoffen wir dir hat die
Folge gefallen. Unser kleiner Talk über Mythos
oder Fakt im Sinne von mehr Entwickler, schnellere
Entwicklung. Und ansonsten macht ihr noch
einen schönen Tag. Wir hören uns beim nächsten Mal
wieder deine Coding Buddies. Gemeinsam besser.