Was ist Developer Anarchy?

Ich habe über Developer (oder Programmer) Anarchy gelesen, was als post-agile Entwicklungsmethode in Rechnung gestellt zu werden scheint. Ich habe ein paar Ressourcen darauf gefunden ( 1 , 2 ), aber es scheint nicht viel da draußen zu sein.

Ich habe mich gefragt, ob jemand gute Ressourcen hat, bei denen ich mehr darüber herausfinden kann - wie man es umsetzt, Vor- und Nachteile, Vergleich mit anderen Methoden usw.

agile development-process development-methodologies

— Martyn
quelle

Ich habe noch nie davon gehört, aber es scheint mir ein bisschen widersprüchlich. Sie sagen, "... Formalitäten und Regeln schränken Kreativität und Produktivität ein", aber gleichzeitig haben sie regelmäßige Stand-up-Meetings (als Teil der Methodik?). Ich kann nicht glauben, dass die Beschreibung einer solchen Methodik mit der Festlegung einer Regel beginnt.

— Giorgio

Als ich zum ersten Mal darüber las, schien es mir, dass es von einer Person oder von Leuten gemacht wurde, die nur Erfahrung mit halbgesottenem Agile hatten. Denn diese "Developer Anarchy" ist ein Lehrbuchbeispiel für "Agile Done Right". Z.B. richtig agil umgesetzt.

— Euphorischer

Der erste Link, den Sie zitieren, scheint bereits alles zu enthalten, was Sie suchen.

— Michael Borgwardt

Was für ein schönes Schlagwort!

— CesarGon

@CesarGon: Schlagworte sind einfacher zu erfinden als Methoden, die wirklich neu sind. ;-)

— Giorgio

Ich kann Sie auf Alistair Cockburns Gedanken zu diesem Aspekt „echter“ agiler Projekte hinweisen :

Ein Mitglied der Crystal-Methodenfamilie ist Crystal Clear. Crystal Clear kann einem Hörer der Stufe 3 mit den folgenden Worten beschrieben werden:

„Platzieren Sie 4-6 Personen in einem Raum mit Workstations und Whiteboards und greifen Sie auf die Benutzer zu. Lassen Sie sie alle ein bis zwei Monate laufende, getestete Software an die Benutzer liefern und lassen Sie sie ansonsten in Ruhe. “

Tatsächlich habe ich Crystal Clear in diesen Worten einem erfahrenen Projektsponsor beschrieben. Er befolgte diese Anweisungen und berichtete fünf Monate später: "Wir haben getan, was Sie gesagt haben, und es hat funktioniert!"

Einige Monate später interviewte ich den Teamleiter und sein Bericht war ungefähr so kurz wie meine Anweisungen:

„Auf Ihren Vorschlag hin haben wir vier diesen Konferenzraum mit Netzwerkverbindungen übernommen. Wir haben es alle vier Monate aufbewahrt, auf die Whiteboards dort drüben gemalt und dabei Software geliefert. Es hat großartig funktioniert. “

Das war es, worum es bei Agilität ging, und es scheint, als ob dies der Ansatz der Anarchy-Methodik ist - der Punkt ist, dass man, wenn man Jungs erlebt hat , ihnen sagen kann, sie sollen "abhauen und es funktionieren lassen" und sie werden genau das tun . (Dies funktioniert nicht mit weniger erfahrenen Leuten, Sie würden es nicht einem Team von Junioren überlassen, ohne zumindest etwas Aufsicht zu haben).

Alles, was sich im Laufe der Jahre über Agilität angesammelt hat, wie tägliche Stand-ups und Scrum-Boards, Product Backlog Grooming-Sitzungen, Pre-Meeting-Meetings über das Product Backlog Scrum-Board-Grooming-Session-Planungs-Meetings, sind alles Schwergewichtsprojekte, die gesehen werden sollten Gemeinkosten für eine erfolgreiche Produktlieferung.

Zu viel heutzutage werden diese Dinge jedoch als obligatorisch angesehen und die "agile" Methodik entwickelt sich zu einem System, das mehr Prozesse als die alten Methoden hat!

— gbjbaanb
quelle

"Zu viel heutzutage werden diese Dinge jedoch als obligatorisch angesehen und die 'agile' Methodik entwickelt sich zu einem System, das mehr Prozesse als die alten Methoden aufweist!": Sie haben einen wichtigen Punkt (+1) erreicht. Ich habe mit SCRUM in einem Team von erfahrenen Entwicklern gearbeitet und wir hatten nach zwei Jahren das Gefühl, dass ... wir früher agiler waren, als wir keine täglichen Meetings hatten (wir trafen uns zweimal pro Woche) und viele andere Aktivitäten passiert "wenn das Team entscheidet, dass sie gebraucht werden" anstatt "wenn die Methodik sie vorschreibt".

— Giorgio

+1. Letztendlich denke ich, dass diese Methoden einen andauernden Zyklus anzeigen: Schwere Methoden scheitern wiederholt, (einige) erkennen, dass die Programmierer klug genug sind, um mit Dingen umzugehen, sich vom Prozess abzuwenden und im Allgemeinen funktionieren die Dinge - aber der leichte Prozess ist ausprobiert Bei ungenügenden oder unerfahrenen Teams schlägt die Schätzung fehl oder wird verfehlt. Der Prozess wird hinzugefügt, um "Sicherheit" und "Vorhersagbarkeit" zu erhöhen, und der Zyklus wird fortgesetzt.

— Asthasr

Gahhh ... dieser Zyklus klingt genau und deprimierend.

— Graham

"Tim war ein talentierter Entwickler, der in einem Unternehmen mit talentierten Entwicklern arbeitete. Nahezu jede Methode, die Ihnen

— einfällt,

@syrion: Vielleicht hast du recht. Ich habe irgendwo gelesen, dass die agilen Praktiken für erfahrene Programmierer funktionierten. Dann mussten erfahrene Programmierer, die unerfahrene Teams trainiert hatten, Regeln für sie aufschreiben (weil kontinuierliches Trainieren viel kostet und es besser ist, einige Regeln in einem Buch festzuhalten). Auf diese Weise wurden neue Methoden wie SCRUM und ähnliche entwickelt, sodass die Leute jetzt Bücher oder Zertifikate verkaufen können. Aber der wahre Geist von Agilität besteht darin, den eigenen gesunden Menschenverstand anstelle von Regeln anzuwenden, die von anderen geschrieben wurden. Regeln sind Richtlinien, werden aber von vielen als Religion angesehen.

— Giorgio