Clean Code DeveloperClean Code Developer

Hallo Sven, es gibt bspw. diese Aufzeichnung: https://refactoring-legacy-code.net/aufzeichnung-zum-webinar-softwareentwicklung-ohne-abhaengigkeiten-veroeffentlicht/ Viele Grüße Stefan

Ohje... wie alt sind denn die Kollegen? ;-) Leider ist mir derzeit kein IOSP Video bekannt. Das müsste ja für deine Kollegen auch sehr auf den Punkt sein, oder? Zum Beispiel "Das IOSP in 90 Sekunden", oder? :-D

Danke für den Hinweis auf das Video. Ich bin begeistert.

Hallo Ralph, in meiner Ausbildung zum Scrum Product Owner habe ich gelernt, dass die Velocity (Story Points pro Sprint) eine Konstante für ein Team darstellt und lediglich gemessen wird, um Unterforderung und Überlastung zu vermeiden (nach dem 'Mura' Prinzip (Unausgeglichenheit) aus der 'Lean Production'). Sie ist kein Indikator für einen Wert der Software. Welcher Wert produziert wird, hängt fast ausschließlich damit zusammen, welche Priorität die Aufgaben im Backlog bekommen (die wertvollsten zuerst).

Hallo, Stefan! Natürlich ist die Velocity (bzw SPs) kein Indikator für Wert. Das ist ja mein Punkt 😉 Dass Wert die Priorität beeinflusst, ist klar. Aber nicht nur. Das wäre ja auch zu schön 😁 Aber selbst wenn nur Wert die Priorität beeinflussen würde, dann wird Wert immer noch nicht getrackt. Warum nicht? Wo ist das Diagramm, auf dem gezeigt wird "So viel Wert wurde geschafft im Sprint!"? Man misst also keinen Wert, sondern etwas, das Last darstellt? Die Velocity zeigt an, ob ein Team sich überlastet hat oder nicht ausgelastet war? Last bezieht sich auf Kapazität, denke ich. Ich habe vllt die Kapazität, 60 Kartoffeln pro Stunde zu schälen. (Das hat natürlich Voraussetzungen, zb ein scharfes Messer oder Ungestörtheit oder unverletzte Hände.) Wenn ich 60 Kartoffeln schäle, bin ich ausgelastet. Schäle ich 80 Kartoffeln, bin ich überlastet. Bei nur 40 Kartoffeln nicht ausgelastet. Woher weiß ich, dass ich 60 Kartoffeln schälen kann, dass das meine Kapazität ist? Indem ich Erfahrung sammle. Ich schäle einfach mal einen Tag lang und zähle die Kartoffeln pro Stunde: [54,55,56,62,67,59,65,62] Der Durchschnitt ist 60. Warum variiert die Zahl der geschälten Kartoffeln? Weil ist am Anfang erstmal mit dem Setting vertraut werden musste und die Kartoffeln sowieso unterschiedlich groß sind. Es gibt nun zwar einen Trend, das ich scheinbar noch mehr Kapazität habe - aber darauf würde ich jetzt erstmal nicht wetten😉 Wer nun wissen möchte, wie lange ich brauche, um die Kartoffeln für eine Firmenfeier mit 250 Gästen zu schälen, der würde die Zahl der benötigten Kartoffeln nehmen (zb. 3 pro Gast im Schnitt, also 750 insgesamt) und durch meine Kapazität teilen. Dann kommen ca. 13 Stunden oder 1,5 Tage raus. Erstens gäbe es nun eine Prognose, wie lange vorher ich mit dem Schälen beginnen müsste. Das ist für die Organisation der Vorbereitung interessant. Zweitens wäre gewährleistet, dass ich mich nicht überlaste. Das ist für die dauerhafte Arbeitsfähigkeit wichtig. Aber warum das Streben nach "Ausgeglichenheit"? Warum "mura" vermeiden? Ich denke, aus demselben Grund, warum man die Geschwindigkeit der Autos auf der Autobahn in einem recht engen bereich haben will: um Staus zu vermeiden. Wenn mehrere (!) gekoppelte (!) Stationen etwas produzieren, dann ist große Variabilität im Output der Stationen keine gute Sache. Dadurch entsteht Verschwendung, wenn eine Station mehr produziert, als die nächste aufnehmen kann (das sieht man an Halden). Oder es entsteht Verschwendung, weil freie Kapazität nicht durch Output vorheriger Stationen genutzt wird (das sieht man an Stillstand). Wo ist das beim Kartoffelszenario aber ein Problem? Dazu müsste man ein bigger picture des Essenszubereitungsprozesses sehen, denke ich. Wo ist das bei der Softwareentwicklung ein Problem? Welcher nachgelagerte (!) Prozessschritt könnte überlastet werden mit viel Output, wenn die Velocity diesen Sprint mal doppelt so hoch ist wie beim vorherigen? Welcher nachgelagerte (!) Prozessschritt könnte unterfordert werden, wenn die Velocity in diesem Sprint nur halb so hoch wäre wie beim vorherigen? Wenn schon "mura" ein Gedanke ist, dann frage ich nach dem bigger picture, in dem der Produktionsschritt Softwareentwicklung ausgeglichen/rund laufen soll? Wo sind potenzielle Halden oder Leerläufe? Aber nicht nur das, die nächste Frage ist: Wen interessiert denn das, was die Software ausgeglichen produziert? Das ist "Komplexität"; die wird ja gemessen. Bei der Kartoffelanalogie wird die Kapazität in dem gemessen, was relevant ist für eine weitere Essenszubereitung. Story Points jedoch interessieren niemanden. Kein Kunde ist bereit, für Story Points Geld auszugeben. Komplexität von User Stories hat nur Relevanz für den PO; sie informiert seine Priorisierung, weil sie angenommenerweise mit Umsetzungsdauer positiv korreliert. Er setzt sie für die Priorisierung zum von ihm geschätzten Wert einer USer Story in Beziehung. Und dann? Dann ist Komplexität nicht mehr interessant. Dann dauert die Umsetzung einfach so lange, wie sie dauert. Nach einem 2 Wochen Sprint, hat man einfach 10 Tage gearbeitet. Keine Überraschung, würde ich sagen. Ob man dabei eine Komplexität von 46 oder 120 bewältigt hat... Was sagst das über die Kapazität aus? Ob man aber 10 User Stories oder nur 5 oder 13 geschafft hat... Das (!) könnte etwas aussagen für den Kunden. Aber auch User Stories werden nicht konsequent getrackt. Dabei wäre das doch das Allereinfachste. Man muss nur zählen. (Ich wäre da sogar noch genauer und würde auch angeben, an welchen Tagen welche Stories fertiggestellt wurden.) Wer mehr User Stories schaffen will - also die User Story Kapazität erhöhen will -, der kann sie ja kleiner schneiden. Warum nicht? Jede User Story stellt als Inkrement zumindest irgendeinen Wert dar. Das fände ich einen Schritt in Richtung Ehrlichkeit und Relevanz. Komplexität jedoch... die ist aus meiner Sicht kein Indikator für irgendetwas, allemal, da man sie sich jederzeit so hinschätzen kann, wie man mag. (Was natürlich niemand tut, wenn er an Velocity gemessen wird.)