Moin Moin,
ich suche ab sofort Software-Entwickler, IT-Abteilungen und insbesondere dich zu gewinnen fürs klare Verteilen von Rollen in Software-Entwicklungsprojekten.
Ich denke, dass in den letzten beiden Beiträgen→, einige Vorteile dieses Ansatzes aufgezeigt werden konnten. Zusammenfassend erwähnen möchte ich als Vorteile:
- reduzierter Stress / erhöhte Annehmlichkeit
- hohe Aufmerksamkeit durch SingleTasking
- zielführend / produktivitätssteigernd
- einfache Organisation
1) Würdest du diesen Ansatz gerne ausprobieren bzw. umsetzen? ( 5-Sterne-Skala ),
Ausführungen willkommen.
Lasst uns mittels Kommentaren austauschen.
Beste Grüße,
Mustafa
Austausch mittels E-Mail: mustafa.kevin.dwenger@posteo.de
Betreff: Austausch
Top comments (6)
Ich denke, es gibt ein Spannungsverhältnis zwischen dem Wunsch, ein kreuz-funktionales Team zu haben, und sich in einem Feld zu spezialisieren.
Die beste Auflösung ist meines Erachtens ein Team aus Spezialisten, bei dem jeder über ausreichend Wissen verfügt, um im Ernstfall in einer anderen Rolle einzuspringen, wobei transparent ist, dass diese keinesfalls mit der gleichen Effizienz wie ein Spezialist ausfüllen kann.
Der Blick über den Tellerrand ist gerade bei einem hohen Grad an Spezialisierung hilfreich.
Stimme dem zu.
Kennst du es, dass das innerhalb eines Projekts oder einer Projektphase die Aufgaben nach Rollen vergeben werden ähnlich wie auf einer Baustelle?
Was hälst du davon?
( Neues Projekt, neue Rollen für einen Entwickler möglich -> damit würde man Anreize geben über den Tellerand zu schauen )
Ich hatte bisher eigentlich nur zwei Varianten: weitgehend autonome Teams, bei denen sich jeder die Arbeit sucht, die er am Besten macht und sich ggf. noch wen oder welche dazu nimmt (pair oder mob programming), mit dem/denen das Wissen geteilt wird, oder Teams, bei denen die Arbeit pro Person geplant wird. Erstere sind mir lieber.
Meiner Meinung nach braucht es keine zusätzlichen Anreize. Gute Entwickler sind von Natur aus neugierig.
Den ersten Teil habe ich verstanden.
Jedoch bin ich mir nicht sicher was „bei denen die Arbeit pro Person geplant wird“ heißt.
Im Sinne der klassischen „BWLer-Schule“? -> Wir haben einen Arbeitsaufwand von x Stunden und y Entwickler die jew. z Stunden schaffen? Dann halt schauen wie viele Entwickler man aufs Projekt werfen muss ?
Danke für den Austausch.
Ja, so ziemlich. Das war die Antithese zu agiler Entwicklung. Es wurde UX, Entwicklung und QA hintereinander mit ein wenig Abstand geplant, auf Basis vorheriger Abschätzung. Dass das überhaupt funktioniert hat, war nur dem Team zu verdanken.
Ah verstehe.
Ja, ich denke, dass bei einem Team von Leuten, die ihr Fach verstehen, eine schlechte Organisation zwar ein Störfaktor sein kann, jedoch selten den Misserfolg entscheidet. Anders jedoch, wenn das Team nicht Stark im Fach ist.
:-)