“Can work from user stories”
Was bedeutet das? Ich habe herausgelesen: “Der mid-level Developer kann das, was er am Quellcode zu tun hat, selbstständig aus User Stories ableiten.”
Stimmen Sie mit mir in dieser Interpretation überein? Wenn ja, dann hier zur Begründung, warum ich darüber den Kopf geschüttelt habe.
Welcher Ansatz von Softwareentwicklung steht dahinter, wenn Entwickler ihre Arbeit am Quellcode selbst aus User Stories ableiten? Ich stelle mir das so vor:
Es gibt eine Besprechung, in der User Stories vorgestellt werden. Das Team klärt sein Verständnis der Anforderungen, die darin stecken. Dann wird vielleicht der Aufwand geschätzt. Dann wird geklärt, welche User Stories in Angriff genommen werden sollen. Und dann melden sich Entwickler, die einzelne User Stories umsetzen wollen. Sie arbeiten im Sinne eines Durchstichs, also einer allein (oder vielleicht zwei im Pair) realisieren die User Story.
Ich behaupte nicht, dass der Autor des Blogpostings so arbeitet. Ich behaupte auch nicht, dass er meint, ein mid-level Developer solle so arbeiten. Die obige Formulierung jedoch suggeriert mir so ein Vorgehen. Und das ist so weit weg von dem, wie ich meine, dass Software entwickelt werden sollte, dass ich einfach mal einhake.
Und wenn mir in den Tagen eines klar geworden ist, dann dies:
Kein Entwickler sollte allein von User Stories ausgehend arbeiten.
Wir haben jedes Projekt mit der Erarbeitung eines gemeinsamen Verständnisses der Anforderungen begonnen. Anschließend haben wir gemeinsam den Lösungsansatz erarbeitet. Viele Gehirne haben also die Anfordeurngen hinterfragt, viele Gehirne haben sich kreativ in den Entwurf eingebracht. Das war für die Projekte unheimlich hilfreich.
Nicht nur wurde dadurch eine gemeinsame Sprache als Basis für den vertrauensvollen Umgang mit der Problemdomäne im Team herausgearbeitet. Nein, alle haben auch dazu beigetragen, dass der Entwurf unter keinen blinden Flecken leidet. Und alle haben einen Überblick über die Gesamtanwendung bekommen.
Das war Team Buildung und Software Design in einem. Ein effizienter und effektiver Prozess – der darüber hinaus auch noch Spaß gemacht hat. Keine Prinzipienreiterrei, sondern kreativer Fluss der Ideen im Rahmen des Clean Code Developer Wertesystems.
Aus meiner Sicht brauchen User Stories daher immer viele Entwickler und nicht einen. Ob der eine allein mit User Stories umgehen kann, ist mir recht egal. Wichtiger ist, ob ein Entwickler sich im Team in den Umgang mit User Stories einbringen kann, ob er einen Beitrag zum Verständnis und zur Planung der Umsetzung leisten kann.
Das hat denn für mich auch weniger mit Domänenwissen oder technischer Erfahrung zu tun, als vielmehr mit Softskills. Wie neugierig ist ein Entwickler? Wie “schnell im Kopf” ist sie? Ist sein Denken flexibel? Ist sie offen für Neues? Kann er querdenken? Wie geht sie mit anderen Teammitgliedern im Verständnis- und Entwurfsprozess um? Welche Erfahrung hat er mit dem Prinzipien- und Praktikenrahmen von Clean Code Developer?
Was das Erfahrungsniveau von Entwicklern definiert, weiß ich nicht so genau. Wie lange ist einer Junior Developer, ab wann ist einer Senior Developer? Mit einem bin ich mir aber sicher: Dass Softwareentwicklung jenseits des Trivialen ein Prozess ist, der entscheidend durch Phasen der Gemeinsamkeit geprägt ist.
Das reine Codieren darf gern im stillen Kämmerlein allein oder zu zweit geschehen. Es ist eine eher umsetzende, ausführende Tätigkeit. Klar, dabei ist auch Kreativität gefragt, aber die kann keinen großen Schaden mehr anrichten ;-) Denn sie findet in einem Rahmen und auf einem Fundament statt.
Und dieses Fundament, dieser Rahmen, die sind das Ergebnis gemeinschaftlichen Denkens. Da sind viele Gehirne gefragt.
3 Kommentare:
Aber sind das nicht zwei unterschiedliche Paar Schuhe? Dem Autor ging es doch um eine evolutionäre (Junior -> Senior) Einzelentwicklung/bewertung eines Entwicklers. In deinem Beitrag geht es um einen Softwareentwicklungsprozess im Team. In einem nachhaltigen teamorientierten Entwicklungsprozess ist die gemeinsame Erarbeitung möglicher Lösungswege Teil eines obligatorischen Planungsmeetings. An diesem müssen sich alle Teammitglieder, ob Anforderung in Form einer User Story verstanden wurde oder nicht, beteiligen. Wie Du schon schreibst, dass trägt zu einer besseren Fehlerabdeckung, Teambuilding und eines möglichst breiten Verständnis des Systems bei. Dabei kann ein Planungsmeeting bei gut involvierten Entwicklern im Team manchmal sehr kurz sein, in einem gemischten Team aber auch länger dauern. Nun, die Kernfrage war ja "Was macht einen erfahrenen Entwickler aus?" - Da muss ich dem Autor zustimmen - Ein tiefes Verständnis der technischen aber auch "Business" Domäne. Damit hat er das Rüstzeug zum Entwickeln einer Lösung aus einer User Story. Diese in einem Planungsmeeting seinen Teammitgliedern zu erläutern und mögliche Alternativen gemeinsam zu erarbeiten ist das i-Tüpfelchen hin zu einem guten Team mit einem "gemeinsamen Geist", oder?
@Mike: Mir ging es - wie ich versucht habe klar zu machen - nicht um die Frage des Autors. Die und sein Statement, was ein mid-level Entwickler können soll, waren mir nur Anlass etwas darzustellen, was ich grad wieder erfahren habe:
Anforderungsverständnis und Entwurf sind Prozesse, die von einer Gruppe profitieren.
(Coden/Umsetzung profitiert nicht von einer Gruppe. Auch das habe ich wieder deutlich erlebt.)
Das bedeutet: Wer die Gruppe nicht ausnutzt, wer ihr keine Zeit gibt, der missversteht Softwareentwicklung. (Dass die Gruppe dabei am besten (vorsichtig) moderiert wird, will ich hier aber nicht auch noch anschneiden.)
-Ralf
Hallo Ralf,
hier ist mein Artikel zum CCD-Praktikum.
Kommentar veröffentlichen