Blog Arolla

Depuis que je suis agile, je ne vais plus sur lequipe.fr

7208767112_2857ccf292_o

Introduction

Ça fait 7 ans que je fais du développement et je n’avais jamais travaillé dans un pool d’une vingtaine de développeurs suivant les préceptes agiles.

Quelle surprise à mon arrivée !!! Certains sont 2 derrière un seul pc, d’autres discutent à 3 ou 4 en griffonnant des schémas fumeux. J’ai, pour ainsi dire, commité ma première ligne de code après deux semaines de mission !!!

Je me demandais vraiment où j’étais tombé. Tout le monde était cool et détendu alors que j’avais été staffé parce qu’il fallait aller plus vite !!!

Mais où est le chef ? Comment supporte-t-il ça ?

Au bout de 2 mois j’ai compris. Dans une atmosphère amicale et sans pression, je n’ai jamais autant travaillé. Et content par-dessus le marché.

Je vais tenter de m’expliquer en quelques maximes vraies, marrantes et/ou symboliques.

Depuis que je suis agile, je ne vais plus sur lequipe.fr

Reprenons, depuis que je suis agile, je ne vais plus sur lequipe.fr. Mais pourquoi donc ?

Pour plusieurs raisons. La première, c’est que grâce à toutes les cérémonies comme on appelle ça en agile, l’information circule bien, chacun finit par avoir confiance en l’autre. Chacun reste à sa place. “Chacun son métier et les vaches seront bien gardées” comme l’explique la sagesse populaire.

Et nous les développeurs, on se concentre donc sur le développement. On est au cœur des développements. Quand il y a des questions, sur “comment on peut faire ça ?”, “et ça, ça fonctionne comment ?”, c’est nous qui sommes interrogés.

Ainsi, je me sens vraiment un rouage nécessaire dans la chaîne des responsabilités. Je ne suis plus le dernier exécutant. Je fais partie d’un équipage, comme sur un bateau. Et mon intérêt est que ce bateau navigue le mieux et le plus loin possible.

Autre point, mon outil de travail. Je vis avec au moins 8 heures par jour. Je le présente régulièrement à mes collègues internes ou externes au service. Pour mon bien être et ma fierté, je tiens à le garder le plus propre et le plus efficace possible.

Pour filer la métaphore maritime, si le résultat de mon travail est un bateau, alors ce bateau embarque équipage et clients. Je fais partie de l’équipage et je ne fixe pas le cap. Mais c’est moi qui équipe le bateau pour qu’il puisse arriver à bon port. Il en va de mon honneur et de mon plaisir que la traversée soit un bon souvenir pour chacun.

Mener toutes ces tâches à terme est un travail plaisant et prenant. Les initiatives et avis sont critiqués, appréciés mais jamais méprisés. Ainsi j’ai toujours quelque chose à améliorer, une tâche plus intéressante à faire qu’aller sur lequipe.fr. Vous avez déjà vu un marin aller sur lequipe.fr ?

Depuis que je fais du pair programing, je ne commite plus de alert(‘toto’);

Une technique intéressante du management agile est le pair programming. Ok, le titre du paragraphe est plus rigolo qu’autre chose. Mais elle recèle une vérité : il n’y a plus de code “oublié” dans mes commits ou dans ceux de mon binôme. Vous savez, la méthode écrite ou encore les variables mal nommées qu’on a utilisées pour tracer notre premier chemin, le code écrit à la va-vite pour arriver au plus vite à un premier résultat. Ce code qu’on ne voit même plus, le binôme le voit très bien. Il m’avertit avant que je commite.

Dans n’importe quel domaine, ceux qui en ont fait l’expérience se sont rendus compte que mettre ses idées en commun est plus efficace que travailler chacun de son côté.

Souvent lorsqu’on travaille seul, que l’on est à fond sur son code, on occulte une partie de l’objectif ou de la problématique. On perd un peu de vue l’ensemble du travail à effectuer.

Avoir à côté de soi quelqu’un avec un peu plus de recul, parce que n’ayant pas le clavier dans les mains, permet d’éviter de nombreux pas de côté. Les confrontations constantes de points de vue permettent en sus d’arriver plus rapidement à des conceptions cohérentes et pérennes. Les méthodes et variables sont mieux nommées et la responsabilité de chaque objet est plus clairement définie.

Depuis que je chiffre en points, je ne fais plus de bugs

On le sait, on est toujours confronté à des délais, quel que soit le domaine dans lequel on travaille. On est également toujours confronté à l’imprévu. On a tous fait un jour un chiffrage, puis un ou deux ou trois imprévus sont venus perturber notre glorieuse marche en avant. A quelques jours du jour J, alors que 90% du travail est terminé (les 10% restants représentant normalement 50% du temps total), la tentation est grande de faire “comme si” on avait terminé. Ça passe si facilement.

Le fait de chiffrer en points ôte cette barrière psychologique. L’absence de jour d’échéance permet de respecter une vraie DOD. On sait bien que le temps perdu ici sera rattrapé plus tard sans avoir besoin de truquer les chiffrages.

De ce fait, je ne suis pas obligé de bâcler mes tests, mes cas limites. J’ai le temps de penser à une conception viable. Je ne dis pas que chiffrer en points permet automatiquement de s’affranchir des contraintes de temps. Mais cela permet de mieux faire accepter aux maîtres d’œuvres les contraintes essentielles mais cachées de notre métier : faire les tests, gérer les cas qui ne devraient pas arriver, etc…

Sur le court terme, cela coûte sûrement plus cher. Mais nous qui avons tous travaillé quelques années savons pertinemment que c’est sur le long terme qu’on paye l’addition. Avec une conception réfléchie, des cas d’erreurs traités en amont, des tests bien pensés, on recule d’autant la date de péremption du produit.

Depuis que je fais régulièrement des démo, je ne connais plus l’effet démo

A la démo, on montre quoi ? On montre les stories validées. C’est quoi une story validée ? C’est une story démontrée à la personne l’ayant conceptualisée, ayant imaginé les cas d’utilisations et les cas d’erreurs. Donc, c’est bon, on est tranquille. La story est validée, elle a déjà été démontrée à la personne la plus à même de détecter les problèmes. Et une chose est sûre, c’est qu’un ordinateur, ce n’est pas timide. On peut donc montrer notre travail à une foule en délire sans problème, ça fonctionne. A nous la gloire.

Fini de passer pour un idiot. Les “autres”, les non développeurs ne nous prennent plus pour des attardés irresponsables qui compliquent les choses par plaisir.

Depuis que je vais en communauté de pratiques, je ne me demande plus “mais qui est l’andouille qui a pondu ça ?”

Lorsque l’on travaille en équipe, il arrive forcément un jour où on l’on doit faire évoluer le travail pensé par un collègue ou ex-collègue. La première pensée est parfois “ouahh c’est vachement bien pensé, j’ai presque rien à modifier”, mais plus souvent c’est “mais pourquoi, pourquoi c’est écrit comme ça ?” Le premier réflexe est de se dire “bon je vais tout refaire” mais on hésite parce que cela engage beaucoup de travail. Ok le chiffrage se fait en points, cela ne signifie pas pour autant qu’on fait ce qu’on veut comme on veut. Alors, dans un deuxième temps, après la déception vient le pragmatisme. Il est l’heure d’essayer de comprendre le code et son histoire. Et, souvent, s’il y a un problème dans le code, c’est qu’il y a eu un problème lors de la première, de la deuxième, voire la troisième écriture du code ou demande d’évolution.

Lors des communautés de pratiques, tout un chacun a le loisir de s’expliquer sur les problèmes rencontrés et/ou la façon dont il les a résolus. On peut d’une part donner son avis sur la résolution choisie ou simplement connaître le problème rencontré. C’est très précieux. Comme on dit en anglais, c’est le “collective code ownership”. Chacun connaît l’ensemble de l’application. Je ne dis pas que chacun la maîtrise, mais chacun la connaît. Et surtout chacun sait qui maîtrise ou a maîtrisé ce problème. Quel gain de temps et quelle sérénité !!!

Le deuxième avantage induit par les communautés de pratiques, c’est l’adoption de nouvelles librairies ou pratiques. L’argumentation visant à choisir telle librairie ou telle pratique permet une préemption rapide et efficace de ces nouveautés.

Conclusion

Le but de cet article n’est pas de faire une démonstration des bienfaits de l’agilité. Je suis trop novice en agilité pour me permettre de démontrer ou prouver quoi que ce soit. J’imagine mais je ne peux pas résoudre les écueils qu’ont probablement rencontrés certaines personnes essayant ou ayant essayé de mettre en place l’agilité dans leur société, leur service.

Le modeste but de cet article est de convaincre les sceptiques ou les chats échaudés de s’intéresser réellement à ces méthodes, de ne pas les rejeter après un échec vécu ou vu. Je pense que la façon de les mettre en place est très importante. Vous aurez constaté au cours de cet article que je me suis très peu appuyé sur la théorie “agile” mais je me suis intéressé surtout à la façon dont elles sont vécues par mes coéquipiers et moi. Je pense que c’est l’aspect le plus important.

“Très bien. Super. Le mec, il est content de lui, content de son travail, mais ça apporte quoi de plus réellement ?”

Rien que cet aspect est déjà très important. Mais l’autre aspect, l’autre preuve presque, c’est que lors de la mise en production de notre projet qui a consommé plus de 20 développeurs pendant plus de 6 mois, nous avons rencontré un seul bug, non bloquant de surcroît. Épatant non ?

Pour finir en quelques mots, le développement est un métier très abstrait, à la construction invisible, je pense que vous en conviendrez tous. Les méthodes agiles sont pour moi des pistes à suivre pour que chacun se sente à sa place, responsable et heureux de faire son métier. Je ne crois pas qu’il y ait de méthode absolue à suivre aveuglément. Je crois plutôt que sont des idées à interpréter et adapter à son environnement, son équipe, son métier.

Crédit photo https://creativecommons.org/licenses/by-nc-sa/2.0/

Plus de publications

5 comments for “Depuis que je suis agile, je ne vais plus sur lequipe.fr

  1. Julien Léger
    29 janvier 2015 at 13 h 53 min

    C’est fou à quel point, je trouve plein de points en commun avec ce que je peux vivre au sein de l’équipe dans laquelle j’évolue.

    Concernant les “communautés de pratiques”, je ne comprends pas vraiment à quoi cela correspond ? Qu’est ce qui en résulte ? Une base de connaissance ? Si oui, je serais curieux d’avoir ton retour sur le sujet. 😉

  2. 2 février 2015 at 18 h 05 min

    Bonjour Julien

    Dans ma mission, la communauté de pratiques est une cérémonie hebdomadaire ou les différentes équipes de dev se regroupent par techno (ici Front et Back).
    Lors de ces réunions on peut discuter de plusieurs sujets :
    – un représentant de chaque équipe présente le travail de la semaine, les stratégies choisies et/ou les problèmes rencontrés. Chacun peut poser des questions et/ou apporter des conseils. Ainsi on comprends les problèmes résolus ou non dans le code. Et s’il ne sont pas résolus, on comprend vite pourquoi.
    – chacun peut présenter une idée d’amélioration (généralement technique) : une nouvelle API en remplacement d’une autre, uniformisation des appels vers …, idée d’architecture ou nouvelle règle de conception, nouvelle idée concernant le code review etc etc. Au travers des débats générés, le consensus est généralement rapide. Dans le cas contraire un vote à main levée valide ou non l’idée proposée.
    – enfin, c’est aussi le moment où l’on discute des stratégies de branch, de merge, de report de commit, etc etc..

    Les sujets sont nombreux et il n’y a pas de formalisme rigoureux, le tout est de permettre aux différentes équipes de dev de rester sur une même longueur d’onde et de laisser à chacun la possibilité de défendre une idée.

    Les débats sont animés, pointus ou amusants mais personne n’est laissé de côté et personne ne travaille en électron libre.

    C’est encore un moment compliqué à comprendre pour les managers (enfin j’imagine 🙂 ), mais c’est vraiment précieux.

  3. Philippe COCHARD
    29 avril 2015 at 17 h 24 min

    Merci pour ce retour d’expérience. J’aime à la fois le message et le style. Bravo.
    Je me permet de partager via LinkedIn.

    Une question sur votre organisation : la répartition des équipes en front/back office ne nuit-elle pas au développement des stories ? Il me semble que cela doit restreindre l’autonomie de chaque équipe puisqu’elle dépend de l’autre pour pouvoir proposer un incrément fonctionnel.
    Par ailleurs, appliquez vous aussi les préceptes d’équipes “auto-apprenantes” en mettant en oeuvre des formations croisées ?

  4. Raphaël
    30 avril 2015 at 10 h 26 min

    Tout d’abord merci pour ce retour.

    Au PMU les équipes sont mixtes pour la plupart. Elles sont donc autonomes. C’est seulement lors des communautés de pratique que nous sommes répartis selon nos technos. Les quelques développeurs fullstack participent à l’une ou l’autre des communautés voire les deux.

    En ce qui concerne les formations croisées :
    J’ai constaté que de nombreux dev Front viennent du Back et ne souhaitent pas y retourner.
    En revanche, les développeurs Back sont encouragés à faire du Front s’ils le veulent.

    Par ailleurs, à chaque fin de sprint, une demi-journée est réservée au “Tech-Time”, c’est à dire qu’on peut tester de nouvelles technos, nettoyer notre poste de travail, etc etc. Lors de cette demi-journée plusieurs dev Front ont mis en place des mini-formations pour les développeurs Back cherchant à mieux comprendre le Front.