SCRUM: un poème sur l'amour et la douleur



S'il est si bon, pourquoi tout le monde ne travaille-t-il pas uniquement selon cette méthodologie? Et ceux qui l'auraient implémenté montrent souvent un ScrumBut monstrueux. Un vrai SCRUM laisse des cicatrices, des blessures et des marques sur votre cœur, et maintenant je vais vous parler du mien.

Douleur de mêlée


Quand j'ai essayé pour la première fois, j'étais déjà jeune et je l'ai compris. Je suis juste tombé amoureux du livre Jeff Sutherland SCRUM: L'art de faire deux fois le travail en deux fois moins de temps. Certes, vers la fin, il m'a semblé un peu fanatique quand il a commencé à dire comment la méthodologie aide à l'école et en médecine. Mais j'ai vraiment beaucoup appris de Sutherland et j'ai immédiatement décidé d'essayer cette technique dans mon équipe. De rares douleurs commencèrent.

Retards et retards dans les réunions


Et si vous voulez rencontrer les stand-ups de 10 minutes et que quelqu'un a 15 minutes de retard? Tout d'abord, tout le monde l'attend, puis je veux entrer dans les détails, et le stand-up est retardé d'une heure. Et si quelqu'un n'a atteint aucune réunion, il est maintenant déconnecté des événements et demande à nouveau tout. Tout cela conduit au fait que personne n'a encore commencé à travailler, mais tout le monde est déjà fatigué d'une réunion visqueuse. J'ai d'abord dû travailler sur la discipline: sans délai, sans argument, sans entrer dans les détails. Pour être honnête pendant 5-10 minutes, la mêlée revigore, mais en quoi diffère-t-elle alors des réunions soviétiques traditionnelles du matin?

Différends, discussions détaillées et objectifs


Vous dites à l'équipe "nous avons 5-10 minutes", et ils vous disent que si nous ne réglons pas ce petit caquet, nous ne pourrons pas continuer, et cela nous bloquera tous. Ou pire encore: nous devons voir un concept et une stratégie généraux, nous ne pouvons pas travailler sans, alors écrasons les excréments dans un mortier. Une stratégie et un concept général sont nécessaires, ils doivent être pris en charge avant le début, s'ils ne sont pas là, alors vous ne devriez pas aller en cycles et ralentir le travail des conflits.

Nous sommes confrontés au fait qu'il est très difficile de démarrer un sprint sans comprendre l'objectif global de l'entreprise dans son ensemble:

Scrum master: "Formulons l'objectif du sprint: mesurable, compréhensible, réalisable!"
Sceptique: «Et pourquoi cet objectif devrait-il être juste cela? Où l'as-tu trouvée? "
... et il y a eu une dispute pendant une heure.

Scrum master: «L'objectif de notre produit est d'éliminer les personnes des mesures. Disons l'objectif du sprint! »
Peppy: "Entaillons un mini-module qui prendra les compteurs et les placera dans l'assiette."
Sceptique: «Eh bien, non, mais soudain, il s'avère que c'est un travail supplémentaire, vous devez comprendre le projet dans son ensemble. Je veux garder tout le projet à l'esprit! »
Scrum master se tire une balle dans la bouche avec un fusil de chasse ... Je

réécrirai brièvement les conditions de départ du sprint:

  1. Pas de retards
  2. Pas de passes
  3. Sans retarder la réunion
  4. Aucun argument
  5. Pas de petites pièces
  6. L'objectif global est clair, avec lequel toute l'équipe est d'accord.
  7. Il y a une volonté que le mini-sprint soit erroné et que le but du sprint soit mal choisi.

Tout ça fait très mal, beaucoup de douleur!

Gardez tout le projet à l'esprit!


... le Scrum master qui vient de reprendre ses esprits en soins intensifs tombe à nouveau dans le coma ...

Il n'y a pas de projet et ne peut pas être dans la tête, car le monde autour change constamment. Tout dans ma tête n'est qu'une illusion. Pas besoin d'avoir peur de faire trop de choses inutiles et de mal dans le cadre du sprint. Nous progressons par petites étapes, il y a donc toujours la possibilité de corriger les erreurs. Que d'argumenter pendant deux semaines, rattrapons deux sprints pendant ce temps, faisons une erreur, testons les hypothèses et gagnons le combat!

C'est pourquoi nous laissons tous les différends et la démocratie au sprint de la planification. Quand le sprint a commencé, ne discutons pas - les résultats nous jugeront très bientôt. Prêt pour le changement fait partie du Manifeste Agile!

Ne me dites pas ce que vous avez fait hier!


Lorsque vous et votre équipe courez un sprint dans la mêlée, alors vous avez un côté qui reste derrière vous! De plus, souvent en stand-up, tout le monde est amené à dire qui a fait quoi hier. Pourquoi donc? Oui, car il est beaucoup plus difficile de dire ce que vous voulez faire aujourd'hui, comment cela vous rapprochera de l'objectif du sprint et ce qui vous bloque.

Soit dit en passant, si nous ne discutons que des plans pour aujourd'hui, alors il n'y a pratiquement rien à dire. L'avenir a beaucoup moins de personnes chargées d'émotions que le passé. Sprint regarde vers l'avenir. Si vous suivez ce principe, les stand-ups ne prendront pas plus de 10 minutes.

Difficultés de toilettage


Lorsque les singes mangeaient suffisamment et sexaient, ils s'assoient pour peigner les insectes de la laine de l'autre. Les membres de l'équipe, comme eux, réalisent de petites tâches avec les jambes du flux général, en essayant de les rendre aussi courtes que possible.

Il s'avère souvent que la tâche n'est pas correctement planifiée lorsque le travail a déjà commencé. Personne ne veut rien ratisser. En conséquence, tout le monde pleure de larmes sanglantes parce qu'il est trop paresseux au début. Plus la tâche est petite, plus il est compréhensible et difficile de se tromper.

Je m'assois généralement avec des développeurs en dehors du sprint et je lis chaque histoire utilisateur à haute voix en chœur.

L'équipe elle-même choisit les tâches!


Mais c'est une vraie douleur pour les scoops. Comment? Après tout, il est beaucoup plus facile d'affecter des tâches directement. Comme vous le savez, le soviétique, c'est-à-dire que le peuple russe n'est pas prêt pour la démocratie, il y aura du chaos!

Et puis il s'avère qu'il y a des tâches savoureuses et intéressantes, mais des tâches ennuyeuses et routinières. Et cela arrive aussi: il y a votre tâche, vous êtes spécialisé dans cela. Et puis tout à coup, quelqu'un qui n'est pas noyau le saisit sous votre nez, car c'est tellement savoureux et intéressant.

Laissons ça faire mal aux managers, mais lorsque les membres de l'équipe choisissent leurs propres tâches, nous obtenons de meilleures performances et une meilleure qualité.

... Scrum master sourit sans laisser de coma ...

Fonctionnalité croisée


Le commandement des forces spéciales peut être un médecin, un opérateur radio, un commandant, un mécanicien. Mais que faire si quelqu'un est tué? Ensuite, leurs fonctions seront reprises par d'autres combattants. Ce principe est utilisé dans l'équipe SCRUM afin qu'il n'y ait pas de «goulots d'étranglement». Si tout est bloqué sur l'un ou l'autre, alors le reste de l'équipe devrait quitter son travail et entreprendre des tâches inhabituelles pour lui.

Scrum fait beaucoup souffrir votre fierté professionnelle: "J'ai étudié pendant tant d'années pour ne pas visser la tringle à rideau."

Les échecs


Bien sûr, mon premier sprint s'est soldé par un échec. Et presque chaque premier sprint avec une nouvelle équipe se solde par un échec. Le plus souvent, la raison en est que l'objectif de sprint a été mal formulé. Il s'avère que c'était inaccessible et incompréhensible, l'équipe a surestimé sa force et la majeure partie du travail a été bloquée par le client.

La chose la plus intéressante est une rétrospective d'un sprint échoué lorsque le temps est écoulé et que les objectifs ne sont pas atteints. Non, non, nous ne prolongerons pas le sprint pour la journée, non, nous ne travaillerons pas la nuit! Nous reconnaissons l'échec et nous analyserons ce avec quoi nous nous sommes trompés, ce qui s'est passé avec succès et ce qui pourrait être amélioré.

Habituellement, après un tel débriefing, tout le monde se rassemble et le prochain sprint est super réussi. Dans la deuxième rétrospective, toute l'équipe commence à ressentir un véritable buzz du travail, et donc de la vie en général. Vous vous fixez des objectifs mesurables, réalisables, compréhensibles, mais complexes et maintenant vous êtes ravis de leur réalisation.

Le fait que le sprint soit terminé avec n'importe quel résultat réduit l'anxiété et vous permet de vous concentrer sur les tâches locales, ce qui améliore la qualité de l'exécution.

... wow, nos Scrum Masters passent déjà des soins intensifs à la thérapie, le coma derrière ...

SCRUM est comme une flamme, il vous brûle quand il fait chaud


Épuisement professionnel! Scrum est le meilleur moyen d'accélérer! Si vous ne faites pas de pause après chaque sprint, tout le monde se fatiguera rapidement, les stand-ups deviendront une routine et le travail glissera dans la poubelle complète.

La satisfaction de vivre vient lorsque vous fixez des objectifs audacieux, combattez, échouez, remettez-vous sur pied et obtenez des résultats. Vous ne pouvez pas vivre dans ce mode pour toujours. Ils ont terminé le sprint - ont pris une pause d'une semaine: ils ont ratissé des tâches de routine, sont partis en vacances, sont passés à d'autres projets et ont repris des forces pour une nouvelle bataille. Pour retomber amoureux, vous devez lécher un peu les blessures de l'expérience précédente et vous êtes prêt. Bien que beaucoup soient attirés par le polyamour, et c'est la polybole!

Nous connectons le client à SCRUM


Même si le client n'est pas programmeur, il va se défoncer, je vous le promets! Seul tout doit être honnête. Un véritable SCRUM: vous ne pouvez pas jeter les pièces importantes, transformant tout en ScrumBut impie. Objectif du projet, carnet de commandes, objectif de sprint, l'équipe sélectionne les tâches et donne une évaluation, des stand-ups quotidiens, des rétrospectives, des pauses entre les sprints. Si au moins quelque chose en est jeté, alors tout cesse de fonctionner et le client est déçu par une méthodologie flexible.

Soyez comme Sutherland, soyez fanatique quand on vous dit: "Oh, tout cela est si gênant, SCRUM est bon, nous allons y travailler, mais il n'est pas nécessaire de suivre tous ses principes."

Souvent, les membres de l'équipe me disent: "Comment puis-je le faire, car le client verra le travail inachevé et jurera." Exactement! Plus le prototype est rugueux - plus il est facile de critiquer, plus tôt vous entendez des critiques - moins vous consacrez de temps et d'efforts aux modifications et améliorations!

C'est exactement ce que le Manifeste Agile nous dit: les

gens et l'interaction - des prises de position quotidiennes avec le client et l'équipe!
La collaboration avec le client, c'est aussi ça.
Volonté de changer - plus tôt nous apporterons des changements, mieux ce sera!

Si rose? Et où est la douleur? Ha! Partout: la direction a peur et reporte le début du sprint avec le client, craint que le client ne voie le travail non terminé. Il y a des clients qui veulent acheter le produit fini, comme dans un magasin, et ils pensent que les développeurs ont besoin des standups, pas eux. Et une fois, ils m'ont dit: "Nous voulons que tout soit flexible et que le prix soit dur"

Le prix est difficile, les tâches sont flexibles


... à cet endroit, le Scrum master conduit déjà la mêlée depuis l'hôpital à distance.
Attendez, est-ce vraiment possible? Les scientifiques se disputent encore à ce sujet ...

Montrez-moi un développeur qui n'aurait pas peur d'une telle déclaration. Dans sa tête, les perspectives d'un esclavage à vie naissent immédiatement. Le directeur général, avec ces mots, imagine la faillite de l'entreprise et l'effondrement de l'entreprise. Est-ce la principale douleur?

Il s'avère que vous pouvez faire des prix difficiles au client avec des tâches flexibles! Nous fixons l'argent, évaluons les tâches et comprenons lesquelles s'inscrivent dans le budget et lesquelles ne le sont pas. Ici, bien sûr, vous marchez le long de la lame d'un couteau. Le client discutera de l'évaluation des tâches individuelles et le gestionnaire tentera de donner une évaluation à la place des développeurs. Cela ne peut être fait que si tout le monde est d'accord avec le principe: celui qui l'évalue. Pour ce principe, vous devez vous battre avec la direction et les clients.

Projets à grande échelle


Certaines personnes pensent que le bonheur et le bonheur sont dans les grands projets.
Certains imbéciles se trompent, je suppose
qu'ils ne me trompent pas
Je sais que ce n'est pas vrai Je sais que ce n'est pas vrai
Les projets à grande échelle ne sont qu'un mensonge qui se termine par un visage bleu. Selon les statistiques, la plupart des petits projets survivent.
Pour changer le monde, une petite équipe suffit.

Habituellement, un projet à grande échelle réussi est une série de petits projets sympas. L'essentiel est un produit qui fonctionne, comme le manifeste le manifeste. Ne poursuivons pas l'échelle, mais commençons par un petit, mais rapide, flexible et fonctionnel.

Plus l'entreprise est grande, plus le projet est grand, moins elle a de flexibilité. C'est pourquoi SCRUM se concentre sur un petit projet qui peut être réalisé en un sprint de 1 à 3 semaines et une petite équipe de 2 à 7 personnes.

Dans le même temps, de très grandes équipes et de très grandes tâches peuvent toujours être effectuées selon une méthodologie flexible, pour cela, vous devez tout découper en petites tâches et en petites équipes.

Dans le résidu sec:


  1. Le travail de mêlée fait mal.
  2. Il est nécessaire de travailler dans Scrum, car victoire garantie.
  3. Vous devez suivre la méthodologie clairement et fanatiquement sans vous glisser dans ScrumBut - c'est le plus difficile et le plus douloureux.
  4. Nous impliquons les clients et la direction dans SCRUM au maximum, ce qui n'est pas aussi douloureux qu'il y paraît.
  5. Nous avons coupé tous les projets à grande échelle en petits, bien que cela fasse beaucoup de mal.

Sources de plaisir:


  1. Manifeste pour le développement de logiciels agiles
  2. Qu'est-ce que ScrumBut?
  3. Chanson SCRUM HURTS

Une explication de la douleur, en particulier pour Masha:


La douleur est généralement que vous devez changer tout ce à quoi vous êtes habitué. La douleur provoque une sensation de perte de contrôle et un processus incontrôlable lorsque vous confiez vos tâches préférées aux membres de l'équipe et craignez qu'ils ne submergent le projet. La douleur survient lorsque vous entrez dans la gorge de votre propre chanson et que vous brisez des projets à grande échelle.

La douleur passe lorsque les tâches sont super petites et même le fakap féroce des participants ne remplit pas tout le projet. Cela devient plus facile lorsque vous cessez de vous inquiéter et que vous répandez de la paille sur l'ensemble du projet tout de suite, lorsque vous vous détendez et coupez une tâche à la fois.

All Articles