Welcher agile Prozess bringt das Team dazu, Aufgaben einzelnen Entwicklern zuzuweisen, anstatt dass Einzelpersonen Aufgaben für sich selbst zuweisen?

Du fragst:

1. Gibt es einen Prozess, der die Gruppe dazu anregt, Aufgaben einzelnen Entwicklern zuzuweisen? Die Aufgaben sollten als Teil einer Gruppenentscheidung und als Teil dessen, was als nächstes kommt, zugewiesen werden.

Was Sie tun müssen, ist, dem Team (denjenigen, die die Kommissionierung durchführen) zu erklären, worauf Sie abzielen. Dies kann sie dann ermutigen, die Aufgabe so aufzuteilen, wie Sie es erwarten.

Sobald sie den Nutzen Ihrer Verbesserung erkennen , werden die meisten von ihnen mitmachen.

Dann fragst du:

2. Wie kann ich mit den Vorkommnissen umgehen, wenn Leute herumkommen und Aufgaben von externen Ressourcen erhalten, auf diese Weise die Gruppenentscheidung, wer was tut, hacken? Ich frage mich irgendwie, ist das, was ich beschrieben habe, ein Unsinn? Welcher agile Prozess hält Entwickler davon ab, Aufgaben für sich selbst auszuwählen?

Während Agile die Effizienz fördert, erwarten Sie, kurzfristige Ineffizienz für langfristige Effizienz zu fördern.

Sobald Sie „Effizienz“ (neu) definieren, sollte es mit Ihrer Implementierung von Agile fließen.

Sie können Menschen nicht davon abhalten, die Regeln zu brechen, es sei denn, Sie wollen Polizist werden und Sie haben die Befugnis, Menschen zu bestrafen. (Selbst dann möchten Sie diese Art von Kultur wahrscheinlich nicht.) Aber Sie können sie ermutigen, nach Ihren Regeln zu spielen, und ihnen die Vorteile erklären.

Denken Sie daran, dass der gelegentliche „Regelbruch“ nicht das Ende der Welt bedeutet ; Manchmal ist es besser, kleinere Verstöße zu ignorieren, anstatt eine große Sache daraus zu machen und alle abzulenken.

Eine gute Idee ist es, ein Protokoll darüber zu führen, wann Ihre Implementierung „den Tag gerettet“ hat. Bsp.: Da x und y den Code kannten, brauchten wir bei x längerem Urlaub keine lange Übergabe.

Menschen daran zu erinnern, wie großartig Ihr System ist, hilft ihnen, es zu verstehen, und ermutigt sie, ihm zu folgen.

Mir ist kein Prozess bekannt, der Entwickler ausdrücklich davon abhält, ihre Aufgaben auszuwählen. Stattdessen fördern die meisten agilen Frameworks den Einsatz von selbstorganisierenden Teams .

Ein Aspekt der Selbstorganisation ist, dass das Team entscheidet, wie Aufgaben unter den Teammitgliedern verteilt werden.

Es wäre sicherlich legitim für ein Team, einen zufälligen oder pseudozufälligen Prozess der Aufgabenzuweisung auszuprobieren. Sie könnten es vielleicht als Experiment durchführen: Entscheiden Sie, wie sie den Erfolg messen wollen, probieren Sie den Ansatz für einen festgelegten Zeitraum (z. B. 4 Wochen) aus und bewerten Sie dann, wie der Ansatz am Ende gelaufen ist.

Allerdings wäre es in einem selbstorganisierten Team nicht angemessen, wenn eine Person über die Vorgehensweise bei der Aufgabenverteilung entscheidet und diese im Team durchsetzt. Das Team sollte alternative Ansätze diskutieren und einen Konsens über den Ansatz erzielen, den es ausprobieren möchte.

Wie kann ich mit den Vorkommnissen umgehen, wenn Leute herumkommen und Aufgaben von externen Ressourcen erhalten, auf diese Weise die Gruppenentscheidung, wer was tut, hacken? Ich frage mich irgendwie, ob das, was ich beschrieben habe, ein Unsinn ist? Welcher agile Prozess hält Entwickler davon ab, Aufgaben für sich selbst auszuwählen?

Wenn sich das Team für den Ansatz entscheidet, den es verwenden wird, ist es weitaus unwahrscheinlicher, dass es versucht, es zu umgehen. Das ist der Wert von selbstorganisierten Teams: Die Teams haben eine Zustimmung zum gewählten Ansatz und führen ihn daher eher gut aus.

Bei Agile geht es um sich selbst organisierende Teams. Das Team ist derjenige, der herausfinden kann, wie die Arbeit am besten zu erledigen ist, und normalerweise endet man mit einer Art Pull-System. Menschen nehmen Arbeit an, ihnen wird keine Arbeit zugeteilt.

Wenn das Team entschieden hat, dass es eine gute Idee ist, alle zu ermutigen , Aufgaben zu übernehmen, mit denen sie nicht vertraut sind, dann ist das eine Sache. Wenn Sie eine Praxis wollen, die sie davon abhält , Aufgaben zu übernehmen, mit denen sie vertraut sind, dann ist das eine andere Sache. Der erste Ansatz ist agil, der zweite ... ich bezweifle es .

Ich glaube nicht, dass es einen agilen Prozess gibt, der das tut, wonach Sie fragen, und das liegt daran, dass es nicht wirklich sinnvoll ist, es sei denn, Ihr Kontext ist besonders. Damit meine ich, dass die Arbeit mehr oder weniger aus dem gleichen Fachgebiet stammt, Ihre Teammitglieder haben Rollen aus diesem Fachgebiet, aber sie haben nicht nur die gleiche Erfahrung. Manche sind kompetenter, manche weniger. Das zu tun, was Sie vorschlagen, könnte in dieser Situation funktionieren, aber es kann nicht in allen Situationen funktionieren. Und der Grund dafür ist, dass Sie zwangsläufig eine Spezialisierung innerhalb des Teams haben werden.

Die Art und Weise, wie Sie die Frage formuliert haben, lässt mich glauben, dass Sie glauben, dass Spezialisierung ein Problem ist. Es ist nicht so lange, bis das Team alle Rollen innerhalb des Teams hat, um ihre Arbeit zu erledigen, dann ist das kein Problem . Teams liefern Software in Agile, nicht Einzelpersonen.

Spezialisierung wird zu einem Problem, wenn das Unternehmen Silos von Spezialisten hat, die von Teams und Projekten geteilt werden. Da haben Sie tatsächlich ein Problem, weil es eine externe Abhängigkeit ist und dem Team tatsächlich einige Rollen fehlen, um ihre Arbeit selbst richtig zu erledigen.

Es ist gut, Wissen zu teilen, es ist gut, Programmierungssitzungen zu zweit abzuhalten, es ist gut, dass die Leute den Überblick behalten und die Verantwortung für die Ergebnisse teilen, aber ihnen Aufgaben zuzuweisen, mit denen sie nicht vertraut sind, ist nicht unbedingt der richtige Weg. Es drängt sie aus ihrer Komfortzone und das ist eine Möglichkeit, Dinge zu lernen, aber treiben Sie sie zu weit und Sie werden ein Durcheinander an Ihren Händen bekommen, am Ende viel Frustration und sogar Mitarbeiterfluktuation verursachen. Wie gesagt, das funktioniert in bestimmten Kontexten, nicht in allen. Ich ermutige Sie, an das letzte Projekt zu denken, an dem Sie dies versucht haben, und die Fähigkeiten der Menschen und die Art der Arbeit zu berücksichtigen, und ich bin sicher, Sie werden feststellen, dass es nicht zu viele Variationen gab, nur unterschiedliche Erfahrungsebenen und Ansichten des großen Ganzen.

Um Ihnen ein weiteres Beispiel zu geben, stellen Sie sich vor, Sie haben einen Designer in Ihrem Team und einen Java-Back-End-Entwickler. Würden Sie dem Backend-Entwickler eine Designaufgabe aufzwingen, nur weil Sie eine Spezialisierung vermeiden wollen? Oder schlimmer? Würden Sie dem Designer eine Backend-Aufgabe geben? Das macht keinen Sinn.

Es gibt in der Tat ein Problem: bei der Arbeit an vorrangigen Aufgaben. Angenommen, der Designer ist beschäftigt, aber der Backend-Entwickler hat gerade etwas Arbeit erledigt und kann die nächste Aufgabe aus der Prioritätenliste übernehmen. Die nächste Aufgabe in der Reihenfolge der Prioritäten ist eine Entwurfsaufgabe. UPS! Jetzt muss sich der Entwickler umschauen, um zu sehen, welche anderen Backend-Arbeiten es gibt. Die zweite Aufgabe ist Back-End-Arbeit, also übernehmen sie diese Aufgabe. Aber das war die zweite Priorität, nicht die erste. Das ist ein Problem, oder? Aber Sie lösen dieses Problem nicht, indem Sie die Designaufgabe dem Back-End-Entwickler aufbürden.

Wenn Sie sich Sorgen über die Art und Weise machen, wie die Arbeit ausgeführt wird, oder wenn Sie ein gewisses Risiko festgestellt haben, dass Programmierer nur bestimmte Arten von Aufgaben auswählen, dann bringen Sie das Problem mit dem Team zur Sprache und lassen Sie es einen Weg finden, es zu beheben. Zwingen Sie keine bestimmte Arbeitsweise auf, es könnte andere/bessere Möglichkeiten geben, dies zu beheben, nicht unbedingt so, wie Sie es vorschlagen .

Im Allgemeinen sollten Sie sich darum kümmern, was das Team als Nächstes vorhat, und nicht genau, wer von den Teammitgliedern es tatsächlich tut.