Êtes-vous vraiment Agile ?

Cet article est écrit par Jamie Buckley, responsable de l'ingénierie chez Foundry4, et a été initialement publié par Foundry4, un cabinet de conseil en technologie aidant les organisations à exploiter technologie pour résoudre les problèmes complexes d'aujourd'hui. Lisez l'article original ici et plus encore Foundry4 [** insights here**](https://foundry4.com/our- connaissances).

Voir Agile correctement est une révélation. Cela change votre vision des projets logiciels de la même manière qu'il est maintenant difficile d'imaginer devoir utiliser du savon, de l'eau et des mains pour laver vos vêtements depuis l'invention de la machine à laver.

Mais les entreprises et les projets logiciels éponymes « Agiles » échouent trop souvent. Pour le nouvel ingénieur logiciel, il y a un danger que cet outil incroyable pour livrer des projets logiciels réussis ne devienne donc empoisonné à leurs yeux.

**• Tu veux écrire pour nous? Jetez un œil au guide pour les contributeurs

Peut-être que le problème clé est qu'Agile ne résoudra pas vos problèmes, il les exposera simplement. Je n'aime pas les miroirs exactement pour la même raison, c'est inconfortable de voir vos défauts et imperfections vous être présentés...

Je décrirais Agile comme le processus de travailler en équipe, sur des petites pièces bien comprises de travail, pour obtenir un élément livrable desdits éléments de travail complet, fournissant une valeur commerciale incrémentielle. C'est un ensemble de principes directeurs, où la maîtrise et la maturité viennent en choisissant d'utiliser des modèles et des cadres plutôt que de les suivre aveuglément.

Travailler en équipe, et essayez de comprendre ce que vous construisez avant vous construit le. Ne mordez pas plus que vous ne pouvez mâcher. Assurez-vous que les changements de direction sont peu coûteux en examinant fréquemment ce que vous faites et ce que vous construisez. Si tout cela ressemble à du bon sens, c'est parce que c'est tout ce que devrait être Agile.

Les stand ups sont pour l'équipe

Les mots pour semer la peur dans le cœur d'un ingénieur logiciel :

Hier je l'ai fait… Aujourd'hui je le fais…

Comme il est de notoriété publique, la chose préférée de tout le monde est d'être obligé de parler devant un demi-cercle d'autres personnes, qui les regardent en silence, attendant leur tour. La meilleure partie est de savoir que chaque personne du groupe a entendu environ zéro pour cent de ce que vous venez de dire, étant beaucoup trop préoccupée par la répétition de ce qu'elle est sur le point de dire.

Evil Project Manager vous jette un regard menaçant et des éclairs crépitent au-dessus de vous.

Comment travaillez-vous encore sur cette histoire, alors qu'on ne l'a dimensionnée qu'à trois oranges et une papaye ?

J'exagère légèrement, mais ce n'est pas une situation inconnue, surtout si vous détestez parler devant d'autres personnes.

Si quelqu'un vous fait dire le format "hier je l'ai fait, aujourd'hui je le fais", ne vous sentez pas mal pour ce que vous ressentez. Ce n'est pas Agile, c'est un KPI. Vous ne travaillez pas dans une société de logiciels, vous travaillez dans un centre d'appels, où vous devez faire x ventes par jour, sans compréhension plus large du contexte. Si vous obligez votre équipe à faire cela, sachez simplement qu'ils vous en veulent et font des grimaces dans votre dos.

L'erreur commise ici est simple. Le format « hier, aujourd'hui » sert à s'assurer que tout le monde est aussi occupé que possible, ou à opposer un membre de l'équipe à un autre. Mais l'accent doit être mis sur le travail du sprint, pas sur l'individu.

Voici une autre façon de procéder :

_Ensuite, la fonction submersible au safran. Je vois que c'est encore en développement. Paul, comment ça va ?*

Paul : En fait, j'ai rencontré quelques problèmes, je pense que cela va être plus de travail que prévu.

Je vois, peut-être que quelqu'un d'autre dans l'équipe peut vous aider en s'associant avec vous ? John? Ça te dérange d'aider ?

Discussion. Problème. Solution. Les Beatles font correctement Agile...

Peut-être que ce processus révèle que vous ne passez pas assez de temps à peaufiner vos histoires ou que votre définition de prêt fait défaut. Peut-être que cela révèle qu'un pic (travail exploratoire dans le temps) aurait dû être fait pour bien comprendre le problème. Cela révèle peut-être que les estimations sont trop optimistes. Quoi qu'il en soit, c'est quelque chose à discuter au rétro (l'exercice rétrospectif à la fin d'un sprint où vous examinez ce qui s'est bien / mal passé).

Le mot « expose » ici, est l'élément clé. Agile suppose que vous travaillez dans un environnement sans ego, où tout le monde se soucie de faire le travail et est heureux d'aider les autres à résoudre leurs problèmes. Cela suppose que l'équipe a l'autorité et l'autonomie pour identifier ce qui gêne et résoudre les problèmes.

Le défi du raffinement

Si vous avez choisi une fonctionnalité sur laquelle travailler et que les informations sur le ticket font défaut, il y a des problèmes plus tôt dans la chaîne. Je suis sûr que beaucoup d'ingénieurs auront une certaine expérience lorsqu'on leur demandera d'écrire quelque chose du genre :

_Construisez un truc qui fait ça

Suivi d'un e-mail à mi-parcours des travaux qui dit.

Attends non, sauf dans ce cas où ça fait ça.

Ces exigences auraient dû être réglées à l'avance, et bonne chance au testeur qui n'était pas dans la chaîne de courrier électronique. Une partie du problème est que les gens ne sont pas doués pour décrire ce qu'ils veulent (demandez à n'importe quel professionnel de l'industrie de l'art), et les gens ne sont pas non plus doués pour demander aux gens de décrire ce qu'ils veulent.

Lutter pour décrire ce que vous voulez n'est pas un défaut de caractère personnel. Si vous êtes un nouveau propriétaire de produit, ne vous sentez pas mal que votre expertise dans votre domaine ne se traduise pas immédiatement en exigences concrètes, cela demande beaucoup de pratique.

Voir mon article sur BDD (Behaviour Driven Development) pour un outil potentiel à utiliser ici, ou simplement prenez n'importe quel livre sur BDD et des exemples de cartographie. À défaut, dessinez simplement des images de ce qui est nécessaire. Tout ce qui n'est pas une danse interprétative qui fournit un sens sans ambiguïté et traçable et suscite les bonnes questions est utile.

La profession d'analyste en génie logiciel est essentiellement l'application professionnelle d'avoir des conversations utiles, ce qui est plus difficile qu'il n'y paraît. C'est formidable, mais à moins que le raffinement ne puisse répondre de manière significative aux questions, il ne fait qu'introduire une nouvelle couche à blâmer dans la chaîne lorsque les mêmes problèmes se produisent. Toutes les parties impliquées ont besoin d'une volonté de s'asseoir et de comprendre le problème, d'un cadre pour saisir la compréhension et de poser les bonnes questions.

Pire encore, parfois le raffinement peut simplement être des gens d'affaires et techniques dans une pièce ensemble, pensant à tort qu'ils sont d'accord les uns avec les autres. C'est tout aussi mauvais que de ne pas avoir de conversation du tout, il y a une raison pour laquelle le célèbre "Trois Amigos" n'est pas "Deux Amigos".

Une solution simple ici consiste à élargir les types de personnes dans la pièce. Il devrait y avoir au minimum une personne qui parle affaires, une personne qui parle technologie, et un QA/testeur/qui sera invité à vérifier éventuellement que les deux langues parlées correspondent.

Ces personnes devraient pouvoir être en désaccord à l'amiable. Les raffinements devraient ressembler à un argument amical pour tout travail non trivial. Le BDD est excellent ici car il fournit un langage commun avec lequel les trois parties peuvent régler leurs désaccords.

Vous vous amusez déjà ?

Ce qui précède ne fonctionnera pas toujours. Une partie de la nature d'Agile consiste à accepter que les choses tournent mal, que les logiciels soient difficiles et que nous tâtonnons tous dans une certaine mesure dans le noir. Si vous avez l'impression qu'Agile n'est qu'un ensemble sans fin de doutes, « faisons-nous ça bien ? réunions, c'est parce que la gestion d'un projet est difficile. (Waterfall n'était pas mieux à cet égard, c'était juste l'équivalent d'un couple marié mettant ses sentiments en bouteille jusqu'à ce que l'un d'eux empoisonne les œufs brouillés …)

Sans cadre pour mettre en évidence et résoudre les problèmes, un exercice négatif peut émerger où des équipes ou des individus se blâment mutuellement.

C'est la faute de l'entreprise de ne pas avoir expliqué ce qu'elle voulait

C'est la faute de l'ingénieur logiciel pour avoir mal compris ce qui a été demandé

C'est la faute du testeur d'avoir laissé ce bug s'infiltrer

Tout cela est réactif et n'aidera pas. Asseyez-vous dans une pièce, discutez de ce qui, selon vous, s'est mal passé dans histoire récente, c'est-à-dire le dernier sprint. Puis proposez ce qui pourrait être amélioré. Écoutez ce que les gens disent et soyez ouvert à l'idée de changer votre façon de travailler.

Peut-être que l'entreprise n'a pas compris à quel point ce qu'elle demandait était complexe à livrer.

Peut-être que les ingénieurs sont trop enthousiastes pour créer des trucs sympas et ne pensent plus à créer un MVP étroitement ciblé. Bien sûr, je n'ai moi-même jamais été coupable de cela...

Peut-être que les testeurs ont du mal à comprendre ce qui a été réellement demandé au milieu des factions en guerre et du chaos.

Dites ce que vous pensez, dites ce qui vous dérange et dites ce qui vous aiderait. Faire quelque chose de bien ensemble en équipe pour célébrer un sprint réussi. Nous avons la chance de travailler dans ce qui est fondamentalement un métier amusant. Agile devrait vous faire dire qu'hier vous avez apprécié votre journée de travail et qu'aujourd'hui vous vous éclatez. — Jamie Buckley

Nous voulons savoir ce que vous pensez de cet article. Pitch an article à nous ou envoyez vos commentaires à hello@aphysical.co

(Crédit photo : Unsplash)