In einem repressiven Managementmodell wählt ein Leiter in der Regel Mitarbeiter entweder dümmer aus als er selbst oder diejenigen, die er auf die eine oder andere Weise „hypnotisieren“ oder erpressen kann. Sie suchen nach "Hunden", die leicht zu handhaben und leicht zu vergiften sind. Die idiotischen Anweisungen, die von oben kommen, werden unverändert weitergegeben, und diejenigen, die sie unten vertreten können, überleben, der Rest platzt. habr.com/post/124716
Ist alles so schlecht mit Teamführung? Ob man ein Scrum formell auferlegt, wenn niemand seine Bedürfnisse versteht und es nicht wirklich spürbar ist, oder seine Elemente schrittweise einführt, damit das Team seine Effektivität spürt.
Interessenkonflikte sind eine häufige Situation in Arbeitskollektiven und nicht nur in Programmierern. Und oft gibt es kein Recht und keine Schuld, es gibt einen Konflikt zwischen Erfahrung und Visionen. Wie man das Potenzial aller Mitarbeiter freisetzt und Synergien erzielt, wenn 1 + 1 = 11, nicht 2.
Inspiriert nach der Fußball-Weltmeisterschaft. Die Geschichte vom Rückzug von Scrum. Alle Ereignisse sind fiktiv, alle Zufälle sind zufällig. Eine verallgemeinerte und stark vereinfachte Situation.
Das Team besteht also aus Analysten, Front-End und Full-Stack-Back-End. Scrum nicht. Das Team besteht aus einem ziemlich kompetenten, abwechslungsreichen und erfahrenen Teamleiter mit weitreichenden Befugnissen. Das Management des Unternehmens delegiert ihm die volle Autorität.
Stellen Sie sich für eine Analogie vor, dass ein Projekt eine Fußballliga ist. das ganze Team mit einem Schleier, das heißt einem gescheiterten oder langwierigen Projekt. Erfolg wird als qualitativ hochwertiges und pünktlich geliefertes Produkt angesehen, dh die Spitzenposition des Teams in der Meisterschaft gemäß den Ergebnissen aller Spiele. Spiele sind Sprints. Sprint - eine Iteration im Scrum, bei der das Wachstum von Software erstellt wird. Es ist zeitlich starr festgelegt, wie ein Fußballspiel. Überblick über das erste Spiel (Sprint), die Situation ist ziemlich real.
Beginn der Arbeit am Projekt (Erste Hälfte, alles läuft gut, Torpunktzahl 1 - 0)
Die Pfeife und Spieler, die individuell genug Erfahrung haben, aber nicht zusammen spielen, machen ihren Job also sehr gut. Der Analyst legt die Aufgaben fest, das Frontend erstellt die Anwendung im Mok-Backend. Am Anfang läuft alles gut, Layout, Architektur des Projekts, Seiten werden schnell erstellt, der Kunde erhält schnell Ergebnisse, das Team erhält Feedback von ihm. Jeder ist glücklich.
Das Backend wird separat entwickelt, Architektur wird erstellt, eine Datenbank wird erstellt, ungefähre Methoden werden geworfen.
Nicht kundenorientiertes Backend (Gefährlicher Moment, Ziel, schlechte Unterstützung in der mittleren Zone, 1 - 1)
Der Analyst, der sehr gute individuelle Qualitäten aufweist, überträgt die Aufgabe an das Team, den Bildschirm und die Beschreibung.
Das Front-End empfängt einen Pass, setzt das Formular, schreibt den Client-Code und übergibt den Pass an den Fullstack-Token. Und erwartet so etwas wie:
Holen Sie sich / some / method
Fullstek-Backender (Mannschaftskapitän, auch bekannt als Teamleiter) nahm einen Pass und gibt:
In der Regel verfügen Full Stacks über geringe Kenntnisse in bestimmten Bereichen (einfach, weil sie physisch nicht alles tief abdecken können), aber sie sehen das gesamte Projekt als Ganzes. Sie sind gut in kleinen Projekten, in denen sie alles selbst erledigen, und in der Teamentwicklung ineffektiv.
Es gab eine Pause und Verwirrung, als der Teamleiter gefragt wurde, warum dies so ist, Schweigen und Ignorieren, weiß er, was er tut. Bei wiederholten Übertragungen und nachfolgenden Fragen, warum so. Antwort: "Vertrauen Sie mir, ich weiß, was ich tue, Sie haben keine Vision vom System als Ganzes." Während die Auslosung 1-1 ist. Und hier kann nichts getan werden, weder gegenüber dem Spitzenreiter noch gegenüber der Führung.
Schwache Teamarbeit (Information, Ziel, 2-1 Fakap führt)
Frontender denkt und belastet. Was müssen Sie auf den Bildschirm werfen? Er fragt noch einmal, aber die Interaktion bleibt nicht bestehen. Tim-Leader-Full-Stack-Beckender ist nervös, gestreute Antworten. "Denk nach!" "Es ist einfacher für mich, es selbst zu tun", "Kicker." Das Spiel bleibt nicht hängen, die Mannschaft verfehlt das zweite Tor.
Stärkung durch Teamentwicklung (Zeit ist nicht zugunsten des Teams, 2: 1-Punktzahl ist gleich)
Das Front-End zarte wenig über die Parameter, lernte die Richtung des Passes vorherzusagen, aber es gab immer noch eine Ehe im Spiel. Der Front-End-Anbieter nimmt nicht alles nach Gehör wahr und fragt nach Teamentwicklungswerkzeugen (Redmine, Jira, Trello). Führung wird sich treffen. Begonnen mit Aufgaben wie:
Gruß -> ??? (Welches Feld soll aus den Daten entnommen werden?)
Parameter 1-> ??? (Welches Feld soll aus den Daten entnommen werden?)
Parameter2 -> ??? (Welches Feld soll aus den Daten entnommen werden?)
Aus Gründen der Klarheit werden die Daten direkt bis zum Eintreffen aus dem Backend bereinigt und in verständlicher Form in HTML geworfen. Das Spiel hat sich stabilisiert, aber die Zeit läuft ab, das Konto ist das gleiche zugunsten des Fakap.
Verletzung, Umgestaltung des Codes (Das Team gewinnt zurück, verfehlt aber das Tor mit 3: 2)
Das Front-End ist verletzt und verlässt das Feld für eine Weile (geplanter Urlaub). Zu diesem Zeitpunkt kriecht das Back-End in den Front-Code, verbringt viel Zeit damit, ihn umzugestalten, und entwirrt die Daten aus dem Back-End heldenhaft direkt in HTML. Schnelles Ziel, großartig! Als Antwort erhält er Fehler vom Analysten und herausragende Aufgaben für den aktuellen Sprint. Ja ... das Team erhielt schnell ein Rückziel. Beckender fällt in die Liste der Torschützen. Frontender erholte sich schnell und war wieder im Spiel. Aber da die Pässe nicht gehen und der Teamleiter sich selbst verwaltet, ist die Front noch nicht stark involviert. Der Schlusspfiff, das Match ist vorbei. 3: 2 verlor die Mannschaft, aber vor dem nächsten Spiel (Sprints).
Sprint-Retrospektive (Analyse des ersten Spiels, Frontend auf der Bank)
In Scrum werden Sprints rückwirkend vom Scrum Master (Teamcoach) durchgeführt, um Probleme in der Anfangsphase und eine flexible Selbstoptimierung des Teams zu erkennen. Da er jedoch nicht im Verein ist. Frontender initiiert es. Versammelt alle Teilnehmer und erklärt den Irrtum, sich zu weigern, den Pass zu spielen, da ein Moment das Spiel des Teams während der gesamten Meisterschaft (Ende des Projekts) nicht verbessern kann, und bittet alle Teammitglieder, sich zu äußern. Als Reaktion darauf bietet der Teamkapitän - Teamleiter - Full Stack an, das Frontend auf ein anderes Projekt zu übertragen, da die Meinungen der Spieler niemanden stören. Die Mannschaft schweigt - auch die Clubleitung. Der Transfer wurde verzögert, das Frontend schwebte auf der Bank.
Wie betreibe ich das Clubmanagement? Tim Leader oder Scrum Master? Offene Diskussionen, Meinungsäußerungen oder alleinige Anweisungen des Teamleiters. In der Tat gibt es keine richtige Antwort. Um die Situation zu klären, müssen Sie einen Tester eingeben und das Spiel in einigen weiteren Sprints betrachten. Es hängt alles von der Größe des Projekts ab.
Epilog (die Zeit ist vergangen):
Vielen Dank für die Kommentare!
Was ist unser Leben? Das Spiel ...
Guten Abend im intellektuellen Club. Was? Wo? Wann? Der einzige Ort, an dem jeder Zuschauer mit seinem eigenen Verstand Geld verdienen kann ...
Also Stille in der Halle.
Sehr geehrte Experten (Scrama). Ich mache noch einmal darauf aufmerksam, dass der Artikel ganz am Anfang klar betonte, dass das, was das Team tat, kein Scrum war, sondern nur der Versuch, es zu einem Scrum zu bringen, beschrieben wurde.
Scrum ist wie Poker, es hat sehr einfache, aber sehr strenge Regeln. Gleichzeitig sind Poker und Scrum sehr schwierige Spiele.
Jetzt ist Aufmerksamkeit die richtige Antwort.
Dabei wurde eine sehr einfache und grundlegende Scrum-Regel verletzt. Es gibt nur wenige Rollen in Scrum und sie sind klar formuliert. Es gibt keine Rolle, die als Teamleiter bezeichnet wird. Die Aufgabe des Scrum Masters besteht darin, die Implementierung dieser Regel klar zu überwachen. Und stoppen Sie alle Versuche, es zu verletzen. Unterm Strich ging das Chaos vom Backend nach vorne und das Projekt stolperte.
Scrum ist ein flexibles Softwareentwicklungs-Framework. Das Framework basiert auf einer empirischen Methode (basierend auf Erfahrung) und ist für die Entwicklung von HIGH Value-Produkten in einer komplexen Umgebung vorgesehen. en.wikipedia.org/wiki/Scrum
Rund. 1: 0 - zugunsten der Zuschauer. Kenner machen eine musikalische Pause ... und machen sich bereit für die nächste Runde.