Was ist die bevorzugte Anzahl von Aufgaben, die zugewiesen werden sollen?

Es spielt keine Rolle, Sie werden es sowieso falsch verstehen. Nur der Einzelne selbst weiß, was für ihn am besten ist, daher finde ich es ein bisschen anmaßend zu glauben, dass man das besser machen kann.

Die Antwort lautet also: nicht .

Das Zuweisen von Aufgaben ist schlecht für die Softwareentwicklung, da es unter anderem die Kreativität behindert und negativen Stress erzeugt. Erwägen Sie stattdessen, es umzudrehen und das Team Aufgaben auswählen zu lassen. Das macht es zu einem persönlichen Engagement , das mit viel größerer Wahrscheinlichkeit Erfolg hat. Es erzeugt auch ein bisschen gesunden Druck, weil sie es auf sich genommen haben, die Aufgaben zu erledigen, anstatt das jemand anderes für sie tun zu lassen.

Außerdem gewinnen Sie Zeit für wirklich wichtige Dinge, wie das Priorisieren von Aufgaben und das Beseitigen von Hindernissen für das Team.

Im Wesentlichen geht dies von "Push" zu "Pull".

Die Arbeit an mehreren Aufgaben gleichzeitig zahlt sich immer für Qualität aus. Eine Aufgabe nach der anderen zuzuweisen und auf den Abschluss dieser Aufgabe zu warten, bevor Sie eine andere Aufgabe zuweisen, ist ebenfalls keine richtige Option. Manchmal stecken Sie an einem Problem fest oder arbeiten lange Zeit an derselben Aufgabe, was Sie erschöpft macht.

Mein Vorschlag ist, mehrere Aufgaben zuzuweisen und ihm die Prioritäten im Voraus mitzuteilen. Lassen Sie dem Entwickler die Freiheit, zwischen Aufgaben zu wählen, solange er die erwartete Qualität liefert.

Ich bin derzeit der Scrum Master in einem kleinen Team, das mit Agile SCRUM arbeitet, und war zuvor der Leiter größerer Teams.

Ich denke, es ist am besten, die Leute ihre eigenen Aufgaben auswählen zu lassen – die Leute sich selbst Aufgaben zuweisen zu lassen – was meiner Meinung nach ungefähr analog dazu ist, Leuten Aufgaben zuzuweisen und sie sie fallen zu lassen und etwas anderes zu übernehmen. Der Fortschritt einer Aufgabe – ob jemand Hilfe braucht, eine Aufgabe ausgewählt hat, die er nicht erledigen kann, etc. – kann jeden Morgen in einem kurzen Meeting überprüft werden, bei dem jeder dem gesamten Team mitteilt, wie es ihm geht. Wenn Sie die Mitarbeiter ihre eigenen Aufgaben auswählen lassen, können sie Teile des Systems kennenlernen, die sie sonst möglicherweise nicht sehen, und sie befähigen, vernünftige Entscheidungen über ihre eigene Arbeit zu treffen und damit fortzufahren, ohne Sie jedes Mal fragen zu müssen, „was als Nächstes kommt“.

Ich denke, eine Aufgabe zu bekommen und von ihr erwartet zu werden, dass sie erledigt wird, bevor man irgendetwas anderes tun kann, kommt von einem Wasserfall-Ansatz. Die Idee dabei ist, dass wir diese Aufgaben identifiziert haben und dass dies die Aufgaben sind, die wir erledigen müssen, und sie müssen in dieser Reihenfolge erledigt werden, weil wir das so geplant haben. Das Problem dabei ist, dass sich beim Schreiben von Code oft (normalerweise) herausstellt, dass der Plan nicht alles abdeckt und Sie zusätzliche Aufgaben oder nicht so viele Aufgaben oder andere Aufgaben oder dieselben Aufgaben benötigen eine andere Reihenfolge.

Zusammenfassend: Ich denke, es ist am besten, flexibel mit Menschen umzugehen. Aber das ist nur meine Meinung :)

Erwägen Sie, irgendwo eine Aufgabenliste zu haben, auf der sich die Leute für Dinge anmelden und dann daran arbeiten können, wenn sie Zeit haben.

Ist insgesamt zu wenig Fortschritt für eine Person? Heben Sie die Zuweisung eines oder mehrerer Elemente auf und setzen Sie sie wieder auf die Liste.

Moderne Bug-Tracker können auch Aufgaben erledigen, was für andere einen guten Überblick darüber gibt, wie die Dinge vorankommen. Sie möchten eine, die in Ihr Versionskontrollsystem integriert ist, sodass Sie einfach eine Markierung in die Commit-Nachricht einfügen können, die automatisch vom Task-Manager aufgenommen wird.

Ich habe ein Board mit allen Aufgaben in der Reihenfolge ihrer Priorität. Die Regeln sind:

• Wenn Sie keine Aufgabe haben, ziehen Sie die oberste Karte ab und weisen Sie sich selbst zu.
• Wenn jemand anderes in den Teams mehr über das Problem weiß, wenden Sie sich an ihn, aber erledigen Sie die Arbeit selbst.
• Wenn Sie auf einen Blocker stoßen, bringen Sie ihn zu mir und machen Sie mit einer anderen Aufgabe weiter.
• Wenn Sie das Gefühl haben, dass Sie zu lange brauchen oder feststecken, lassen Sie sich von mir oder einem anderen Programmierer beraten. Wenn das nicht funktioniert, behandeln wir es als Blocker (bringen Sie es mir).
• Sie sollten immer nur an einer Aufgabe arbeiten.
• Sie können Karten nur überspringen, wenn Sie derjenige sind, der am besten über das Problem Bescheid weiß.
• Sie können das Programm nach Bedarf koppeln.

Alle Aufgaben werden auf maximal 1-2 Arbeitstage reduziert.

Dies funktioniert nur in einer Gruppe, die den Gruppenbesitz haben möchte und keine unterschiedlichen hochspezialisierten Rollen hat (z. B. Flash-Entwickler, DBA, Programmierer für eingebettete Gerätetreiber usw.).

Meine Meinung zu diesem Thema ist: Es kommt darauf an.
Es hängt vom Entwickler ab. Beispielsweise gibt es Entwickler, die die Freiheit der zweiten Methode zusammen mit dem zusätzlichen Druck mögen, den diese Methode auf den Entwickler ausübt. Es übt zusätzlichen Druck auf den Entwickler aus, da er nicht dafür verantwortlich ist, eine Aufgabe rechtzeitig zu erledigen, sondern gleich mehrere. Ich bin so ein Entwickler, Zeitdruck plus die Freiheit, die Ziele in der gewünschten Reihenfolge zu erreichen, macht mich wirklich produktiv.
Es gibt jedoch andere Entwickler, die diesem Druck nicht standhalten und unproduktiv werden.

Was ich sagen möchte: Es gibt keine definitive Antwort, es hängt vollständig von Ihren Entwicklern ab und Sie müssen möglicherweise Ihre Methode für jeden einzelnen Entwickler ändern.

Es hängt stark von Ihren Codierern ab. Einigen müssen Aufgaben zugewiesen werden, andere sind nur produktiv, wenn sie ihre Aufgaben tatsächlich auswählen.

Es hängt auch von den Aufgaben ab: Denken Sie daran, dass Sie irgendwann ein paar Aufgaben zuweisen müssen, die niemand tun möchte, die aber noch erledigt werden müssen.

Eine Sache, die Sie tun sollten, ist eine einigermaßen vollständige Liste der Aufgaben. Geben Sie Ihren Teammitgliedern eine gewisse Flexibilität in dem Sinne, dass es ihnen erlaubt sein sollte, einige Aufgaben in kleinere, mundgerechte Teilaufgaben aufzuteilen, wenn sie dies für erforderlich halten. Dies wird ihnen ein stark erhöhtes Gefühl geben, ein Mitspracherecht darüber zu haben, was sie codieren werden.

Stellen Sie in dieser Liste sicher, dass klar ist, wem welche Aufgabe zugewiesen ist und welche Aufgaben von anderen Aufgaben abhängen. Wenn eine Aufgabe benötigt wird, um andere Aufgaben zu erledigen, muss allen klar sein, wer helfen oder nörgeln soll (je nachdem, ob der Beauftragte arbeitet oder nicht).

Sie möchten, dass sich Ihre Programmierer so weit wie möglich ihren eigenen Aufgaben widmen (sie werden produktiver) und sich gegenseitig helfen (sie arbeiten besser als Team).

Beginnen Sie also damit, sie ein paar Elemente mit höherer Priorität aus Ihrer Liste auswählen zu lassen; Dinge, die sie tun möchten, machen Sie ihnen klar, wie sich die Aufgaben auf die Arbeit anderer beziehen, und ermutigen Sie sie zur Kommunikation, während sie an Dingen arbeiten, die von der Arbeit der anderen abhängen. (Vermeiden Sie es, ihren Arbeitsplan mit Gruppenmeetings zu quälen: Sie können bei Bedarf problemlos Dinge bei einem Kaffee oder an den Schreibtischen der anderen besprechen.)

Ein Punkt, den Sie dabei im Hinterkopf behalten sollten, ist, sich um die schüchternen Mitglieder in Ihrem Team zu sorgen; Sie könnten daran interessiert sein, an dieser oder jener Aufgabe zu arbeiten, scheuen sich aber davor, weil jemand anderes mit einer größeren Klappe sich darum kümmern möchte. Identifizieren Sie sie schnell und erzwingen Sie die Chancen ein wenig, indem Sie sie regelmäßig zuerst ihre Aufgaben auswählen lassen.

Ihr Team wird ebenfalls einige Mitglieder umfassen, denen Aufgaben zugewiesen werden müssen. Gehen Sie dabei ähnlich vor wie bei den schüchternen Mitgliedern (meiner Erfahrung nach sind es häufig die gleichen). Der Trick dabei ist zu wissen, dass die meisten Menschen es zwar scheuen, Entscheidungen aus heiterem Himmel zu treffen, aber normalerweise gerne mit der Auswahl einer Option aus einer Reihe von Möglichkeiten konfrontiert werden. Was sich von Person zu Person unterscheidet, ist die Schwelle. Für einige ist es eine Vielzahl von Optionen; für andere ist es nur ein einziger. Versuchen Sie also, eine Zahl zu finden, mit der sie sich wohlfühlen. Fragen Sie dann in einem ersten Schritt, welche von dieser, dieser und jener Aufgabe sie lieber erledigen würden; und in einer Sekunde, ob es eine andere Aufgabe gibt, an die Sie nicht gedacht haben und die ihnen noch mehr gefallen würde. Dies wird ihre Angst hemmen und sie dazu bringen, ihre Aufgaben zu wählen, ohne es zu merken.

Ein weiterer Punkt, den Sie beachten sollten, ist, dass Sie gelegentlich fest sein müssen. Am Ende des Tages sind Sie der Chef und wenn sich niemand freiwillig für eine bestimmte Aufgabe meldet, müssen Sie sie direkt zuweisen. Es gibt natürlich höfliche Wege, dies zu tun, die Sie inzwischen sicher kennen.

Seien Sie aus dem gleichen Grund flexibel. Manche Aufgaben scheinen nie erledigt zu werden, denn wer sich freiwillig gemeldet hat, findet es schnell langweilig oder schwer oder was auch immer und beginnt, sich auf etwas anderes zu konzentrieren. Überwachen Sie dies und entfernen Sie diese Aufgaben bei Bedarf (sanft) von ihnen. Ihre Teammitglieder werden es zu schätzen wissen, wenn Sie ihnen ihre Aufgaben neu zuweisen, anstatt ihr Gesicht in der Öffentlichkeit zu verlieren („Entschuldigung, ich konnte nicht“).

Der Ansatz, den ich verfolgte, als ich ein Team leitete (6 Personen, 18-monatiges Projekt), das gut funktionierte und die Teammitglieder damit zufrieden zu sein schienen (es hätte mit einigen besseren Tools/Automatisierungen getan werden können, aber wir hatten keine das Budget für den Kauf von Bleistiften, ganz zu schweigen von einem Aufgabenverwaltungssystem), bestand darin, zunächst alle Aufgaben und Teilaufgaben zu identifizieren, die für eine Iteration zu erledigen waren, und dem gesamten Team eine grobe Schätzung des Schwierigkeitsgrads zuzuweisen. Dann würde ich diese Liste zurücknehmen, sie bei Bedarf verfeinern, Aufgaben priorisieren und Teammitglieder bestimmten Aufgaben zuweisen.

Jedes Teammitglied erhält dann seine gesamte detaillierte Aufgabenliste, priorisiert und mit Zeitschätzungen, Ergebnissen für diese Aufgabe usw., sowie eine kürzere Übersicht darüber, an welchen Aufgaben die anderen Teammitglieder arbeiten. Jeder hatte die Möglichkeit, sich an mich zu wenden, wenn er der Meinung war, dass die Zeitpläne geändert werden müssten oder die Ergebnisse nicht klar genug waren usw.

Jeden Abend schickten mir die Teammitglieder eine E-Mail mit den Teilaufgaben, an denen sie gearbeitet hatten und wie weit diese Aufgabe fortgeschritten war. Dadurch konnte ich sehen, wie gut unsere Zeitschätzungen waren, und im Auge behalten, womit die Leute ihre Zeit verbrachten. Wenn jemand viel Zeit mit etwas mit niedrigerer Priorität verbringt, während Aufgaben mit höherer Priorität nicht erledigt werden, dann würde ich mit ihm darüber diskutieren, warum er das Gefühl hat, dass er zuerst daran arbeiten muss, und sehen, ob es da ist war eine Möglichkeit, mit Aufgaben umzugehen, um sicherzustellen, dass Abhängigkeiten beendet wurden, bevor sie benötigt wurden.

Dies funktionierte besonders gut, da die Teammitglieder alles wussten, was von ihnen für eine bestimmte Iteration erwartet wurde, was ihnen half, bessere Design-/Implementierungsentscheidungen für ihre Module zu treffen (wir hatten ein Gesamtdesign, aber die Details wurden den Teammitgliedern überlassen die ein bestimmtes Feature implementierten) und Teammitgliedern eine einfache Zusammenarbeit ermöglichten, da sie genau wussten, wer an welchem ​​Feature arbeitete. Ich habe Anleitungen zum Auflisten von Prioritäten und Abhängigkeiten gegeben, es aber den Teammitgliedern überlassen, in welcher Reihenfolge sie an Aufgaben arbeiten möchten.