Um wieviel ist denn die Software besser geworden? Und anhand dieser Frage merkt man ja schon so was. Was was ist die Einheit von der Zahl, die du mir hören willst? Sowas? Sie ist 2 besser Coding Body deinem Podcast wohnt um Softwareentwicklung und aktueller Technews herzlich willkommen. Herzlich Willkommen zur neuen Folge des Cody Buddies Podcast. Schön, dass du wieder eingeschaltet hast, dass wir uns
hier wieder versammelt haben. Ich bin natürlich wieder dabei, Tino und auch der fantastische Fabi, den ich jetzt begrüßen mag. Fabi, Was geht ab, wie geht es dir? Hallöchen. Halle schön, ich find. Es immer schön, wenn man angekündigt wird irgendwie. Ich weiß auch nicht. Fühlt sich so an, als wenn man so reinkommt. So reingelaufen. Kommt so. Ja, ich komm doch. Mal reingelaufen. Ja, stimmt. Klatschig Klatsch ich immer so mit der Wand ab. Ja, genau so virtuell.
Und da ist er wieder, und da geht er auch wieder. Ja gut, geht es mir ganz gut. Soweit so gut, es ist n bisschen kühler geworden, das find ich ja mal super ne. Einfach mal nicht schwitzen. Ja, ist auch mal was Schönes. Ne, war ja teilweise n sehr warmer Sommer, obwohl. Ich es krass finde, weil eigentlich hab ich das Gefühl es hat die ganze Zeit nur geregnet und dann war es noch mal richtig heiß. Aber. So n Wechsel immer ne entweder Regen oder super warm.
Ja, also immer noch n normaler deutscher Sommer, so wie man ihn kennt würd ich. Sagen ja, wie man ihn kennt und wie man ihn liebt. Aber jetzt kommt wieder die schöne muckelige Winterzeit sei ich schon Herbst erstmal Herbst ne, aber ich. Mag den Herbst überspringen wir ja scheinbar direkt, das ist ja super kalt geworden. Ja, so viel dazu. Aber ich würd mal sagen, starten
wir in die Folge rein. Ja, ja, ich hab auch ein Thema mitgebracht, was krass oder Thema Pass auf was das war haben wir da schon mal vor einer Weile nicht im Podcast. Aber so mal drüber gesprochen und haben uns gesagt okay das kann man doch mal im Podcast beleuchten und zwar das Thema. Metriken in der Softwareentwicklung aber.
Bezüglich der Produktivität innerhalb eines Entwicklungs Teams oder sagen wir mal die produktive eines Entwicklers, also Einzahl Mehrzahl so. Und ja, was gibt es da so für Methoden? Wie kann man das ganze Messen, macht es Sinn das zu messen? Das würd ich halt gern mal so n bisschen kritisch hinterfragen mit dir und mal. Gucken ja, auf welchen Nenner wir da so kommen oder wie wir
beide das so betrachten. Weil es gibt natürlich, sag ich mal gerade denn von vom Manager, also von der Management Ebene den Wunsch gewisse Metriken zu haben um einfach zu überwachen. Wie produktiv ist denn mein Team? Was Produkt XY entwickelt zurzeit können. Wir, das messproduktivität ich find überwachen ist finde ich klingt so mies. Ja, aber also Monitoren im Sinne von Messen, sagen wir mal. Ne, verstehe ich. Genau und im Prinzip deshalb, weil man ja sehen möchte.
Im besten Fall werden wir immer produktiver oder halt frühzeitig erkennen zu können, dass sie Produktivität nachlässt, dass man halt Gegenmaßnahmen einleiten kann. Deswegen sind solche. Metriken ja an sich erstmal vom Grundgedanken nicht schlecht, sag ich mal. Die Frage ist halt immer, wie gut funktioniert sowas und da gibt es natürlich verschiedene Ansätze und die würde ich jetzt gerne mal mit dir. Beleuchten ja auf jeden Fall.
Das ist auch echt ein spannendes Thema, gerade im Bereich der Softwareentwickler. Also man versucht ja immer irgendwie eine gewisse Art von Produktivität oder Performance zu messen, das war ja irgendwie gefühlt schon immer so macht.
Ja, auch Sinn. Man möchte ja auch irgendwie, man hat ja auch einen Anspruch an sich selber, also ich weiß nicht, es fängt ja schon finde ich so zu Hause an, wenn du sagst, ich möchte jetzt keine Ahnung Geschirr spülen, ich weiß nicht wie es dir geht, aber ich versuche halt auch irgendwie, dass das schnell geht oder versucht es halt zu optimieren oder so und deswegen das ist ja immer so auch ein Anspruch an sich selber und ob du jetzt als Einzelperson das machst oder in
einem Team oder als Unternehmen, das ist ja finde ich. Irgendwie eine ganz normale Sache und gerade so bei also. Früher auch so bei also früher heute auch noch ne, aber da kann man das konnte man das ja mal super messen, wie zum Beispiel bei Fabriken finde ich, wenn du sagst, ey, wir produzieren heute. Weiß ich nicht. 1000 teile von
irgendwas. In einer Fabrik ne, und jetzt sagt man zum Beispiel ja, hier kommt, dann kommt jemand und sagt, wir haben neue Maschinen und diese Maschinen, die produzieren viel schneller und viel genauer so und am Ende kannst du ja dann zum Beispiel bei so einer Fabrik dich hinstellen und sagen Okay, sagen wir mal, letztes Quartal hatten wir oder letzten Monat meinte Ich, glaube ich hatten wir 1000 Teile produziert und diesen Monat sind es mit den neuen
Maschinen zum Beispiel 5000 teile, das heißt, Wir haben unsere Produktivität um 5, also 5 mal, also das fünffache erhöht. Voll cool.
Und dann kannst du vielleicht noch gucken, dass du sagst, OK, keine Ahnung, diese Teile, die wir hergestellt haben, sind tatsächlich auch besser verarbeitet und halten unter irgendwelchen Stresstests das Doppelte oder was auch immer ja bisschen kaputt gehen, so kannst du perfekt messen, nur total coole Sache und das blöde an der ganzen Geschichte ist ja, dass es bei Softwareentwicklung gar nicht so einfach ist.
Weil wenn du jetzt zum Beispiel sagst okay, du hast irgendwie ein Produkt. Irgendwie ein Stück Software und dieses Stück Software hatte letzten Monat irgendwie eine bestimmte bestimmten Umfang und nächsten Monat hat es auch einen bestimmten Umfang, aber du weißt ja nicht immer hundertprozentig okay, aber welchen also? Was ist denn jetzt, welcher Umfang ist dazu gekommen? Also das ist ja nicht immer nur das, was du siehst. Das, was hinzugekommen ist.
Und das ist ja dann sozusagen nicht so einfach, das Ganze zu messen, wenn du nicht genau siehst oder also wie in so einer Fabrik an Stückzahlen ey, das ist jetzt Bär geworden und deswegen ist halt natürlich die Frage okay wie kann man das zum Beispiel in der Software Entwicklung an irgendwie diese Performance eben messen. Und das Problem ist, dass dann halt oft willkürlich irgendwas gemessen wurde.
Oder versucht wurde zu messen. Du hast da ja auch schon ganz guten Punkt so indirekt angesprochen und zwar? Ja, also in der Softwareentwicklung über n gewissen Zeitraum, den man jetzt beispielsweise mit seiner
Messung betrachten möchte. Ist es mehr geworden, hast du ja gesagt, das heißt, gehen wir mal davon aus, es sind mehr Zeilen Code geworden, Mhm. Das heißt, die Software wächst, es kommt irgendwie ne Art Funktionalität rein, weil ich gehe jetzt mal davon aus, dass wenn mehr Zeilen Code drin sind, auch mehr Funktionalität in dem Produkt steckt, am Ende also in der Software. Und deswegen hat man ja immer überlegt, so im Laufe der Zeit gibt es ja so wie gesagt,
verschiedene Metriken und so der erste. Irgendwo ja auch logischer Ansatz ist halt genau das zu messen, wie umfangreich denn diese Software ist. Beispielsweise und da sind. Wir dann wieder beim Thema. Wieviel Codezeilen sind denn? Dazu gekommen und deswegen ist gab es halt oder gibt es immer noch. Ich weiß nicht wer das einsetzt, aber gibt es halt grundsätzlich die. Metrik ist noch nicht
ausgestorben. Genau, sie ist noch nicht ausgestorben, aber die Metrik Lines of Code quasi zum Messen, die dazugekommen sind, sprich als Entwickler schreibe ich so und so viele Zeilen Code am Tag, das heißt ich kann messen. Wie viele Zeilen kommen denn über einen gewissen Zeitraum durch die jeweiligen Entwickler dazu und kann dann vergleichen? Nimmt diese Zahl zu, schreiben sie immer mehr Code, schreiben sie weniger Code oder ist es relativ konstant?
Das bringt natürlich. Probleme mit sich definitiv. Also ich bin auch gar kein Fan von dieser Metrik, aber ich glaube, es geht auch vielen so, weil man relativ schnell merkt, dass Lines of Code ja nicht die gleiche, also nicht jede Zeile Code, die dazu kommt, hat ja den gleichen Outcome am Ende also output. So gesehen ist gleich, ich habe
eine Zeile Code mehr. Aber wenn wir jetzt mal den Mehrwert betrachten, dann kann der halt sehr, sehr stark variieren, von Zeile zu Zeile. Das heißt, ich kann 10 Zeilen Code geschrieben haben, an einem Tag, hab damit aber n signifikantes Problem beispielsweise gelöst oder
vielleicht n Bug behoben. Na. Oder ich schreib 10 Zeilen Code und das hat eigentlich keinen großen Mehrwert gebracht, weil es vielleicht einfach nur ne kleine Änderung in der Oberfläche war oder was auch immer, aber halt vielleicht so ne Verschönerungsgeschichte war in der Software. Wenn sie jetzt ne Oberfläche hat und das andere hat aber ein signifikat signifikanten Sicherheits eine Sicherheitslücke geschlossen
oder so, dann dann. Hat das ja extrem unterschiedlichen Wert diese Zeilen, da kann man sie ja
einfach nicht vergleichen. Ich finde da merkt man ja relativ schnell, dass das eigentlich an sich keine gute Metrik. Ist na vor allem, stell dir mal vor, wenn du wenn du sagst Ey Entwickler werden dafür ich nenn s jetzt mal belohnt wenn Sie mehr Zeilen Code schreiben, dann kannst du dich als Entwickler oder Entwicklerin hinstellen und sagen ja okay ich kann diese Lösung die erforderlich ist kann ich mit 10 Zeilen Code hinkriegen, aber ich werde ja.
Quasi sozusagen belohnt dafür, wenn ich mehr schreibe. Also mache ich quasi eher die aufgeblähte Lösung, weil dann sozusagen ich ja im Endeffekt besser dastehe und ne höhere produktiver gelte, produktiver gelte, weil du ja zum Beispiel dann auch bei keine Ahnung irgendwelchen Git changes oder sonst was siehst. Okay Oh guck mal wie viele Zeilencode hinzugekommen sind, und das ist natürlich eine absolute Schwachstellung. Genauso kann man sich hinstellen
und sagen, naja. Welcher Entwickler oder welche Entwicklerin mag es denn nicht, wenn es eine Lösung gibt mit 10 Zeilen, anstatt eine Lösung von 100 oder 1000 Zeilen? Welche würde man bevorzugen? Und da, das ist ein extrem guter Punkt, das ist auch genau dieser zweite Kritikpunkt, den auf den ich mit dir kommen wollte. Schön, dass du es angesprochen hast, weil. So gesehen sorgt.
Das ja dafür, dass vielleicht Entwickler sich denken, oh, ich muss mehr zeigen, Code schreiben, diesen dann eventuell ist jetzt wie gesagt kein Vorteil oder so, aber
vielleicht. Unüberlegter machen und mehr Code bedeutet auch mehr Wartung. Das heißt, diese ganze Software bläht sich auf, wird schwieriger zu warten sein und auch schwieriger zu Refact an sein, beispielsweise weil der Code sich halt einfach so. Extrem aufbläht, wenn man nach dieser Metrik bewertet wird und vielleicht im Hinterkopf hat, Oh verdammt, ich muss noch jetzt mal gehen wir mal davon aus, du musst sogar irgendwie ne gewisse Metrik schaffen, weil du dann
als effektiv oder oder als produktiv gilt und denkst dir so, oh, ich muss heute noch 30. Zeilen hochschreiben. Wieso? Stell dir mal vor. Da merkt man ja schon, dass diese Metrik eigentlich gar keine Aussagekraft. Hat ich hab meine Aufgabe bereits erfüllt, aber ich muss noch 30 Zeilen Code scheiden. Das wäre echt totaler Quatsch. Aber könnte man sich da nicht hinstellen, jetzt mal eine produktive.
Eine provokative Frage kann man sich jetzt nicht hinstellen und sagen, ja gut, dann könnte man ja ein Maß nehmen, wo man sagt, das Produkt in möglichst wenigen Zeilen Code, ist das dann ein besseres Maß, also nehmen wir das mal umgekehrt so, ja. Ja gut, wenn du es richtig umdrehst, dann mache ich den ganzen Tag nichts und bin der produktivste von allem, weil ich nichts geschrieben habe. Aber ja, na ja, natürlich.
Wenn du jetzt komplett ins Gegenteil gehst und sagst, ich muss so wenig Code wie möglich schreiben um meine Lösung zu finden, dann neigt man ja wieder dazu.
Unglaublich. Schwierigen Code im Sinne der Verständlichkeit zu schreiben, weil nicht jeder Code, der sehr, also nicht jede Funktionalität, die sehr mit sehr wenig Code gelöst wurde, ist am Ende gut umgesetzt, weil n Entwickler B der das nicht entwickelt hat, n Kollege beispielsweise sich das irgendwann anguckt und sich denkt, was passiert in diesem One Liner. Diese typischen One liner, ich schreibe die ganze Funktionalität in einer Zeile,
weil ich, weil ich einfach Bock hab das so komplett komplex da abzubilden und. Alle anderen brauchen dann ne halbe Stunde um diese eine Zeile zu verstehen. Überspitzt gesagt, aber genau in diese Gefahr läuft man ja rein. Es ist ja nicht immer die beste Lösung, manchmal sind ein paar Zeilen mehr einfach super fördernd für die Verständlichkeit, dann halt auch ne. Ja, auf jeden Fall. Und da finde ich, ist es halt
einfach. Da merkt man irgendwie, dass es so Lines of Code an sich, es ist halt ein trade off mit wieviel Zeilen Code man sozusagen seine Lösung für ein bestimmtes Problem. Oder für eine bestimmte Aufgabe
umsetzt. Dass man sagt, OK, zu viel ist natürlich quatsch, warum sollte ich mehr nehmen als benötigt, wird aber immer noch irgendwie so viel, dass es auch noch trotzdem weiterhin verständlich bleibt und das also es wird relativ schnell klar, finde ich, wenn man einfach mal n bisschen darüber nachdenkt, dass Lions of Code vielleicht nicht das die beste Möglichkeit sind und ich finde, du hattest auch von von Mehrwert vorhin gesprochen und das ist oft auch ein Problem,
wenn sich wenn sich auf die Produktivität von der von der Performance oder von einem Team wird, das halt eben diese dieser Output ne, also das Ergebnis was geliefert wird, zum Beispiel 100 Zeilen Code einfach. Mehr beachtet wird als das eigentliche Outcome, also dieser dieser Outcome, der Mehrwert, der geschaffen wird, weil wenn du zum Beispiel sagst, Ey und ich find, das ist ja schon, du kannst. Es damit super darlegen, weil wenn du sagst.
Ergibt also dieser Output ne wenn du sagst 1000 Zeilen Code output ne super krass kannst du auf dem Blatt Papier sehen.
Ey das sind super viele Zeilen voll gut, da hat jemand produktiv gearbeitet oder man sagt zum Beispiel Na ja gut aber ne kleinere Lösung wäre halt auch schon schön okay 1000 Zeilen Code ist jetzt auf einmal eine bisschen unrealistisch, aber egal wo man dann aber hinterher merkt, ja okay weiß ich nicht, ist zwar weniger Code aber der Mehrwert ist bei der einen Seite nicht geschaffen, weil du halt einfach viel zu viel Overhead hast und auf der anderen.
Hast du auch keinen Mehrwert geschaffen, weil keiner mehr diesen Code versteht? So, und das ist halt so n kleines Problem sag ich jetzt mal oder einer der großen Probleme auch von den nachfolgenden. Performancekriterien, die wir ja auch noch n bisschen besprechen wollen. Dass sozusagen mehr auf dieses Ergebnis, auf diesen Output als auf den Mehrwert, diesen Outcome, den der Fokus gelegt wird.
Ja, ja, was halt einfach auch daran liegt, dass du diesen Output quasi ja auch besser messen kannst als den Outcome. Also wie nehmen wir noch mal kurz dieses Lines of Code Beispiel, ich kann natürlich viel schneller auch automatisiert feststellen, wieviel Zeilen Code sind denn jetzt mit der letzten Änderung in die Software gekommen? Das lässt sich ja viel leichter ermitteln. Als wieviel Mehrwert wurde geschaffen?
Genau. Wieviel also mal vereinfacht gesagt, um wieviel ist denn die Software besser geworden? Und anhand dieser Frage merkt man ja schon so was. Was ist die Einheit von der Zahl, die du mir hören möchtest? Sowas? Sie ist 2 besser. Und das ist halt, da merkt man einfach die Schwäche von dieser Metrik. Und deswegen, glaube ich, sind da auch relativ viele schnell von weggegangen und es wurden sich halt andere Metriken auch in der Zeit überlegt und die
sind auf jeden Fall schon. Ne Ecke besser haben aber auch ihre vor und Nachteile und da würd ich gerne mal auf eine Eingehen, im Prinzip auf die. Die Geschwindigkeit in der Entwicklung wird ja oft belostet, also velocity.
Ja genau, die Metrik wird oft Velocity genannt und da hat man sich dann halt überlegt, wie kann man denn das Messen, wie schnell mein Team entwickelt und ein ein Ansatz ist gerade ja, wenn man in der agilen Welt nach Scrum beispielsweise arbeitet oder allgemein Kanban nach Tickets halt. In der agilen Welt und ich, ich habe Tickets, die müssen erledigt werden und. Die sind ja, sagen wir mal, in
üblichen geschätzt worden. Das heißt, man ermittelt ungefähr, wie lange dauert das, und dann erledige ich sie beispielsweise im Sprint, oder halt, ja, muss jetzt nicht nach Sprint sein in einer gewissen Zeit, und diese Zeit, die ich da nehme für meine Messung, kann ich ja gucken, wieviel habe ich denn erledigt, also beispielsweise, wir sagen, heute ist der Start so ein klassischer Sprint und wir machen.
Jetzt 2 Wochen und wir nehmen jetzt haben im Team jetzt 10 Tickets ja beispielsweise und im Schnitt haben die sagen wir 5 Punkte, dann sind das ja 50 maximal erreichbar.
Punkte in den 2 Wochen wenn ich sage, das ist jetzt mein Zeitraum und ich gucke, wie viele Punkte habe ich denn am Ende auch wirklich erreicht, sprich hab ich alle Tickets abgeschlossen, hab ich ja logischerweise alle 50 Punkte erreicht, das heißt nach meinem Maß habe ich genau meine Geschwindigkeit erreicht, die ich möchte. Ich bin schnell, weil ich schaffe das alles abzuarbeiten.
Beziehungsweise wenn du sagst, du hast zum Beispiel keine Ahnung. In einer in einem Sprint zum Beispiel, sagen wir mal einfach Sprint 1. Hast du vielleicht 30 Punkte abgearbeitet? Sprint 2 hast du auf einmal 40 geschafft und Sprint genau. 3 hast du dann. Irgendwie 45 geschafft. Das heißt deine Geschwindigkeit, deine Velocity von Punkten, die du sozusagen in deinem Zeitraum abgearbeitet hast, dieses gestiegen, also bist du schneller geworden.
So genau. Das wäre nicht der Punkt, was ich jetzt sagen wollte ist genau was du meintest, weil wenn ich jetzt im nächsten Sprint auf einmal nur noch 20 Punkte mache, dann bin ich ja quasi halbiert, mehr als halbiert in meiner Geschwindigkeit und das wäre dann quasi so, wollte man die Metrik dann verwenden zusammen warum sind wir denn jetzt so langsam geworden, was ist passiert oder in deinem Beispiel
super? Wir werden immer schneller, fantastisch und das klingt erstmal logisch, dass man sagt, ja, OK, ja gut, ich Messe halt wieviel oder wie schnell schaffe ich es meine Tickets abzuarbeiten, ja. Klingt ja erstmal schon viel besser als diese Lines of Code. Metric hat aber halt auch Probleme und zwar jeder der in der agilen Welt mal gearbeitet hat oder vielleicht aktuell tut. Liebe zuhören, lieber Zuhörer, falls es bei dir so ist, wirst
du uns wahrscheinlich. Sehr wahrscheinlich zustimmen. Jetzt ist ja genau diese Schätzung, wie lange ein Ticket dauert und man dann halt quasi das mit Punkten verseht. Ein unfassbar schwieriger Punkt und ein sehr subjektiver Punkt, was bei dieser Metrik ja noch viel entscheidender ist, oder? Da haben wir. Übrigens auch mal eine Podcast Folge drüber gemacht. Falls dich das ein bisschen
genauer interessiert. Liebe zuhören, lieber Zuhörer, damit das noch mal genauestens erläutert und warum es auch subjektiv und schwierig ist. Aber ich stimme dir total zu, Tino weil im Endeffekt ist es ja um das mal kurz zusammenzufassen, also wenn jetzt sagen wir mal, wir beide stellen uns irgendwo hin und sagen okay, was meinst du? Weit ist zum Beispiel der nächste Turm irgendwo da hinten
entfernt. Dann werden wir wahrscheinlich weder das genau gleiche schätzen, also die genau gleiche Maßeinheit, die genau also nicht genau die gleiche meta Einheit schätzen sozusagen. Also ich sag dann. Grundsätzlich in Fuß schätze und ich in Meter. Ja, Instinkte fußmäßig Nein. Aber weißt du was ich meine?
Also ich sag dann zum Beispiel keine Ahnung, es sind 50 Meter, du sagst es sind vielleicht 30 Meter oder was auch immer und am Ende unterscheidet sich unsere Schätzung aber auch sozusagen. Die unsere Schätzung wird sich auch von der Realität sehr wahrscheinlich unterscheiden und damit hast du natürlich auf jeden Fall schon mal ne Varianz drin, die dir definitiv.
Die die, die sich, die sich definitiv mit einschleichen, wird in in diese sag ich mal, in diese Varianz deiner Geschwindigkeit von sag ich mal Sprint zu Sprint, Iteration zu Iteration und was ich auch sehr sehr kritisch dabei finde ist, dass wenn wir das jetzt mal weiter denken und sagen okay die Entwickler und Entwicklerinnen schätzen diese Tickets, also es wird irgendeine Story um eine Aufgabe genommen und.
Man setzt sich zusammen und schätzt das und sagt Okay das ist jetzt vielleicht eine 1, eine 2, eine 3, je nachdem, nach welchem Maß man schätzt oder t Shirts heißt und. Dann wird hinterher gesagt, okay, ihr wart vielleicht, wenn ihr zum Management sagt, ihr Wart und Produktion produktiv.
So was wäre denn der nächste Schritt, man könnte sich ja hinstellen und sagen okay, dann sagen wir beim nächsten Mal, wenn zum Beispiel vielleicht schätzt, dass dein Ticket eine 1 wäre, sagst du okay es ist eine 3. So also bläst du im Endeffekt künftig. Ich das ganze auf, das heißt ne du schätzt einfach mehr ein als es überhaupt in Wirklichkeit einnimmt diese Aufgabe um dann hinterher dich feiern zu lassen, dass du so viel abgearbeitet
hast. Und das ist halt natürlich wieder ne sehr, sehr schwierige Sache. Ja. Gerade wenn es ne sorry. Ja nee, es ist halt auch wie gesagt sehr subjektiv und wenn man aber sagt, man will jetzt projektweit diese Metrik verwenden, also über mehrere Teams hinweg, dann kannst du diesen subjektiven Faktor einfach nicht mehr einfangen, weil wie du schon meintest, die einen denken sich so, oh, bevor
ich hier als unproduktiv gelte. Bewerte ich die Tickets lieber als komplexer oder zeitaufwendiger, je nachdem, ob man jetzt nach Komplexität oder wirklich nach Zeit schätzt? Ja, machen ja auch viele. Dass man denn sagt, nee, ich gehe lieber den sicheren Weg und gelte ja auch automatisch als produktiver, wenn ich es höher ansetze und es dann schaffe.
Ist ja besser als zu sagen, Ach naja, es wird schon, ich bin da ziemlich optimistisch und nachher machst du schließt du keine Tickets ab und giltst halt als super unproduktiv, obwohl du quasi gleich performt hast als im letzten Sprint hast dich halt nur verschätzt im Prinzip. Ja, und das ist halt die Gefahr.
Und andererseits kannst du halt auch andere Teams schlecht dastehen lassen, wenn du halt deine subjektive Einschätzung komplett abweichend ist zum zu den anderen Teams und du halt sage ich mal der High Performer in Anführungsstrichen bist der 50 Punkte umgesetzt hat, was aber nur 2 Tickets waren oder wie auch immer, ist jetzt nur eine reine Zahl und die anderen sind im Schnitt bei 3035 punkten beispielsweise.
Und ja, gelten ja dann als weniger produktiv, obwohl sie vielleicht einfach realistischer geschätzt haben. Ja, und dazu kommt ja auch noch, dass wenn du unterschiedliche Teams hast, die vielleicht in einem großen Bereich zusammenarbeiten, aber zum Beispiel irgendwie das Management will, diese Teams vergleichen. Du weißt ja gar, also das Management hat meistens wenig wissen darüber, in welchem Kontext jemand. Unterwegs ist so, und jedes Team hat sehr wahrscheinlich, also
ich weiß nicht das. Da wirst du mir wahrscheinlich zustimmen. Aber wenn man in unterschiedlichen Teams gearbeitet hat, wird es auch wird auch unterschiedlich geschätzt und. Du kannst es halt im Worst Case gar nicht richtig vergleichen. Du kannst nicht sagen, dieses Team schätzt zum Beispiel nach Zeit dieses Team, schätzt nach Komplexität, schätzt nach einer anderen Skala, was auch immer und das Ganze dann hinterher wieder zu auf einen Nenner zu bringen, ist natürlich
schwierig. Klar kann sich hinstellen und sagen, jeder macht das jetzt gleich, aber nichtsdestotrotz hast du immer noch eine Unsicherheit drin, der Kontext ist ein anderer, wie gesagt, ein Output ist ja nicht gleich outcome, also wenn jetzt zum Beispiel jemand sagt, EY, wir haben jetzt dieses Ticket und dieses Ticket ist wirklich sehr, sehr wichtig. Dann ist es vielleicht auch gar nicht so interessant, wie lange es dauert, wenn wir jetzt in
Zeiteinheiten sind. Aber der Impact, der hinterher entsteht. Für das der ist ein. Absolvierendes Tickets, ne, das ist halt wichtig. Genau und das sind halt so. Punkte, die die, die passen einfach nicht zusammen. Und das Problem bei Velocity ist, weil wenn man jetzt kann man sich natürlich fragen ja gut velocity ja wozu ist es denn da? Also diese ganze Stories schätzen und einplanen. Das ist n Planungstool. Damit kann zu Kapazitäten planen.
Damit kann man sagen OK. Es gibt Leute, die zum Beispiel das Team, das also das, das kann jetzt diese Kapazität an Arbeit aufnehmen, ne, aber? Das zu missbrauchen sag ich jetzt mal um ne Produktivität zu messen. Das ist halt schwierig und das kann halt auch im Endeffekt, wenn jetzt zum Beispiel ei das eine Team diese Punkte aufbläht und dadurch sozusagen vermeintlich auf n Blattpapier
schneller ist als das andere. Auch wieder dazu führen, dass natürlich jetzt die Zusammenarbeit zwischen den Teams halt stark gefährdet wird. Ne? Ja. So, und das willst du auch nicht haben. Genau. Und jetzt kann man natürlich auch sagen, Na ja, gut, dann.
Gehst du halt dich zum Beispiel über die Punkte, dass du sagst, OK, ich will, also ich angenommen du bist jetzt manager, du verstehst diesen Punkt von dir gerade und sagst ja OK, dann sind Punkte, kann man manipulieren, dann sagen wir OK wieviel Tickets fertig sind am Ende. Ne, dann können Sie ja sagen, das sind 30 Punkte, aber am Ende zählt wieviel Tickets fertig sind.
Aber genau das kannst du wiederum ja auch manipulieren, indem du denn einfach deine Aufgaben so fein granular machst, dass du sagst keine Ahnung, ich mach ne kleine Änderung in der Software ist ein Ticket, also versteh mich nicht falsch, fein geschnittene Tickets sind Gold wert, weil umso besser kannst du sie dann beispielsweise schätzen oder überhaupt sind sie dann erst greifbar, aber. Wenn du das jetzt wieder in Metrik verpackst.
Könnte man, könnte man auch wieder übertreiben und sagen, wir machen es richtig, richtig fein. Granulare Tickets und ich schließe 5 am Tag ab, überspitzt gesagt und dann ist das ganze auch wieder hinfällig und das ist halt das Problem bei der Velocity, was ich sehe, dass du halt immer einen Weg findest um künstlich deine Produktivität zu steigern, ohne am Ende diesen Outcome zu steigern, weil wie gesagt es ist. Ich finde das ist auch ein gutes Beispiel, es ist ja, wenn es eine Wichtige.
Qualität ist spielt es keine Rolle, ob sie nach 2 oder 3 Wochen da ist. Ja ne, ist ja nicht, dass der Manager sagt, du bist jetzt nicht fertig, du bist fast fertig ist egal. Ich will das jetzt nicht mehr. Es ist zwar wirklich, wirklich wichtig, dass diese Funktionalität in die Software kommt, aber jetzt. Nee, du hattest 2 Wochen. Weißt du, das spielt ja am Ende dann wirklich keine Rolle mehr, weil der Impact einfach groß ist für die Software, dass das dann reinkommt.
Ja, ja, definitiv. Gebe ich dir recht, aber wenn du jetzt weiter guckst und sagst ne, weil ich jetzt das schon mal n bisschen angeschnitten hatte und man sagt jetzt Na gut, Pass auf, man nimmt das vielleicht als Planung ne und sagt dann vielleicht ne, dann könnt ihr ja vielleicht jetzt so n bisschen weiter spinnen das Ganze und sagen Na ja pass auf.
Wir haben jetzt unsere unsere Stories und wir haben jetzt erfahrungsgemäß wissen wir, dass so oder also ich hab das glaub ich auch schon erlebt, dass man sagt OK ne pro. Entwickler oder Entwicklerin kann sozusagen können weiß ich
nicht. Sagen wir mal 5 Stories in der Woche erledigt werden ne nur mal als Beispiel so, dann sag es dann gehst du nicht mehr dahin und sagst OK wieviel können wir abarbeiten, sondern man sagt OK. Ein Entwickler, eine Entwicklerin ist in der Lage, Roundabout 5 Stories storypunkte sozusagen ne, also diese geschätzten Punkte abzuarbeiten.
Dann kann man sich ja hinstellen und sagen, ja gut, OK, das ist ja so ne Art von Utilisation oder Auslastung, dass du sagst ne. Wieviel, wenn wenn ich das weiß wieviel Punkte, also wieviel Tickets kann ich denn dann zum Beispiel einer Person zuordnen? Ne könnte ich ja zum Beispiel sagen, ja gut, wir haben jetzt 2 Tickets, wenn du von 2 Wochen redest 2 Tickets a 5 storypunkte oder? 4 Tickets mit 2 und 3 Punkten pro Woche oder was auch immer ne. Also kannst du ja dann zu.
Ich muss ja. Ich muss kurz mit rechnen. Und das heißt, du kannst im Endeffekt ja ne gewisse Auslastung für eine Person irgendwie ne. Also wenn du jetzt sagst okay Pass auf jede Person ist 100% ausgelastet, hast du vielleicht eine größere Produktivität als wenn du sagst jede Person macht nix. Also jetzt war wirklich die absoluten Extreme so also also. Im Prinzip würde wahrscheinlich. Jeder zustimmen und sagen ja klar, wenn die Leute was tun, na dann ist besser, als wenn die
Leute nichts tun. So und je mehr sie tun, desto besser. Okay verstehe ich, verstehe ich das heißt, die Metrik dahinter ist zu versuchen, die Auslastung möglichst hochzuhalten, und das spricht für eine hohe Produktivität, weil den Leuten böse. Gesagt, nicht langweilig wird. Genau das ist die Metrik dann am Ende. Das wäre die Metrik Utilization oder Auslastung eine. Ja, auch oft genutzt wird oder auch gerne genutzt wird, gerade vom Management, weil das
Management dann das ist. Ja, das ist ja, das kommt ja alles immer so n bisschen, sag ich mal aus dieser Analogie von der Fabrik, ne, es ist ja nur gut, wenn zum Beispiel ne Maschine. Arbeitet so und wenn du sagst, OK, du hast jetzt zum Beispiel ein Fließband und eine Maschine, arbeitet und gibt dann das Teil. Keine Ahnung was auch immer, gibt es an die nächste Maschine weiter und du hast 5 Maschinen.
Ne, und du sagst jetzt OK jetzt wird n Teil hergestellt, erst Maschine 1, dann gibt es das Teil Maschine 2 weiter Maschine 3 Maschinen 4 Maschine 5 Maschine 5 stellst fertig und dann ist es fertiggestellt und dann wird das nächste Teil angefangen. Da könnte man sich ja relativ schnell hinstellen und sagen na ja aber. Könnte man nicht sagen, dass 5 Teile immer gleichzeitig bearbeitet werden, anstatt dass du sagst ein Teil immer nur bis
alles fertig ist? Ne würde ja erst mal Sinn machen und genauso kannst du ja von dieser Auslastung her auch ausgehen und sagen ja komm hier, das können ja auch Entwickler und entwicklerinnen können ja auch genau eine hohe Auslastung fahren. Also das ist im Prinzip kein Leerlauf. Gibt jetzt in der Fabrik, dass halt ständig jeder Teilschritt aktiv ist, sozusagen.
Genauso wie im Team einfach jeder Entwickler dauerhaft aktiv ist, sozusagen und immer ein Ticket vor der Nase hat, sagen wir mal so. Und das klingt ja erstmal auf dem Papier nach einer guten Metrik zu sagen, naja, wenn alle bei 100% sind, dann ist es meine maximale Produktivität, fertig. Also jetzt kannst du sagen okay, jetzt gehen wir noch hier in absoluten Panic Mode und schalten auf 110 Produktivität
hoch und 110%. Aber genau da ist ja auch die Frage, wie lange werden die Entwickler das Mitmachen, weil wenn du immer auf Anschlag läuft und da ist auch die Analyse. Zu Maschinen oder auch so Fabriken nicht schlecht. Du kannst ja nicht immer am Anschlag laufen, weil wie lange soll das gut gehen, das kannst du vielleicht für ne gewisse Zeit machen, aber ich bin mir ziemlich sicher, dass.
Sich ne negative Stimmung einstellen wird, wenn die Entwickler quasi konstant das Gefühl haben am Limit zu sein. Ja, im roten Bereich sozusagen. Ja, genau das, also wenn du halt wirklich immer im roten Bereich drehst sozusagen und sagst, nee, komm bisschen noch noch 2 Wochen los, bisschen bisschen geht noch, dann ist halt wirklich die Frage, wie lange kann man das
durchhalten. Und da gibt es ja auch verschiedene Studien dazu, sage ich mal, die sagen, OK, es ist eher schädlich, so eine hohe Auslastung zu haben, gerade in Hinsicht der Softwareentwicklung, und das kann ich mir halt gut vorstellen, weil ich, wie ich ja gerade schon meinte, wenn ich mir vorstelle, das ganze Team ist immer im roten Bereich, dann wird es irgendwann.
Zu beispielsweise mentalen Problemen kommen, zu Motivationsproblemen und dann wird diese Produktivität ganz schnell in die falsche Richtung kippen. Ja, vor allem das witzige an der ganzen Geschichte ist ja auch, dass gerade bei wenn du jetzt mal wirklich diese Analogie zu einem Fließband nimmst, dann hast du ja eigentlich, sage ich
jetzt mal. Im Normalfall eher das nicht, dass es kommt ja nicht auf einmal neuer Schritt rein, ne, dass du zum Beispiel sagst, so, ja jetzt müssen wir aber also ne irgendwie so Störfaktoren ne, also kann natürlich schon mal sein, dass du irgendwie sagst, ne Maschine fällt aus oder so klar gut gehen wir mal davon ab, sondern dass du sagst irgendwie ungeplante Arbeit in einem Fließband hast du eher weniger ungeplante Arbeit, weil es ist alles durchgetaktet, aber bei
einer Softwareentwicklung in einem Team. In dem Produktteam, was auch immer und. Gerne mal. Also wenn jemand jetzt dagegen widerspricht, Liebe Zuhörerin, lieber Zuhörer, dann immer raus damit. Aber ich glaube, ich möge jetzt sprechen oder für immer schweigen. Genau. Aber Fakt ist es, dass ja wahrscheinlich. Also ich hoffe, dass das jeder
kennt. Weil also ich kenn es auf jeden Fall zur genüge, du hast immer irgendwie ungeplante Arbeit, die irgendwie mal wieder reinkommt und wenn du sagst, OK, du hast bis zu 100% ausgelassen und jetzt kommt aber jemand und sagt, das müssten wir wirklich gerade noch mal einschieben, das ist gerade wirklich noch mal wichtig, wie kannst du Sachen einschieben, wenn du bei 100% ausgelastet bist? Oder vielleicht 110 das funktioniert ja nicht. Richtig. So, das kann man sich auch ganz
gut vorstellen. Wie gut sind denn deine Jonglier Künste? Meine. Ja, also ich kann mit 3. Bällen kann ich jonglieren. Ja, 3 kriegst du hin und jetzt stell dir vor, das sind sind das deine 100%. Meine 120% sind das. OK, aber. Stellen wir uns mal vor, du, du machst das souverän. Das ist genau 3 Bälle ne das das schaffst du und jetzt stell ich mich hin und sag aha ich hab hier noch einen und wirf den einfach so zu dir rüber und auf einmal hast du 4 und musst weiter jonglieren.
Wie lange wird das gut gehen und das ist ja genauso wenn du quasi am Anschlag bist und da einfach keine Zeit und keine keine Kapazität mehr über ist. Für diesen vierten Ball und dann kommt trotzdem irgendwann derjenige der dir diesen vierten Ball zuwirft und am Ende wird. Ich folgendes passieren, dass du alle Bälle fallen lässt und. 3. Bälle fallen lassen, ein Ball werf ich dir gegen Kopf und dann renn ich weg.
Ja OK, gut, dann, das heißt, die Produktivität geht erst mal so auf, was 25 nee 20% 25% runter und dann auf 0, weil du den letzten Ball noch in meine Richtung wirst. Kommt drauf an, was man damit jetzt als produktiv versteht. Also das. Liegt ja am Auge. Des Betrachters. Nein, ich weiß was du. Meinst Plot bist ich hab auch 3 Fälle und mit 4 komme ich dann auch nicht klar und dann passiert bei mir genau das gleiche. Hast du schöne Kettenreaktion im Team? Aber ich finde das, das stellt
es halt einfach sinnbildlich. Ich hoffe man konnte sich das jetzt vorstellen, einfach perfekt da, weil es wird nicht funktionieren dann und du hast es so schön gesagt, weil es ist unvermeidlich, dass irgendein Randthema reinkommt und wenn du dann keine Kapazität dafür hast, wird dir das Halt auf die Füße fallen am Ende. Also ich meine, selbst wenn du von einem Wasserfallmodell aus gehst, wo ihr eigentlich alles durchgeplant ist, von A bis z, wo du wirklich sagst das geht,
hier geht's los, da ist es zu Ende und fertig und dann ist die Sache. Dieses Modell wurde ja nicht umsonst gechallend, weil du halt einfach ja genau diesen Effekt hast, dass du sagst, ey, es kommen neue Sachen rein ungeplante Sachen, es ist es kommen Störfaktoren, irgendwas, irgendwas muss noch mal angepackt werden oder wie auch immer und ja, da kommt man relativ schnell dazu, dass das halt einfach auch nicht das richtige Maß ist oder nicht das
optimale Maß ist. Aber im Endeffekt können wir ja zusammenfassen, wenn wir jetzt sagen, Okay Produktivität
messen. Wir haben jetzt 3 Sachen besprochen, die jetzt nicht so optimal offensichtlich laufen, also zum einen zum einen, aber die Lines of Code, als zweites noch die Velocity, die Geschwindigkeit und als drittes die Utilisation, die Auslastung und wie wir gerade einmal ordentlich dargelegt haben, sind das jetzt nicht die besten Metriken, um irgendwie eine Performance zu messen, eine Performance des Teams oder auch eine Einzelperson.
Genau. Weil sie sich ja einfach ich finde, das kann man eigentlich bei allen sagen, sich halt zu sehr auf diesen Output konzentrieren und nicht auf den Mehrwert, also den Output. Bei der oder während der Entwicklung. Genau, ja, aber in dem Sinne würde ich sagen, das sind auf jeden Fall jetzt erstmal 3 Metriken, die sich nicht unbedingt eignen. Und jetzt können wir mal. Trotzdem beliebt sind und oft
stimmt gut. Dass das noch mal sagst, das wird nämlich trotzdem noch zu oft, wahrscheinlich auch einfach angewendet. Jetzt können wir einfach mal einen kleinen Cliffhanger machen und sagen okay, wir haben jetzt schon, glaube ich, genug gequatscht hier rüber und betrachten einfach mal und gehen einfach mal in der nächsten oder in einer der nächsten folgen, ich weiß es noch nicht genau, wann wir das besprechen, aber da werden wir uns dann mal angucken wie. Kann man es denn überhaupt
besser machen? Was sind denn Metriken, die wirklich dazu führen, dass man vielleicht sinnvoll messen kann, wie produktiv sozusagen ein Team war, anhand der Software anhand des Ziels, was verfolgt wird? Genau weil da gab es ja über die Zeit auch Metriken, die es wirklich besser gemacht haben. Und ich finde es gut, dass wir es in der extra Folge machen, weil wir sind ja jetzt auch schon fortgeschritten in der Zeit und. Haben wir das cool getrennt?
Gefällt mir gut, machen wir, so Fabi, gute Idee. Super und in dem Sinne würde ich sagen, können wir die Folge auch abschließen. Jo und ich hoffe, liebe Zuhörer, lieber Zuhörer, das hier die Folge gut gefallen hat und. Wenn du dich auch bei manchen dieser Metriken wiederfindest im Sinne von, es wird danach gemessen oder du kennst das, was wir gerade geschildert haben, dann schreib uns gerne mal.
Oder du sagst vielleicht auch, nee, Moment, Moment, Moment, wir benutzen die und die Metrik und die funktioniert super dann. Das wissen, weil das ist natürlich einfach n sehr, sehr interessantes Thema auch und wenn du was hast. Dann schreib uns sehr, sehr gerne über unsere Podcast Mail.
Die findest du in den Shownotes. Genauso kannst du auch wenn du sagst, Ey Coding Buddy ist ja Coding Buddies Podcast, das ist ne richtig coole Sache, die gefällt mir richtig super, ich bin total begeistert, dann gib uns auch gerne Feedback oder hinterlasse ne kleine Spende kannst du auch alles über die Podcast Mail machen in den Shownotes oder den Link zur Spende findest du auch in den Shownotes und ansonsten?
Empfehle den Podcast gerne weiter und in dem Sinne würde ich sagen, verabschieden wir uns wieder von dir. Wir hören uns hoffentlich in der nächsten Folge wieder deine Coding Buddies. Gemeinsam besser. Was?