![\"\"](\"https:\/\/cultivate.software\/wp-content\/uploads\/2022\/11\/coin-heads-and-tails_600.png\")
Jede M\u00fcnze (Produkt) muss 4 Arbeitsstationen durchlaufen, bevor sie dem Kunden zur Inspektion \u00fcbergeben werden kann. Jede Arbeitsstation wird von einem Teammitglied (Arbeiter) repr\u00e4sentiert, und jedes Teammitglied muss jede M\u00fcnze zweimal umdrehen \u2013 nacheinander, wobei nur die linke Hand verwendet wird. <\/p>\n
![\"\"](\"https:\/\/cultivate.software\/wp-content\/uploads\/2022\/11\/penny-game_1360-1.png\")
<\/figure>\n<\/div>\nRunde 1 von 4<\/h2>\n\n
In der ersten Runde betr\u00e4gt die Paketgr\u00f6\u00dfe 20 (entspricht der Anzahl aller M\u00fcnzen). Das bedeutet, dass Arbeiter 1 alle 20 M\u00fcnzen der Charge umdrehen muss, bevor er das Paket an die n\u00e4chste Arbeitsstation von Arbeiter 2 weitergeben darf. Dann muss Arbeiter 2 alle M\u00fcnzen umdrehen, bevor er die Charge an Arbeiter 3 weitergeben darf. Und so weiter, und so fort. <\/p>\n
![\"\"](\"https:\/\/cultivate.software\/wp-content\/uploads\/2022\/11\/penny-game-batch-size-of-20_1360-1.png\")
<\/figure>\n<\/div>\nDer Rest des Teams beobachtet die Arbeiter und misst die Zeit, die vergeht, bis der Kunde die erste M\u00fcnze und die letzte M\u00fcnze (alle M\u00fcnzen) erh\u00e4lt.<\/p>\n\n In dem oben genannten Fall ben\u00f6tigt das Team 5 Minuten und 17 Sekunden, um die 20 M\u00fcnzen (Produkte) abzuliefern.<\/p>\n\n Wir haben nur einen Paket mit 20 M\u00fcnzen, daher kommt die erste M\u00fcnze gleichzeitig mit der letzten an.<\/p>\n\n Ich spiele normalerweise den Kunden und an dieser Stelle bringe ich normalerweise ein wenig Schwung hinein:<\/p>\n\n Sobald ich die Charge M\u00fcnzen erhalte, werfe ich eine M\u00fcnze und k\u00fcndige an, dass ich lieber Kopf statt Zahl m\u00f6chte. Ich mache dies, um die sich st\u00e4ndig \u00e4ndernden Anforderungen in Softwareprojekten zu simulieren. <\/p>\n\n Wenn zu Beginn alle M\u00fcnzen zuf\u00e4llig Kopf und Zahl zeigen und wenn alle Arbeiter die M\u00fcnze genau zweimal drehen, werde ich im Durchschnitt 10 K\u00f6pfe und 10 Zahlen erhalten.<\/p>\n\n Tats\u00e4chlich erhalte ich jedoch 11 M\u00fcnzen, die Zahl zeigen, anstatt 20 K\u00f6pfe. Das entspricht einer Fehlerquote von 55%! <\/p>\n\n Es sieht so aus, als m\u00fcsste das Team etwas Zeit mit ungeplanten Nacharbeiten verbringen.<\/p>\n\n Ich vergleiche diese erste Runde mit nur einer Charge gerne mit einem Softwareprojekt, das einen traditionellen Wasserfallansatz verwendet.<\/p>\n\n In einem Wasserfallprojekt wird die Projektzeit in verschiedene Phasen unterteilt:<\/p>\n Die Charge M\u00fcnzen repr\u00e4sentiert eine Sammlung aller Features. Alle Features werden gemeinsam geplant, eingebaut, getestet und am Ende des Projekts dem Kunden als ein finales Produkt (eine Charge) \u00fcbergeben. <\/p>\n\n Oft sind Personen aus verschiedenen Abteilungen f\u00fcr die unterschiedlichen Projektphasen verantwortlich. Zwischen den Abteilungen verwenden sie formelle und zeitaufw\u00e4ndige \u00dcbergaben, um sicherzustellen, dass nicht sie es sind, die das Projekt gef\u00e4hrden. <\/p>\n\n Ob die Features von guter Qualit\u00e4t sind, wird erst am Ende des Projekts festgestellt. Es gibt eine manuelle Testphase, und die Endnutzer k\u00f6nnen erst nach Erhalt des Produkts Feedback dazu abgeben. <\/p>\n\n In einem Wasserfallprojekt gibt es im Wesentlichen einen gro\u00dfen Feedbackzyklus:<\/p>\n Aber das Feedback kommt zu sp\u00e4t. Viele Funktionen des gelieferten Produkts sind fehlerhaft oder in ihrem aktuellen Zustand unbrauchbar. <\/p>\n\n Wasserfallprojekte \u00fcberschreiten oft die Fristen und das Budget aufgrund von unvorhergesehenen zus\u00e4tzlichen Arbeiten, die erst am Ende des Projekts oder nach der Lieferung des Produkts entdeckt werden.<\/p>\n\n Zur\u00fcck zum Penny-Spiel.<\/p>\n\n In Runde 2 wird die Paketgr\u00f6\u00dfe halbiert. Das bedeutet, dass jeder Arbeiter die ersten 10 M\u00fcnzen umdrehen muss und dann die Charge an die n\u00e4chste Arbeitsstation weitergeben darf, bevor er mit dem Umdrehen der verbleibenden 10 M\u00fcnzen fortf\u00e4hrt. <\/p>\n Der Rest des Teams beobachtet erneut die Arbeiter und misst den Prozess.<\/p>\n\n Sobald der Kunde die erste M\u00fcnze (als Teil der ersten Charge mit 10 M\u00fcnzen) erh\u00e4lt, werfe ich eine M\u00fcnze und k\u00fcndige an:<\/p>\n\n \u201eDer Kunde m\u00f6chte Zahl; bitte stellt sicher, dass alle nicht gelieferten M\u00fcnzen Zahl zeigen!\u201c<\/p>\n\n Die Arbeiter d\u00fcrfen nun ein drittes Mal eine M\u00fcnze werfen, um dies zu erreichen.<\/p>\n\n Die erste Charge enthielt 5 unerw\u00fcnschte M\u00fcnzen mit Zahl, und das Team schaffte es, mit der zweiten Charge nur M\u00fcnzen mit Kopf zu liefern.<\/p>\n\n Hier sind die Resultate von Runde 2:<\/p>\n\n Zun\u00e4chst stellen wir fest, dass der Kunde das erste Produkt (die M\u00fcnze) nach 2 Minuten und 39 Sekunden erh\u00e4lt. Das ist etwa doppelt so schnell im Vergleich zu Runde 1. <\/p>\n\n Und mit insgesamt 3 Minuten und 12 Sekunden dauerte es 2 Minuten weniger, um alle Produkte zu liefern.<\/p>\n\n Die Fehlerquote sank von 55 % auf 25 %.<\/p>\n\n Die zweite Runde kann mit einem Projekt verglichen werden, das Scrum als Entwicklungsansatz verwendet.<\/p>\n\n In Scrum arbeitet ein funktions\u00fcbergreifendes Entwicklerteam in 4-w\u00f6chigen Iterationen, die Sprints genannt werden, an dem Produkt.<\/p>\n Pro Sprint konzentriert sich das Team nur auf einige wenige Funktionen. Das Team plant, baut ein und testet die Funktionen. Am Ende jedes Sprints liefern sie das Set an Funktionen und erhalten Feedback. <\/p>\n Fr\u00fches Feedback und enge Zusammenarbeit (funktions\u00fcbergreifende Teams vs. Abteilungen) tragen dazu bei, die Projektzeit zu verk\u00fcrzen und die Qualit\u00e4t erheblich zu steigern.<\/p>\n\n Die Paketgr\u00f6\u00dfe wird in der dritten Runde des Penny-Spiels erneut halbiert. Jetzt muss jeder Arbeiter 5 M\u00fcnzen drehen, bevor er 5 M\u00fcnzen an die n\u00e4chsten Arbeitsstationen weitergibt und mit dem Drehen des n\u00e4chsten Sets von 5 M\u00fcnzen fortf\u00e4hrt. <\/p>\n W\u00e4hrend der Rest des Teams den Prozess mit ihren Stoppuhren verfolgt, entscheidet der Kunde, ob er Kopf oder Zahl m\u00f6chte. Sobald ich die erste Charge von 5 M\u00fcnzen erhalte, werfe ich eine M\u00fcnze und k\u00fcndige an: „Zahl!“. <\/p>\n\n Die erste Charge enth\u00e4lt 2 M\u00fcnzen, die Kopf zeigen.<\/p>\n\n F\u00fcr die verbleibenden 3 Chargen darf das Team eine M\u00fcnze dreimal werfen, um sicherzustellen, dass der Kunde nur M\u00fcnzen mit Zahl erh\u00e4lt.<\/p>\n\n Hier sind die Ergebnisse von Runde 3:<\/p>\n\n Wir stellen fest, dass die Dauer bis zur Lieferung der ersten M\u00fcnze mit 1 Minute und 15 Sekunden erneut halbiert wird (ein Viertel im Vergleich zu Runde 1).<\/p>\n\n Die gesamte Lieferzeit betr\u00e4gt jetzt weniger als 3 Minuten, und die Fehlerquote liegt nur bei 10 %.<\/p>\n\n Wir k\u00f6nnen die dritte Runde mit einem Projekt vergleichen, das Kanban als Entwicklungsansatz verwendet.<\/p>\n\n Ein Kanban-Team arbeitet in w\u00f6chentlichen Iterationen und begrenzt die laufenden Arbeiten, um Kontextwechsel zu vermeiden.<\/p>\n Jede Woche reflektieren sie dar\u00fcber, wie sie den Entwicklungsprozess verbessern k\u00f6nnen und holen Feedback von ihrem Kunden oder den Endnutzern ein.<\/p>\n\n Ein Kanban-Board hilft dem Team, die laufenden Arbeiten zu visualisieren und zu optimieren.<\/p>\n\n Kein Entwickler darf gleichzeitig an mehr als einem Feature arbeiten (One-Piece-Flow). Bevor ein Entwickler mit einem neuen Feature beginnen kann, muss er sicherstellen, dass kein anderes unfertiges Feature noch in Arbeit ist und Unterst\u00fctzung ben\u00f6tigt (z. B. eine ausstehende Code-\u00dcberpr\u00fcfung). <\/p>\n Ein wichtiges Kanban-Prinzip ist:<\/p>\n\n H\u00f6r auf zu starten; fang an zu beenden!<\/p><\/blockquote><\/figure>\n\n Das Ergebnis noch k\u00fcrzerer Feedbackschleifen und noch engerer Zusammenarbeit unter den Teammitgliedern ist ein st\u00e4ndiger Fluss von vollst\u00e4ndig getesteten und integrierten Features w\u00e4hrend der Arbeitswoche.<\/p>\n\n Mit Kanban werden die gesamte Lieferzeit und die Fehlerquote weiter reduziert.<\/p>\n\n Bisher haben wir gesehen, dass die Reduzierung der Arbeitspaketgr\u00f6\u00dfe zu k\u00fcrzeren Feedbackschleifen f\u00fchrt. Und k\u00fcrzere Feedbackschleifen f\u00fchren zu einer Verk\u00fcrzung der Lieferzeit und einer erh\u00f6hten Qualit\u00e4t. <\/p>\n\n Es scheint vern\u00fcnftig anzunehmen, dass, wenn es uns gelingt, die Arbeitspaketgr\u00f6\u00dfe weiter zu reduzieren, die Lieferzeit sinken und die Qualit\u00e4t noch weiter steigen wird.<\/p>\n\n Aber nehmen wir an, die Paketgr\u00f6\u00dfe in der Softwareentwicklung ist bereits auf je ein Feature zeitgleich (Kanban) reduziert.<\/p>\n\n Welche Praktiken k\u00f6nnten m\u00f6glicherweise zu noch k\u00fcrzeren Feedbackschleifen und engerer Zusammenarbeit f\u00fchren?<\/p>\n\n Es ist Zeit f\u00fcr die letzte Runde des Penny-Spiels.<\/p>\n\n Diesmal betr\u00e4gt die Paketgr\u00f6\u00dfe 1 M\u00fcnze. Das bedeutet, dass jeder Arbeiter eine M\u00fcnze zweimal dreht und sie dann sofort an die n\u00e4chste Arbeitsstation weitergibt. <\/p>\n Sobald der Kunde die erste M\u00fcnze erh\u00e4lt (sie zeigt Zahl), k\u00fcndige ich an, dass der Kunde nur „Kopf!“ m\u00f6chte.<\/p>\n\n Hier sind die Ergebnisse von Runde 4:<\/p>\n\n Nach nur 36 Sekunden erh\u00e4lt der Kunde seine erste M\u00fcnze (Produkt). Sie ist fehlerhaft, aber das fr\u00fche Feedback erm\u00f6glicht es dem Team, 19 M\u00fcnzen von guter Qualit\u00e4t zu liefern. Die Fehlerquote sinkt auf 5 Prozent. <\/p>\n\n Die gesamte Lieferzeit betr\u00e4gt 2 Minuten und 42 Sekunden, was erneut etwas niedriger ist im Vergleich zu Runde 3 und etwa der H\u00e4lfte von Runde 1.<\/p>\n\n Ich vergleiche Runde 4 gerne mit einem Projekt, das eXtreme Programming als Entwicklungsansatz verwendet.<\/p>\n\n eXtreme Programming (XP) bringt alles, was in der Softwareentwicklung funktioniert, auf die „extreme“ Stufe.<\/p>\n XP basiert auf agilen Werten und Prinzipien, die sich nicht wesentlich von denen anderer agiler Ans\u00e4tze unterscheiden. Aber XP kommt \u2013 im Gegensatz zu Scrum oder Kanban \u2013 mit einem konkreten Satz von Praktiken der Softwareentwicklung, die die Software Delivery Performance erheblich steigert. <\/p>\n\n Pair-Programming und Test-first-Programming sind zwei der bekannteren XP-Praktiken.<\/p>\n\n Pair-Programming hebt die Zusammenarbeit unter den Teammitgliedern auf die n\u00e4chste Stufe. Das bedeutet, dass alle Entwickler die meiste Zeit \u00fcber in Paaren arbeiten. 2 Entwickler, 1 Computer, 1 Problem. Der kontinuierliche Verbesserungsprozess findet st\u00e4ndig statt. Ein Paar von Entwicklern tauscht st\u00e4ndig Wissen aus und gibt sich gegenseitig Feedback sowie Anleitung. <\/p>\n Test-first-Programming ist die Disziplin, Code in kurzen Zyklen von 5-15 Minuten zu entwickeln. Jeder Zyklus beginnt mit dem Schreiben eines Tests (der fehlschlagen wird), der Anpassung des Codes (damit der Test besteht) und der Verbesserung des Codes (um sicherzustellen, dass der Code wartbar bleibt). <\/p>\n\n Beim Test-first-Programming wird die Gr\u00f6\u00dfe der Arbeitspakete praktisch auf weniger als eine Funktion zur gleichen Zeit reduziert. Jeder Test befasst sich mit einem der vielen Aspekte einer einzelnen Funktion. Jeder Test treibt den Einbau eines Features n\u00e4her in zum Abschluss. <\/p>\n\n Das Penny-Spiel zeigt, dass die Reduzierung der Arbeitspaketgr\u00f6\u00dfe zu k\u00fcrzeren Feedback-Zyklen f\u00fchrt. Und k\u00fcrzere Feedback-Zyklen haben einen tiefgreifenden Einfluss auf die Lieferzeit und die Qualit\u00e4t. <\/p>\n\n Agile Methoden versuchen, dasselbe f\u00fcr Softwareprojekte zu erreichen. Allen agilen Methoden ist gemeinsam, dass sie die Paketgr\u00f6\u00dfe reduzieren, um zeitiger Feedback vom Kunden zu erhalten. Um die Paketgr\u00f6\u00dfe zu verringern, f\u00f6rdern sie eine engere Zusammenarbeit aller Beteiligten, die daran arbeiten, ein Feature dem Kunden vorzustellen. <\/p>\n Scrum f\u00fchrt das Konzept von 4-w\u00f6chentlichen Sprints und funktions\u00fcbergreifenden Teams ein.<\/p>\n\n Kanban verwendet w\u00f6chentliche Iterationen und Begrenzungen f\u00fcr den Arbeitsfortschritt, die das Team zwingen, noch enger miteinander zusammenzuarbeiten.<\/p>\n\n Und eXtreme Programming (XP) bringt engere Zusammenarbeit und k\u00fcrzere Feedback-Schleifen, durch Pair-Programming und Test-first-Programming, auf die Spitze.<\/p>\n\n Bis demn\u00e4chst Verbessert die Einf\u00fchrung von Agile-Ans\u00e4tzen wirklich die Software Delivery Performance von dir und deinem Team? Und wenn ja, welche Methodik ist besser? Scrum, Kanban oder eXtreme Programming? Es ist nicht einfach, die positiven Auswirkungen der Einf\u00fchrung von Agile-Praktiken zu messen. Kein Softwareprojekt ist gleich. Und es ist leider unm\u00f6glich, in der Zeit zur\u00fcckzugehen und es […]<\/p>\n","protected":false},"author":1,"featured_media":3043,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"_genesis_hide_title":false,"_genesis_hide_breadcrumbs":false,"_genesis_hide_singular_image":false,"_genesis_hide_footer_widgets":false,"_genesis_custom_body_class":"","_genesis_custom_post_class":"","_genesis_layout":"","footnotes":""},"categories":[7],"tags":[],"class_list":{"0":"post-3207","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-unkategorisiert","8":"entry"},"yoast_head":"\nRunde 1<\/th> Runde 1<\/th> Runde 2<\/th> Runde 3<\/th> Runde 4<\/th><\/tr><\/thead> Paketgr\u00f6\u00dfe<\/td> 20<\/strong><\/td> <\/td> <\/td> <\/td><\/tr> Erste Lieferung<\/td> 5:17<\/strong><\/td> <\/td> <\/td> <\/td><\/tr> Letzte Lieferung<\/td> 5:17<\/strong><\/td> <\/td> <\/td> <\/td><\/tr><\/tbody><\/table><\/figure>\n\n Fehlerquote<\/h3>\n\n
Metriken<\/th> Runde 1<\/th> Runde 2<\/th> Runde 3<\/th> Runde 4<\/th><\/tr><\/thead> Paketgr\u00f6\u00dfe<\/td> 20<\/td> <\/td> <\/td> <\/td><\/tr> Erste Lieferung<\/td> 5:17<\/td> <\/td> <\/td> <\/td><\/tr> Letzte Lieferung<\/td> 5:17<\/td> <\/td> <\/td> <\/td><\/tr> Fehlerquote<\/strong><\/td> 55%<\/strong><\/td> <\/td> <\/td> <\/td><\/tr><\/tbody><\/table><\/figure>\n\n Wasserfall<\/h2>\n\n
![\"\"](\"https:\/\/cultivate.software\/wp-content\/uploads\/2022\/11\/waterfall_1360.png\")
<\/figure>\n<\/div>\n![\"\"](\"https:\/\/cultivate.software\/wp-content\/uploads\/2022\/11\/loops-1@2x-2.png\")
<\/figure>\n<\/div>\nRunde 2 von 4<\/h2>\n\n
![\"\"](\"https:\/\/cultivate.software\/wp-content\/uploads\/2022\/11\/penny-game-batch-size-of-10_1360-1.png\")
<\/figure>\n<\/div>\nMetriken<\/th> Runde 1<\/th> Runde 2<\/th> Runde 3<\/th> Runde 4<\/th><\/tr><\/thead> Arbeitspaketgr\u00f6\u00dfe<\/td> 20<\/td> 10<\/strong><\/td> <\/td> <\/td><\/tr> Erste Lieferung<\/td> 5:17<\/td> 2:39<\/strong><\/td> <\/td> <\/td><\/tr> Letzte Lieferung<\/td> 5:17<\/td> 3:12<\/strong><\/td> <\/td> <\/td><\/tr> Fehlerquote<\/td> 55%<\/td> 25%<\/strong><\/td> <\/td> <\/td><\/tr><\/tbody><\/table><\/figure>\n\n Scrum<\/h2>\n\n
![\"\"](\"https:\/\/cultivate.software\/wp-content\/uploads\/2022\/11\/loops-3@2x.png\")
<\/figure>\n<\/div>\n![\"\"](\"https:\/\/cultivate.software\/wp-content\/uploads\/2022\/11\/scrum-team_800.png\")
<\/figure>\n<\/div>\nRunde 3 von 4<\/h2>\n\n
![\"\"](\"https:\/\/cultivate.software\/wp-content\/uploads\/2022\/11\/penny-game-batch-size-of-5_1360-1.png\")
<\/figure>\n<\/div>\nMetriken<\/th> Runde 1<\/th> Runde 2<\/th> Runde 3<\/th> Runde 4<\/th><\/tr><\/thead> Arbeitspaketgr\u00f6\u00dfe<\/td> 20<\/td> 10<\/td> 5<\/strong><\/td> <\/td><\/tr> Erste Lieferung<\/td> 5:17<\/td> 2:39<\/td> 1:15<\/strong><\/td> <\/td><\/tr> Letzte Lieferung<\/td> 5:17<\/td> 3:12<\/td> 2:56<\/strong><\/td> <\/td><\/tr> Fehlerquote<\/td> 55%<\/td> 25%<\/td> 10%<\/strong><\/td> <\/td><\/tr><\/tbody><\/table><\/figure>\n\n Kanban<\/h2>\n\n
![\"\"](\"https:\/\/cultivate.software\/wp-content\/uploads\/2022\/11\/loops-6@2x.png\")
<\/figure>\n<\/div>\n![\"\"](\"https:\/\/cultivate.software\/wp-content\/uploads\/2022\/11\/kanban-board_800.png\")
<\/figure>\n<\/div>\nK\u00f6nnen wir das noch \u00fcbertreffen?<\/h2>\n\n
Runde 4 von 4<\/h2>\n\n
![\"\"](\"https:\/\/cultivate.software\/wp-content\/uploads\/2022\/11\/penny-game-batch-size-of-1_1360-1.png\")
<\/figure>\n<\/div>\nMetriken<\/th> Runde 1<\/th> Runde 2<\/th> Runde 3<\/th> Runde 4<\/th><\/tr><\/thead> Arbeitspaketgr\u00f6\u00dfe<\/td> 20<\/td> 10<\/td> 5<\/td> 1<\/strong><\/td><\/tr> Erste Lieferung<\/td> 5:17<\/td> 2:39<\/td> 1:15<\/td> 0:36<\/strong><\/td><\/tr> Letzte Lieferung<\/td> 5:17<\/td> 3:12<\/td> 2:56<\/td> 2:42<\/strong><\/td><\/tr> Fehlerquote<\/td> 55%<\/td> 25%<\/td> 10%<\/td> 5%<\/strong><\/td><\/tr><\/tbody><\/table><\/figure>\n\n eXtreme Programming (XP)<\/h2>\n\n
![\"\"](\"https:\/\/cultivate.software\/wp-content\/uploads\/2022\/11\/loops-12@2x.png\")
<\/figure>\n<\/div>\n![\"\"](\"https:\/\/cultivate.software\/wp-content\/uploads\/2022\/11\/pair-programming-1.jpeg\")
<\/figure>\n<\/div>\nZusammenfassung<\/h2>\n\n
![\"\"](\"https:\/\/cultivate.software\/wp-content\/uploads\/2022\/11\/cause-effect_800.png\")
<\/figure>\n<\/div>\n