Wie wir es mit Mobbing versucht haben

Wenn Sie versuchen, Mobbing oder Mobbing in einer Suchmaschine zu finden, handelt es sich bei einem wesentlichen Teil der Ergebnisse um "psychologischen Missbrauch von Menschen". Daher ist es besser, sofort nach "Mob-Programmierung" zu suchen. In den Top 10 der Ergebnisse von Yandex (27.02.2019) gibt es derzeit nur einen Artikel auf Russisch (und dieser ist eine Übersetzung), aber es gibt viele Artikel auf Englisch. Wenn Sie sie fließend betrachten, sind die meisten von ihnen eine Theorie, keine Analyse eines praktischen Falls. Alle sagen, dass dies dem Team helfen wird, effektiver zu werden, Projektkompetenz lokal zu verteilen und Soft Skills in Menschen zu entwickeln. Ich selbst habe Mobbing in der Praxis während eines der Scrum-Trainings getestet und war ehrlich gesagt begeistert! Nach Rücksprache mit dem Team haben wir beschlossen, unsere Test-Mobbing-Sitzung durchzuführen.

Zu den Vorteilen dieses Arbeitsansatzes gehörten für uns Werte wie die Verbreitung von Fachwissen innerhalb des Teams und die Entwicklung zusätzlicher Fähigkeiten für jeden Teilnehmer. Nachdem wir ein Treffen zum Thema Mobbing organisiert haben, haben wir uns drei Ziele gesetzt: Erstens, Mobbing in der Praxis zu versuchen. Zweitens, um zu verstehen, welche Nachteile und negativen Faktoren in unserem Fall darin liegen. Drittens bestimmen Sie, ob es die oben genannten Werte in unser Team bringt.

Was ist Mobbing?

Der Begründer des Mobbings als Arbeitsstil von Woody Zuill beschreibt ihn wie folgt:

wundervolle Menschen, die gleichzeitig an einem Ort an einem Computer an einer Aufgabe arbeiten.

Das heißt, Mobbing ist ein Arbeitsstil, bei dem ein Team ständig zusammenarbeitet und sich gemeinsam auf Aufgaben „stürzt“. Gleichzeitig durchläuft die Aufgabe alle notwendigen Phasen ihres Lebenszyklus, und jedes Teammitglied arbeitet gleichzeitig mit allen daran. Auf diese Weise wird das Eintauchen und Verstehen der Aufgabe durch das gesamte Team erreicht.

Mobbing hat mehrere Rollen:

• Fahrer: sitzt an einem gemeinsamen Arbeitsplatz und macht genau das, was der Navigator ihm sagt.
• Navigator: Gibt dem Fahrer Anweisungen. Wenn er nicht weiß, was er tun soll, konsultiert er den Mob (den Rest des Teams) und sendet die erforderlichen Aktionen an den Fahrer.
• Mob: nimmt an der Entwicklung teil und teilt dem Navigator mit, was der Fahrer tun soll.
• PO (Product Owner): weiß genau, was passieren soll. Legt die gewünschte Richtung für das Team fest. Es kann ein Fahrer und Navigator sein.
• Moderator: Überwacht die Einhaltung der Regeln, kündigt Schichten an und parkt Ideen. Es ist wünschenswert, dass es eine Person in dieser Rolle gibt.

Mobbing besteht aus einer Sitzung, die aus Zyklen besteht, von denen jeder aus Schichten besteht.
Sitzung - Ein Zeitraum, in dem ein Team an einer Aufgabe arbeitet. Vor der Sitzung wird die Aufgabe ausgewählt und in Stufen unterteilt, und ihr Ziel wird festgelegt - was als Ergebnis erhalten werden muss, beispielsweise das Inkrement der Funktion.

Ändern - Das Zeitintervall zwischen dem Ändern der Rollen des Fahrers und des Navigators. Der Wechsel dauert in der Regel 15-20 Minuten. Kürzere Schichten tragen zu höherer Geschwindigkeit und größerem Team-Engagement bei.

Spielregel

Während der Schicht sitzt der Fahrer am gemeinsam genutzten Computer und tut genau das, was der Navigator ihm sagt. Das Team beobachtet und bespricht gegebenenfalls, was zu tun ist. Der Navigator strukturiert diese Diskussion und sendet dem Fahrer, was genau er jetzt tun muss. Der Fahrer hört nur auf die Anweisungen des Navigators und kann ihm Fragen stellen. Der Navigator kann die Frage an das Team senden. Der Moderator „parkt“ Ideen, die geäußert, aber aus dem einen oder anderen Grund nicht verwendet wurden.

Am Ende der Änderung gehen die Rollen des Fahrers und des Navigators in einer vorgegebenen Reihenfolge an andere Personen: Der aktuelle Navigator geht zum Mob, der Fahrer wird zum Navigator und die nächste Person aus dem Mob wird zum Fahrer. Wenn jedes Mitglied des Teams jede der Rollen besucht, schließt sich der „Kreis“, dh der Zyklus endet.



Nach der Mobbing-Sitzung teilte jeder von uns seine Eindrücke mit, auf deren Grundlage bestimmte Schlussfolgerungen gezogen wurden. Als Ergebnis haben wir ein Ergebnis erhalten, das ein Verständnis dafür vermittelt, wie und wann es besser ist, Mobbing zu verwenden und ob es zu unserem Team passt. Ich werde mit negativen Eindrücken beginnen.

Negativ

Manchmal ist die Rolle des Navigators nicht ganz klar. Irgendwann könnte beispielsweise der Analyst in dieser Rolle sein, und der Entwickler könnte der Treiber sein. Der Navigator erzählte erneut, was das Team ihm erzählte, und verstand aufgrund mangelnder Entwicklungserfahrung nicht vollständig, was dies alles bedeutet. Infolgedessen kam es zu Situationen, in denen der Navigator einfach keinen Sinn machte, dem Team Anweisungen zu geben, weil der Entwickler zunächst den Befehl hört. Warum braucht er also einen Vermittler? Zweitens versteht der Fahrer, wie er in dieser Situation handeln soll, aber gemäß den Regeln der Rolle sind ihm die Hände gebunden.

Wir haben auch festgestellt, dass der Navigator, wenn er auf die nächste Registerkarte in der Entwicklungsumgebung schauen muss, um den nächsten Schritt zu bestimmen, diese Idee äußern und warten muss, bis der Treiber die Registerkarte wechselt. Er selbst hätte dies getan, während er die Anfrage an den Fahrer richtete, wobei alle „so freundlich“ und „bitte-danke“ waren.

Die Schwierigkeit bestand darin, dass zwei Entwickler remote arbeiten. Zunächst wurde Zeit für einen Vorgang wie „Umschalten der Rechte auf den Cursor“ hinzugefügt, damit der Remote-Administrator etwas auf dem Bildschirm anzeigen und gleichzeitig nicht die Kontrolle über die Maus übernehmen konnte. Dazu musste das Konferenzsteuerungsfenster erweitert, der richtigen Person die Steuerung des Cursors ermöglicht und das Fenster minimiert werden. Es dauert nicht so lange, aber es lenkt sehr ab, wirft es aus einer Aufgabe heraus (in die es gerade erst eingetaucht ist) und stört im Allgemeinen. Infolgedessen musste der neue Navigator nach jeder Schicht den vorherigen fragen, was er jetzt tun wollte. Beide mussten sich daran erinnern, „synchronisieren“ und erst dann weitermachen.

Eine weitere Schwierigkeit aufgrund der „Abgeschiedenheit“ einiger Mitarbeiter sind ihre Nachbarn. Irgendwann beschloss ein Nachbar des Fernnavigators, Löcher in das ganze Haus zu bohren, sodass wir eine ganze Reihe von Begleitgeräuschen mit Verstärkung hörten. Wie Sie wissen, hat uns das überhaupt nicht geholfen.

Da wir zeitlich sehr begrenzt waren (eine Stunde pro Mobbing-Sitzung), waren unsere Schichten sehr kurz - jeweils 5 Minuten (so dass jeder Teilnehmer mindestens einmal Zeit hatte, diese oder jene Rolle zu besuchen). Es spiegelt sich meiner Meinung nach auch stark in den Fortschritten wider. Wie bereits erwähnt, waren alle Teilnehmer der Sitzung erst am Ende der Schicht (1-2 Minuten bis zum Ende) in die Aufgabe eingetaucht, und nach dieser kurzen Zeit wurden alle durch den Wechsel abgelenkt. Es ist klar, dass Sie auf diese Weise nicht viel tun werden.

Ein anderes Team hätte gerne mehr Zeit, um „still“ nachzudenken und Ideen zu diskutieren, aber häufige Verschiebungen provozierten den Versuch, mehr mit den Händen zu untersuchen, als theoretisch angenommen.

Wir haben nicht den einfachsten Fall für ein einstündiges Experiment genommen: eine Aufgabe aus einem anderen Projekt, das unserem Team nicht sehr vertraut war. Die meiste Zeit haben wir herausgefunden, wie dieser Code, den wir ändern müssen, im Allgemeinen funktioniert. Während der insgesamt 7 Arbeitsstunden (1 Stunde für jedes Teammitglied) haben wir wirklich nicht verstanden, auf welcher Seite wir uns dieser Aufgabe nähern sollten.

Es wurde festgestellt, dass das gesamte Team die Lösung des Problems unter einem bestimmten Gesichtspunkt sieht, einschließlich eines Testers. Wir schlugen vor, dass dies in Zukunft (wenn wir das entsprechende Stadium erreicht haben) die Objektivität des Testens negativ beeinflussen könnte, da wir alle wissen würden, wie es funktioniert, und unbewusst versuchen würden, Engpässe zu vermeiden. Leider ist dies nur eine Annahme.

Aber unsere andere Hypothese wurde bestätigt. Noch vor der Sitzung haben wir vorgeschlagen, dass es ein Rennen von Ideen geben wird, wenn Menschen mit unterschiedlichen Visionen bei der Arbeit an derselben Aufgabe auftauchen. Genau dies geschah: Einige Entwickler schlugen vor, das lokale Debugging mithilfe von Integrationstests durchzuführen, andere - indem sie den Geschäftsprozess, der geändert werden sollte, vollständig implementierten. Jede Seite brachte überzeugende Argumente vor. Wir sind aus dieser Situation herausgekommen, weil wir uns entschlossen haben, zuerst einen Ansatz zu versuchen. Wenn wir zum vereinbarten Zeitpunkt verstehen, dass diese Methode mehr Arbeit erfordert, werden wir eine alternative Option verwenden.

Die Einstellungen in der Entwicklungsumgebung erwiesen sich als Stolperstein: Jeder Entwickler ist mit seinen eigenen spezifischen Parametern vertraut. In diesem Fall gab es nur eine Entwicklungsumgebung, und natürlich mochten nicht alle die Einstellungen.

Es ist uns sogar gelungen, einen Erleichterungsfehler zu machen: Kurz vor Schichtende ging der zukünftige Fahrer zum Tee. Infolgedessen ging sein Navigator auch, um Tee zu brauen, und so verloren wir eine Zeitverschiebung.

Wie Sie sehen, sind einige negative Faktoren auf organisatorische Fehler zurückzuführen, aber sie haben gezeigt, wie man es besser macht und warum.

Positiv

Die Teilnehmer stellten fest, dass diese Art der Arbeit es Personen, die normalerweise Aufgaben vom Unternehmen erhalten, ermöglicht, diese zu analysieren und zu testen, sich mit dem Prozess der direkten Lösung dieser Probleme zu befassen. Sie sahen die Arbeit von der anderen Seite: Welche Schritte eine Aufgabe auf dem Weg zu ihrer Umsetzung durchläuft. Ihnen wurde klar, welche Aktionen die Entwickler ausführen, um zu verstehen, wie sie mit ihrer Lösung umgehen sollen. Somit sieht und versteht jeder, was gerade mit der Aufgabe passiert.

Für einige von uns ist klar geworden, warum Entwickler bei der Beschreibung einer Aufgabe häufig eine eingehendere Analyse benötigen und warum sie manchmal auf den ersten Blick ziemlich absurde und klarstellende Fragen stellen.

Zweifellos ist dies eine neue, wertvolle Erfahrung für jeden von uns. Darüber hinaus hilft eine solch ungewöhnliche Zusammenarbeit, das Team zu stärken, das heißt, sie dient als eine Art Teambildung: Zum ersten Mal sah jemand die direkte Arbeit der anderen Person und lernte seine Gedanken in einer bestimmten Situation.

Ergebnisse

Nachdem wir die gegenseitigen Rückmeldungen zur Sitzung besprochen hatten, kamen wir zu bestimmten Schlussfolgerungen.

Nach unseren Ergebnissen stellte sich heraus, dass man beim Mobbing nicht unbedingt mit dem gesamten Team oder zumindest nicht ständig arbeiten sollte. Wenn in unserer Realität das gesamte Team nur an einer Aufgabe arbeitet, werden keine Verhandlungen mit Auftragnehmern geführt und Benutzeranfragen werden nicht bearbeitet. Sie können dies natürlich tun, bis Ihre Schicht kommt, aber dann müssen Sie abgelenkt werden, zu der Aufgabe wechseln, die alle lösen, dann wieder aussteigen und sich daran erinnern, was Sie vor der Schicht angehalten haben.

Es ist notwendig, dass der Navigator etwas erfahrener ist als der Fahrer. Andernfalls stellt sich heraus, dass es sich um ein kaputtes Telefonspiel handelt, wenn der Navigator versucht, dem Fahrer buchstäblich zu überholen, was er gesagt hat, ohne vollständig zu verstehen, "was das alles bedeutet". Sie können beispielsweise die Rollen nicht nacheinander ändern. Wenn Sie Paaren keine leistungsstärkeren Navigatoren zur Verfügung stellen können, Sie den Menschen jedoch beibringen müssen, nicht nur entsprechend ihrer Spezialisierung zu arbeiten, ist die Paarprogrammierung unserer Meinung nach effektiver.

Wir hatten den Eindruck, dass Mobbing gut funktionieren würde, wenn neue Entwickler im Team auftauchten oder jemand im Team entschieden programmieren wollte. Wenn Sie dann Mobbing mit erfahrenen Entwicklern durchführen, werden Neulinge schnell in Teamprojekte eintauchen und allgemein anerkannte Prinzipien und Arbeitsregeln verstehen.

Auf die gleiche Weise können Sie an einer Aufgabe arbeiten, für die nur eine Person in einem Team über Fachwissen verfügt (ja, wir haben eine solche Person und ein solches Projekt), um das Wissen unter den anderen zu verbreiten.

Wir gingen davon aus, dass Mobbing gut für Tigerteams ist: Teams, die gebildet werden, um eine dringende Aufgabe zu lösen. Dies kann jedoch funktionieren, wenn sich das Team zumindest im selben Raum befindet und die Entwicklungsumgebung für die Mehrheit vorbereitet ist. Andernfalls geht aufgrund unnötiger Kommunikationsfaktoren Zeit verloren.
Wenn sich gerade ein Team gebildet hat und im Idealfall ein neues Projekt zusammen mit diesem gebildet wird, kann Mobbing gut funktionieren. In diesem Fall wird jeder Teilnehmer sehen, wie und warum bestimmte konzeptionelle, architektonische und andere Entscheidungen getroffen werden. Das Wissen über das Projekt ist unausgewogen.

Letztendlich werden Schichten länger benötigt. Mindestens 15-20 Minuten statt unserer 5. Und Sie müssen etwas mit der Regel tun, dass ein Fahrer nur die Hände eines Navigators sind, ohne eigenen Kopf.

Also haben wir versucht, in der Praxis unter den Bedingungen der Arbeit unseres Teams zu mobben. Einige Regeln haben uns gestört, etwas, das wir missverstanden haben, irgendwo haben wir Fehler gemacht. Trotzdem haben wir uns selbst gefühlt, was es ist, ob es möglich ist und ob wir in diesem Stil arbeiten müssen. Nach den Ergebnissen dieses Experiments haben wir die Werte, die wir für uns selbst als die wichtigsten identifiziert haben, nicht vollständig erhalten. Es ist zu bedenken, dass wir nur eine Stunde lang versucht haben, mit zu kurzen Schichten zu mobben, da diese Ergebnisse möglicherweise nicht die zuverlässigsten sind. Bei der Arbeit an "Vollzeit" -Mobbing treten einige Probleme nicht auf, und einige werden nach "Anpassung" an den Prozess überwunden. Wahrscheinlich haben wir es einfach nicht geschafft, in so kurzer Zeit die Werte zu erreichen, die wir brauchten. Um dies sicher zu wissen, lohnt es sich, Mobbing in anderen Situationen zu versuchen, aber dies wird eine ganz andere Geschichte sein.

PS
Sie können die folgenden Materialien zum Thema lesen und sehen:
GOTO 2017 - Mob-Programmierung: Ein ganzer Teamansatz - Woody Zuill
Woody Zuill - Ein Tag der Mob-Programmierung
Agilix Consulting Blog: Warteschlangen beenden und ein Team mit Mobbing beschleunigen