Wenn etwas getan werden muss, sei es eine neue Aufgabe oder Hilfe bei einer bestehenden Aufgabe, ist eine reflexartige Reaktion, die ich oft in freier Wildbahn gesehen habe, die Suche nach einer Person, die dies erledigt .
Hier sind einige zufällige Beispiele dafür:
" Ich muss die Protokolle sehen, mit wem kann ich sprechen? "
" Ich möchte, dass dieser Patch zusammengeführt wird, wer kann mir helfen? "
" Ich möchte, dass sich diese Schaltfläche anders verhält, wer kann daran arbeiten? "
Manchmal würden die Leute davon ausgehen, dass ein einzelner Schauspieler immer verfügbar ist und darauf wartet, eine bestimmte Aufgabe auszuführen (" Wenn ich die Protokolle sehen möchte, gehe ich zu Josh, er würde mir immer dabei helfen ").
In anderen Fällen würden die Leute davon ausgehen, dass immer ein einziger Router verfügbar ist (" Wenn ich etwas implementieren möchte, kann mir dieser Manager, Bob, immer helfen, die richtige Person für den Job zu finden ").
Manchmal werden die Aufgaben nach dem Zufallsprinzip zugewiesen (" Ich werde zufällig Aufgaben zugewiesen (irgendwie) " - Bester Weg, Entwicklungsarbeit in Projekten aufzuteilen und zuzuweisen? ).
Ich denke, dass dies umgangssprachlich als "Push" bezeichnet wird.
Andererseits scheinen einige Entwicklungsmethoden (Lean, Scrum, Kanban) den „Pull“-Ansatz zu bevorzugen, wenn die Aufgaben nicht an eine bestimmte Person (und manchmal durch eine Weiterleitungsperson) übergeben werden, sondern irgendwo (in einem Kanban Board, in einem Scrum Backlog, etc.), die von den Teammitgliedern abgeholt werden.
Ich frage mich, was sind die Vorteile des „Pull“-Ansatzes? Es könnte nützlich sein, sie aufzuzählen.
Ich gehe davon aus, dass der "Push"-Ansatz nicht nur direkt, sondern auch unmittelbar ist .
(Zum Beispiel, wenn jemand auf dich zukommt und sagt: „ Hey, Joe, können wir das heute später machen? “).
Der „Pull“ hingegen erfolgt nicht nur indirekt über die Warteschlange als Vermittler, sondern auch verzögert . Aufgaben können sich in der Warteschlange ansammeln und darauf warten, im Laufe des Tages ausgewählt zu werden, oder auf ein Planungsmeeting warten.
Wir Menschen haben ein begrenztes Arbeitsgedächtnis . Immer wenn jemand mit einer Aufgabe auf uns zukommt, müssen wir eine Menge Zeug in unser Arbeitsgedächtnis laden und in die andere Problemdomäne wechseln. Dies erfordert Zeit und Gehirnleistung (ich erinnere mich, dass ich eine Studie darüber gelesen habe, dass für einige Programmierer das Wechseln von Aufgaben eine begrenzte Ressource ist, sie können nur eine Handvoll solcher Wechsel pro Tag erleiden).
Wir brauchen das Arbeitsgedächtnis zum Denken, je weniger davon wir für die anstehende Aufgabe haben, desto schlechter wird unsere Leistung sein ( vgl ), also ist es schädlich für alles, woran wir gearbeitet haben, wenn wir etwas davon ausleihen, um eine andere Aufgabe zu besprechen.
Und wenn es einer Person gelingt, uns mit der Frage zu überraschen , verlieren wir wahrscheinlich den aktuellen Status insgesamt !
Und wenn wir versuchen, zwei Dinge gleichzeitig zu halten, die Aufgabe, an der wir gearbeitet haben, und die Aufgabe, mit der wir konfrontiert wurden, werden wir wahrscheinlich auch die zweite vermasseln. Wir könnten ihm zu wenig Aufmerksamkeit und Arbeitsgedächtnis schenken, seine Komplexität nicht richtig einschätzen, unsere Fähigkeiten nicht beurteilen, den Kontext und das Gesamtbild nicht erfassen usw.
Der „Pull“-Ansatz ermöglicht es uns also, unsere Arbeit besser zu planen und neue Aufgaben und aufgabenbezogene Fragen zu akzeptieren, wenn unser Arbeitsgedächtnis bereit ist, sie aufzunehmen.
PS vgl. http://blog.ninlabs.com/2013/01/programmer-interrupted/
Einige von uns können in einen Zustand der Hyperfokussierung eintreten, der Flow genannt wird.
Ich denke, dass es bei Flow darum geht, die richtige Balance zwischen unseren kognitiven und emotionalen Anteilen zu halten. Es ist ein enger Kreislauf, in dem das, was wir tun, uns auch begeistern wird, was unsere Kreativität, unseren Entdeckergeist, unsere Gewandtheit und alles andere, was uns motiviert , fördert .
Dieses Gleichgewicht ist sehr effektiv, aber auch prekär.
Die Aufgabenzuweisung kann stressig sein. Es erzwingt einen Wechsel vom kreativen zum planenden und verwaltenden Gehirn. Es unterbricht den Flow leicht.
Dies könnte der Grund sein, warum Schaffer die „Freiheit von Ablenkungen“ als eine der Anforderungen aufführt .
Der Vorteil des „Pull“-Ansatzes ist also, dass wir damit niemandes Flow brechen müssen.
Die Aufgabenzuweisung ist oft mit Ungewissheit verbunden. „ Kann ich das? Habe ich die Zeit? Will ich morgen daran arbeiten? Gibt es Konsequenzen, wenn ich bestehe? .
Ungewissheit ist stressig. Einige Studien zeigen, dass es schlimmer ist als Schmerzen .
Interessanterweise kann eine subtile Aufgabe ( „ Würdest du daran denken, mit mir daran zu arbeiten? “ ) noch mehr Unsicherheit ins Bild bringen.
Ein noch stärkerer Stressfaktor ist der Mangel an Transparenz. Wir sind verdrahtet, um das soziale Umfeld um uns herum zu untersuchen. Ob bewusst oder unbewusst, wir messen, wo wir stehen, wie nützlich wir für das Team sind und ob unsere Beziehungen sicher sind. Manche Menschen sind deswegen eher besorgt als andere ( vgl ), aber Sicherheit in Beziehungen gehört neben Nahrung und Fortpflanzung zu unseren Grundbedürfnissen ( vgl ).
Der „Pull“-Ansatz bringt Transparenz ins Team. Wir wissen, was los ist, wer an welchen Aufgaben arbeitet, was erledigt wird und was sich verzögert.
Die direkte Aufgabenzuweisung findet hingegen oft unter dem Teppich statt.
PS Mehr zu diesem psychologischen Sicherheitsaspekt in Duhigg, What Google learning from its quest to build perfect team .
Wie Dijkstra es ausdrückte , lohnt es sich, „ seine Aufmerksamkeit auf einen bestimmten Aspekt zu richten “.
Die Auswahl der Aufgaben ist definitiv ein separater Aspekt. Oder besser gesagt eine Gruppe von Aspekten. Wir sollten die Ziele der Aufgabe klären und diskutieren, prüfen, ob die Aufgabe wirklich erforderlich ist, ihre Priorität einschätzen, einige Komplexitätsschätzungen erstellen, verschiedene Wege zum Erreichen des Ziels analysieren (Cialdini zitiert eine Studie, die zeigt, dass Unternehmen die Optionen methodisch bewerten und darüber nachdenken die Risiken jedes einzelnen sind im Durchschnitt erfolgreicher als Unternehmen, deren Prozess darin besteht, ins Getümmel zu springen).
Die Aufgabenverteilung während der Entwicklung ist wichtig, sicherlich das „intelligente Denken“ wert, von dem Dijkstra spricht.
Der „Pull“-Ansatz ermöglicht es uns, uns auf diese wichtigen Anliegen zu konzentrieren.
Unser Gehirn wird durch Zeit und Umgebung sowie andere Hinweise abgestimmt. Meistens entwickeln wir Verhaltensmuster, die durch diese Hinweise ausgelöst werden (vgl. „ Besetzung “). Sie können sich das als Prefetching vorstellen .
Dies erleichtert unsere Aktivitäten.
Das klassische Scrum erfordert, dass die täglichen Meetings zur gleichen Zeit stattfinden. Das hilft den Menschen nicht nur, dort zu sein, sondern spielt auch mit den Zeit- und Ortshinweisen, sodass unser Verstand die Art von Aktivitäten optimieren kann, die die Planung und Aufgabenverteilung mit sich bringt.
" Personen Aufgaben zuzuweisen ist eine implizite Behauptung, dass Sie (der Zuweisende) es besser wissen als sie (die Zuständigen). Selbst wenn dies zutrifft, ist es für eine Person immer noch leicht, Anstoß zu nehmen. Meistens ist dies jedoch nicht der Fall stimmt. Menschen kennen sich selbst am besten. Menschen sind am besten darin, sich selbst Aufgaben zuzuweisen. Und deshalb führt es fast immer zu einer suboptimalen Arbeitsverteilung unter den Mitgliedern eines Teams, wenn eine Person anderen Menschen Aufgaben zuweist. “ - Pitfall of Scrum: Assigning Aufgaben von Mishkin Berteig .
Alles ist einfach, wenn wir nur einen Entwickler haben. Aber sobald wir zwei oder mehr davon haben, machen wir Fehler bei der Aufgabenverteilung.
Angenommen, wir haben eine Entwicklerin, die immer an Problem X gearbeitet hat, und wir weisen ihr einfach die X-bezogenen Aufgaben zu. Was könnte möglicherweise falsch laufen?
Außer vielleicht ist diese Entwicklerin plötzlich beschäftigt, sie interessiert sich nicht mehr für Problem X und steht vor einem Burn-out, Sie verpassen vielleicht eine Gelegenheit für andere Entwickler, das System besser kennenzulernen, andere Entwickler fühlen sich vielleicht ausgeschlossen, es gibt vielleicht weniger Anreiz, Designentscheidungen zu überprüfen und gegenseitig zu befruchten, wird es weniger Interesse daran geben, was mit X los ist, und daher weniger Motivation von Fellowship usw. Viele Fallstricke für einen einfachen Kinderspiel, nicht wahr?
Entwickler sind keine vereinfachten Roboter, sie wissen wirklich am besten, wenn es um die Auswahl ihrer Aufgaben geht.
Der „Push“-Ansatz setzt normalerweise eine Autorität voraus und benötigt diese. Es unterteilt das Team in Beauftragte und Beauftragte. Diese Konfiguration bringt oft die verwandten Muster der menschlichen Psychologie ins Spiel.
Die Zuweiser könnten sich dem Eltern-Ich-Zustand der Transaktionsanalyse annähern, der " ... im Wesentlichen nicht wahrnehmungsfähig und nicht kognitiv ist. Er ist einfach eine konstante und manchmal willkürliche Grundlage für Entscheidungen ... Er funktioniert gültig, wenn ausreichende Informationen für eine Entscheidung eines Erwachsenen vorhanden sind ist nicht vorhanden, wirkt aber bei bestimmten Personen trotz adäquater Erwachseneninformation " (Claude Steiner).
Mit anderen Worten, die Zuweiser könnten erwarten, befolgt zu werden, unabhängig davon, wie willkürlich ihre Entscheidungen sind.
Die Zugewiesenen könnten in ähnlicher Weise die unterwürfige Einstellung oder andere Konfigurationen annehmen, die mit dem Eltern-Ich-Zustand des Zuweisenden kompatibel sind. (vgl. Robert C. Ginnett - Crews as Groups: Their Formation and their Leadership)
Versuche, von diesem Schema abzuweichen, könnten zu plötzlichen Konflikten und Verwirrung führen.
Der „Pull“-Ansatz ist in dieser Hinsicht weniger riskant, er neigt dazu, das Team in Richtung des bewussten Erwachsenen-Ich-Zustands zu ziehen, anstatt das Zusammenspiel von Autoritäten anzuzapfen, die an die Eltern-Kind-Ich-Zustände gebunden sind.
Um die Aufgaben in der Warteschlange zu präsentieren, müssen wir sie oft vorbereiten. Schreiben Sie eine User Story, erstellen Sie einen Tracker-Eintrag, heften Sie einen Sticker an ein Kanban-Board.
Dieses Stück, auch wenn es kurz ist, könnte als Grundlage für die Aufgabendokumentation dienen. Wir können das Tracker-Problem aus dem Code referenzieren oder der Aufgabenkarte auf einem Board Details hinzufügen.
Als ich über effektives Zeitmanagement recherchierte, fand ich bei einigen Autoren den Gedanken, dass es am wichtigsten ist, einen Weg zu finden, das unnötige Zeug auszusortieren.
Streichen Sie Dinge, die Sie nicht wirklich brauchen, von Ihren To-Do-Listen und Sie werden plötzlich feststellen, dass tatsächlich Zeit für die Dinge bleibt, die wichtig sind.
Eine ähnliche Idee findet sich beim Projektmanagement und bei der Priorisierung. Für ein gesundes Projektdesign und eine gesunde Entwicklung kann es entscheidend sein, die WON'T-Priorität zu haben. Nein zum Feature-Creep sagen. Spreu vom Weizen trennen.
Nun, dies ist mit dem "Push"-Ansatz sehr schwer zu bewerkstelligen. Es ist schwer, nein zu sagen, wenn man eine Aufgabe bekommt. Wenn es zugewiesen wird, erwarten wir , dass es wichtig sein muss (aufgrund der sehr sozialen Interaktion, die in die Aufgabe investiert wird). Die Aufgaben stapeln sich in Entwicklerwarteschlangen. Entwickler sind ständig beschäftigt und/oder vergesslich.
Beim „Pull“-Ansatz, insbesondere der iterativen Planung, kommt das Trimmen ganz von selbst. Die Aufgaben in der Warteschlange konkurrieren um die Iteration miteinander. Indem sie gegeneinander gestellt werden, entwickeln sie eine natürliche Priorität. Nur eine Handvoll der wichtigsten Aufgaben wird in Übereinstimmung mit den Iterationskapazitätsbeschränkungen ausgewählt.
In der schlanken Produktion gibt es ein „Stop the Line“-Prinzip ( cf ): Wenn etwas mit Ihrer Entwicklungspipeline nicht stimmt, finden Sie es besser heraus und beheben es, anstatt herumzustolpern und zu versuchen, das Problem zu ignorieren.
Beim „Push“-Ansatz sind einige Probleme schwer zu entdecken. Der Aufgabe fehlen möglicherweise sinnvolle Informationen, die Leute haben möglicherweise überhaupt keine Ahnung, warum sie wichtig ist, es kann in Bezug auf die Motivation wenig weitergehen, die Aufgabe ist möglicherweise zu groß oder zu komplex usw. usw., aber wenn die Aufgabe zugewiesen wird, am meisten Entwickler werden sich trotz der Hindernisse durchschlagen. Das könnte eine gute Sache sein. Aber wenn wir das Management verbessern, Hindernisse aus dem Weg räumen und „ Projekte um motivierte Personen herum aufbauen “ wollen, funktioniert die stoische Arbeit möglicherweise rückwärts.
Beim "Pull"-Ansatz wird das wesentliche Feedback in das System eingebaut. Wenn Sie eine Aufgabe ankündigen und niemand sie übernimmt, wissen Sie, dass Sie ein Problem haben.
Vielleicht ist das Ziel hinter der Aufgabe nicht klar, vielleicht muss es nicht wirklich umgesetzt werden, vielleicht hast du den Kontakt zum Team verloren usw. usw. Was auch immer es ist, du musst „anhalten“ und es reparieren .
Menschen neigen dazu, zu vereinfachen. Es ist ein wesentlicher Bewältigungsmechanismus ( cf ). „ System 1 neigt dazu, eine schwierige Frage durch eine einfachere zu ersetzen “ ( Thinking, Fast and Slow ).
Eine dieser Vereinfachungen besteht darin festzustellen, ob wir in einem bestimmten Kontext für uns selbst denken müssen oder ob wir einfach den Entscheidungen anderer folgen können. Wir können nicht erwarten, dass ein Entwickler immer zwischen den beiden wählt (weil diese Wahl immer wieder zu treffen ist langsam und nicht effektiv). Es ist wahrscheinlicher, dass sie entweder den selbstorganisierenden oder den Follower-Ansatz annimmt.
„ Der Vorteil, den ein Kommandant durch fortgesetztes persönliches Eingreifen zu erreichen glaubt, ist weitgehend illusorisch. Indem er sich darauf einlässt, übernimmt er eine Aufgabe, die eigentlich anderen gehört, deren Wirksamkeit er damit zerstört. Er multipliziert auch seine eigenen Aufgaben bis zu einem Punkt, an dem er sie nicht mehr alle erfüllen kann. “ – Helmut von Moltke .
„Entscheidend ist trotz Technik und Bewaffnung der Wert des einzelnen Soldaten. … Das Schlachtfeld erfordert Soldaten, die unabhängig denken und handeln können, die jede Situation kalkuliert, entschlossen und mutig nutzen können und die verstehen, dass der Sieg von jedem Einzelnen abhängt. “ – Truppenführung ( Wikipedia ).
Der „Push“-Ansatz drängt Entwickler dazu, Follower zu werden. Wenn das Management wichtige Entscheidungen trifft, sich um wichtige Kommunikation und Zeiteinteilung kümmert, würden die meisten Entwickler damit beginnen, diese kognitiven Funktionen an das Management zu delegieren.
So sehen wir in der Praxis, dass der „Push“-Ansatz oft dazu führt, dass Manager mit unterschiedlichem Mikromanagement überfordert werden.
Der „Pull“-Ansatz hingegen lädt die Teammitglieder zum eigenen Denken ein. Es wird meist als Weg zu den sich selbst organisierenden Teams genannt.
Wohlgemerkt, ein selbstorganisiertes Team braucht immer noch Führung und Management, aber Führungszeit wird für sinnvolle Themen aufgewendet (Motivation, Sinnstiftung, Festlegung der Ziele und Fristen, Beseitigung von Hindernissen usw.).
PS Es muss beachtet werden, dass "Pull" nicht jedermanns Sache ist. Es funktioniert nur, wenn das Team kulturell dazu passt, viel Vertrauen und Bescheidenheit herrscht und die Menschen bereit sind, Verantwortung in die Hand zu nehmen. Wie in Valves Handbuch für neue Mitarbeiter erwähnt wird, erfordert „Pull“ möglicherweise Mut und Wissen, „um nicht auszuflippen“.
Pull-Ansätze optimieren den Ablauf (wie schnell Aufgaben von „in Bearbeitung“ zu „erledigt“ wechseln), während Push-Ansätze für eine 100-prozentige Auslastung optimieren (dadurch sicherstellen, dass jeder jederzeit etwas tut).
Schauen wir uns ein Beispiel an. Wir haben zwei Entwickler, A und B, und 8 Aufgaben, 1-8, sortiert nach Priorität.
Wir weisen A 1, 3 und 5 sowie B 2, 4 und 6 zu und lassen 7 und 8 im Rückstand.
Wir beginnen mit A, das an 1 arbeitet, B, das an 2 arbeitet.
Ich nehme an, Sie sprechen von kleinen Aufgaben. In diesem Fall besteht ein Vorteil darin, dass Personen, die auf der Suche nach Arbeit sind, sofort eine Aufgabe übernehmen können.
Anscheinend bitten Sie auch um Anleitung zum Umgang mit diesen Anfragen:
Ich schlage vor, dass Sie einen klar definierten Prozess haben, wie Sie diese Anfragen stellen und wann Sie sie annehmen können. Der einfachste Weg, Ihnen bei der Entscheidung zu helfen, ist eine „Anfragevorlage“, die der Anforderer ausfüllen muss, damit die Anfrage akzeptiert wird. Einige Felder können Folgendes sein: Was, Warum, Beschreibung, vorgeschlagene Frist und alle besonderen Dinge im Zusammenhang mit Ihrem Domainproblem. Das hilft ihnen zu überlegen, ob ihre Anfrage sinnvoll ist!
Die Überwachung und Protokollierung dieser Aufgaben ist wichtig für:
Alle nicht dringenden Anfragen sollten während der nächsten Sprintplanung analysiert werden. Dann können Sie es jemandem zuweisen, je nachdem, wie beschäftigt er sein wird, und dann mit einer Frist zurückkommen.
Die kurze Antwort ist, dass wir hohe Kosten für die Unterbrechung von Personen zahlen (Kontextwechsel). Wenn Sie möchten, dass die Mitarbeiter effizient arbeiten und sich in ihrer Arbeitsumgebung wohlfühlen, dann ist es Sache des PM oder des agilen Äquivalents (je nach Methodik – Scrum Master, wer auch immer), Entwickler zu schützen.
Das ist politisch nicht immer möglich. Es wird immer bevorzugt, wenn Produktivität und gute Arbeit geschätzt werden. Und manchmal treten Notfälle auf, und diese Unterbrechung ist unerlässlich. Aber, um es noch einmal zu wiederholen, Pull ist mit deutlich höherer Produktivität und Zufriedenheit verbunden.
Nachtrag: Es ist wirklich schlimm für Entwickler, jedem Stakeholder ausgeliefert zu sein, der seine Kontaktdaten hat. Unterbrechungen sind störend (siehe längere Antwort oben oder erwägen Sie einen Kontextwechsel), auch wenn sich keine neue Aufgabe ergibt. Unabhängig von Push oder Pull möchte der PM (oder wer auch immer) in der Lage sein, der einzige Kontakt mit Stakeholdern außerhalb des Teams zu sein.
Nach meiner Erfahrung haben Softwareaufgaben oft sowohl versteckte Abhängigkeiten als auch versteckte Kontexte. Oft findet man einen Entwickler, der sich auf diesen oder jenen Bereich des Systems „spezialisiert“, weil er damit besser vertraut ist und die Arbeit schneller erledigen kann. Jeder andere im Team sollte mit jedem Teil des Systems vertraut genug sein, um in jedem Bereich „hochzufahren“ und die richtige Arbeit zu erledigen, aber eine spontane Spezialisierung ist oft zielführender. Offensichtlich müssen Sie das „Rühren des Topfes“ fördern, damit die linken Hände wissen, was die rechten Hände tun.
Das "Einreihen in Warteschlangen" funktioniert oft gut, solange Sie sich der Muster bewusst sind, nach denen diese Warteschlange am natürlichsten bedient werden könnte. Stellen Sie sicher, dass das gesamte Team immer die Dringlichkeit jeder Aufgabe versteht und wie sie das Projekt als Ganzes voranbringen wird. Die Teammitglieder selbst sind oft eine hervorragende Ressource, um Ihnen zu helfen, diese Entscheidungen in ihrem Namen zu treffen, da sie jeden Tag „dabei“ sind und über technisches Wissen und domänenspezifische Erfahrung verfügen, die Sie möglicherweise nicht wirklich haben nicht zu erwarten wäre.
MCW