Dans un modèle de gestion répressif, un leader sélectionnera, en règle générale, les employés soit plus stupidement que lui-même, soit ceux qu'il peut «hypnotiser» ou faire chanter d'une manière ou d'une autre. Ils recherchent des "chiens" faciles à gérer et à empoisonner. Les instructions idiotes venant d'en haut seront transmises par procuration sans modifications, et ceux qui peuvent les remplacer par la suite survivront, le reste éclatera. habr.com/post/124716
Est-ce que tout va si mal avec le leadership d'équipe? Que ce soit pour imposer une mêlée de façon formelle lorsque personne ne comprend son besoin, et qu'il ne se fait pas vraiment sentir, ou introduire ses éléments progressivement, pour que l'équipe ressente son efficacité.
Les conflits d'intérêts sont fréquents dans les collectifs de travail et pas seulement chez les programmeurs. Et souvent, il n'y a pas de droit et de culpabilité, il y a un choc d'expériences et de visions. Comment libérer le potentiel de tous les employés et obtenir une synergie lorsque 1 + 1 = 11, pas 2.
Inspiré après la Coupe du monde de football. L'histoire du retrait de Scrum. Tous les événements sont fictifs, toutes les coïncidences sont aléatoires. Une situation généralisée et grandement simplifiée.
Ainsi, l'équipe est formée, analyste, front-end, full-stack-back-end. Ne mêlez pas. L'équipe est formée d'un chef d'équipe assez compétent, diversifié et expérimenté, doté de larges pouvoirs. La direction de l'entreprise lui délègue pleine autorité.
Pour une analogie, imaginez qu'un projet est une ligue de football. toute l'équipe avec un feil, c'est-à-dire un projet échoué ou de longue haleine. Le succès est considéré comme un produit livré de haute qualité et en temps opportun, c'est-à-dire la première position de l'équipe dans le championnat selon les résultats de tous les jeux. Les jeux sont des sprints. Sprint - une itération dans la mêlée, au cours de laquelle la croissance du logiciel est créée. Il est fixé de manière rigide dans le temps, comme un match de football. Vue d'ensemble du premier match (sprint), la situation est bien réelle.
Début des travaux sur le projet (première mi-temps, tout se passe bien, score de but 1-0)
Ainsi, le coup de sifflet et les joueurs suffisamment expérimentés individuellement, mais qui ne jouent pas ensemble, font très bien leur travail. L'analyste définit les tâches, le front-end fait l'application sur le backend mok. Au début, tout se passe bien, mise en page, architecture du projet, les pages sont rapidement créées, le client reçoit rapidement les résultats, l'équipe reçoit ses retours. Tout le monde est content.
Le backend est développé séparément, l'architecture est en cours de construction, une base de données est en cours d'élaboration, des méthodes approximatives sont lancées.
Backend non orienté client (Moment dangereux, but, aide mal dans la zone médiane, 1 - 1)
L'analyste, montrant de très bonnes qualités individuelles, transfère la tâche à l'équipe, à l'écran et à la description.
Le front-end, reçoit une passe, compose le formulaire, écrit le code client, passe la passe au fullstack-bekender. Et attend quelque chose comme:
Récupérer / some / method
Fullstek-backender (capitaine d'équipe, alias chef d'équipe) a réussi une passe et donne:
En règle générale, les piles complètes ont des connaissances superficielles dans les domaines (simplement parce qu'elles ne peuvent pas tout couvrir physiquement), mais elles voient le projet dans son ensemble. Ils sont bons dans les petits projets où ils font tout eux-mêmes et sont inefficaces dans le développement d'équipe.
Il y a eu une pause et une perplexité, lorsqu'on lui a demandé pourquoi, le silence et l'ignorance, le chef d'équipe sait ce qu'il fait. Avec des transmissions répétées et des questions subséquentes, pourquoi. Réponse: "Faites-moi confiance, je sais ce que je fais, vous n'avez aucune vision du système dans son ensemble." Alors que le tirage au sort est de 1-1. Et rien ne peut être fait ici, ni pour le front-end, ni pour les dirigeants.
Faible travail d'équipe (informations, objectif, 2-1 fakap mène)
Frontender pense et tend. Qu'est-ce que vous devez lancer sur l'écran? Il demande à nouveau, mais l'interaction ne colle pas. Tim-leader-full-stack-beckender est nerveux, jonchent les réponses. "Pensez!" "C'est plus facile pour moi de le faire moi-même", "Kicker." Le jeu ne colle pas, l'équipe rate le deuxième but.
Renforcement par le développement de l'équipe (le temps n'est pas en faveur de l'équipe, le score 2-1 est le même)
Le front-end tendre peu à deviner les paramètres, a appris à prédire la direction de la passe, mais il y avait toujours un mariage dans le jeu. Le fournisseur frontal ne perçoit pas tout à l'oreille et demande des outils de développement d'équipe (Redmine, Jira, Trello). Le leadership va se rencontrer. Commencé avec des tâches telles que:
Salut -> ??? (quel champ prendre des données)
Paramètre 1-> ??? (quel champ prendre des données)
Paramètre2 -> ??? (quel champ prendre des données)
Par souci de clarté, les données sont nettoyées directement à l'arrivée du backend et sous une forme compréhensible sont jetées en html. Le jeu s'est stabilisé, mais le temps presse, le compte est le même en faveur du fakap.
Blessure, refactorisation du code, (L'équipe gagne en arrière, mais manque le but 3-2)
Le front-end est blessé et quitte le terrain pendant un certain temps (vacances prévues), à ce moment le back-end, rampe dans le code du front, passe du temps à le refactoriser et démêle héroïquement les données du back-end directement en html. Objectif rapide, super! Mais en réponse, il reçoit des bogues de l'analyste et des tâches en suspens pour le sprint actuel. Oui ... l'équipe a rapidement reçu un objectif de retour. Beckender tombe dans la liste des meilleurs buteurs. Frontender a rapidement récupéré et était de retour dans le match. Mais comme les passes ne vont pas et que le chef d'équipe se gère, le front n'est pas encore très impliqué. Le coup de sifflet final, le match est terminé. 3-2 l'équipe a perdu, mais avant le prochain match (sprints).
Rétrospective Sprint (Analyse du premier match, front-end sur le banc)
En mêlée, pour identifier les problèmes dans les premiers stades et l'auto-réglage flexible de l'équipe, les sprints sont effectués rétrospectivement par le maître de mêlée (coach d'équipe), mais puisqu'il n'est pas dans le club. Frontender l'initie. Rassemble tous les participants et explique l'erreur de refuser de jouer la passe, car un moment ne peut pas améliorer le jeu de l'équipe tout au long du championnat (fin du projet), et demande à tous les membres de l'équipe de s'exprimer. En réponse, le capitaine d'équipe - chef d'équipe - full stack, propose de transférer le front-end à un autre projet, car les avis des joueurs ne dérangent personne. L'équipe est silencieuse - la direction du club aussi. Le transfert a été retardé, le front planant sur le banc.
Comment gérer la gestion du club? Tim leader ou Scrum Master? Discussions ouvertes, expression d'opinions ou ordres uniques du chef d'équipe. En fait, il n'y a pas de bonne réponse. Pour clarifier la situation, vous devez entrer un testeur et regarder le jeu dans quelques sprints supplémentaires. Tout dépend de la taille du projet.
Épilogue (le temps a passé):
Merci beaucoup pour les commentaires!
Quelle est notre vie? Le jeu ...
Bonsoir, au club intellectuel. O?? Quand? Le seul endroit où chaque spectateur peut gagner de l'argent avec son propre esprit ...
Alors silence dans le couloir.
Chers experts (scrama). Encore une fois, j'attire l'attention sur le fait que l'article au tout début soulignait clairement que ce que l'équipe faisait n'était pas une mêlée, mais seulement une tentative d'afficher un brouillage était décrite.
Scrum est comme le poker, il a des règles très simples mais très strictes. Mais en même temps, le poker et la mêlée sont des jeux très difficiles.
Maintenant, l'attention est la bonne réponse.
Dans le processus, une règle de mêlée très simple et basique a été violée. Il y a peu de rôles dans la mêlée et ils sont clairement énoncés. Il n'y a pas de rôle appelé chef d'équipe. La tâche du Scrum Master est de contrôler clairement la mise en œuvre de cette règle. Et arrêtez toute tentative de le violer. En bout de ligne, le chaos du backend est allé à l'avant et le projet a trébuché.
Scrum est un cadre de développement logiciel flexible. Le cadre est basé sur une méthode empirique (basée sur l'expérience) et est destiné au développement de produits de HAUTE valeur dans un environnement complexe. en.wikipedia.org/wiki/Scrum
Ronde. 1-0 - en faveur des téléspectateurs. Les connaisseurs font une pause musicale ... Et préparez-vous pour la prochaine manche.