Aucun plan de bataille ne survit au contact de l’ennemi 26


Sun Tzu est difficile à appliquer à la vie de tous les jours sans une bonne analyse et Clausewitz est carrément bourrin pour le développement.

Mais aviez-vous entendu parler de Helmuth Karl Bernhard ? Si on met de côté le fait qu’il ait participé à moult massacres, sa vision de la guerre résume très bien le déroulement d’un projet de développement Web:

Aucun plan de bataille ne survit au contact de l’ennemi

Pourquoi le développement agile ?

Vous allez faire un planning. Et que vous n’allez pas le suivre.

Parfois parce que vous êtes un procrastinateur expert.

Mais souvent parce que:

  • une version de x, y ou z n’est plus la même;
  • le matos est différent à l’arrivée;
  • votre client voudrait “juste” un petit truc en plus;
  • le contrat a été amendé;
  • la version beta a montré que votre brillant plan de conquête du monde avait une faille;
  • les tests d’utilisabilité ont foutu par terre vos espoirs fous de révolutionner le monde de l’UI;
  • votre chef de projet est un schizophrène psychopathe à tendances lunatiques (comme tous les autres, moi y compris);
  • votre commercial a décidé qu’il allait encore vendre du rêve;
  • les specs ne sont pas à jour/sont incomplètes/sont fausses/sont écrite en Klingon par un émigré chinois élévé au Portugal (mes excuses aux chinois, portugais et klingons);
  • etc.

Le fait de ne pas suivre le plan A est une bonne chose. Si vous l’aviez fait, le produit à l’arrivé n’aurait pas convenu. Le problème est quand le changement de direction se fait avec la méthode rache et le résultat est douloureux.

Suivre le planning, ça marche quand on travaille sur un satellite ou un limiteur de vitesse. Dans le dev pour un end user lambda, ça le fait vachement moins. L’ennemi se pointe, on engage la bataille, et il faut maintenant donner du sens au chaos.

Le développement agile existe justement parce que c’est la réalité du terrain. C’est une formalisation d’une méthode de travail adaptative qui répond à ces conditions de travail changeantes et non maitrisables.

La plupart des développeurs agiles ne font pas de l’Agile

Alors évidement, l’Agile, c’était la grande mode il y a cinq ans. Maintenant tout le monde fait de l’Agile. C’est main stream, c’est has been. En fait, beaucoup ont essayé l’Agile, et en sont revenu en affirmant que c’était super overrated et que franchement, ça valait pas le coup de se donner autant de mal.

Le truc c’est que sur 10 personnes qui ont essayé de travailler de manière agile, seule une l’a vraiment fait. Les autres ont généralement fait:

  • Une adaptation de la nomenclature agile à leur workflow, leur idée du monde et leurs mauvaises habitudes.
  • Ou une utilisation d’une partie uniquement des outils, supposant que cela suffirait. C’est la méthode à Gilles.

Sauf que l’Agile suppose justement un changement d’habitudes, parce que la plupart des développeurs sont de bons techniciens, mais de mauvais travailleurs en équipe. De plus, faire la moitié de l’Agile, c’est comme mettre des super pneus uniquement à gauche d’une deudeuch avec des roues lisses: ça coûte un bras et on dérape tout autant, juste pas dans la même direction.

L’Agile, ce n’est pas le bordel. En fait, ce n’est même pas une collection d’outils. C’est juste deux choses:

  • Forcer les gens à communiquer régulièrement et utilement.
  • Forcer les gens à réévaluer la situation régulièrement, et mettre en place la suite des opérations.

Agile, ce n’est pas Scrum, ce n’est pas XP, ce n’est pas du pair programming, ce n’est pas une collection de posts it. C’est n’importe quelle stratégie (y compris celles utilisant  les outils précédemment cités) qui sera utilisée de manière consistante pour atteindre ces deux résultats.

Le reste n’a aucune importance. D’ailleurs, vous faites peut être de l’Agile sans le savoir. Il y a plus de bons dev qui sont agiles sans le savoir, que de devs qui prétendent faire de l’Agile et pour qui c’est vraiment le cas.

Ok, c’est bien beau tout ça…

…mais c’est très abstrait.

En fait c’est très simple. La plupart des développeurs sont de mauvais communiquant. La plupart des gens (moi inclus) n’aiment pas se remettre en question, ni admettre qu’ils se sont trompés.

Développer en utilisant une méthode agile est juste un moyen de forcer à palier ces problèmes en utilisant le moins de ressources possibles. Ceci peut être atteint en utilisant plusieurs outils, et pas tous, par exemple:

  • Créer des petites équipes (5 personnes max, 3 idéalement). Si votre projet est plus gros, divisez le.
  • Une réunion journalière debout de 5 minutes qui oblige tout le monde à dire ce qu’il a fait, ce qu’il va faire et les points bloquant. Seuls les membres de l’équipes sont invités, et tenus d’être présents en personne sans rien faire d’autre en même temps.
  • De la revue de code hebdo avec toute l’équipe (pas une humiliation publique, pas une autocritique, une revue).
  • Isoler l’équipe pour qu’elle ne soit pas interrompue, et la faire travailler sur un seul projet à la fois.
  • Formaliser le progrès du projet et ce qu’il reste à faire. Pas par qui, pas par date, pas avec une grosse description. Juste un truc simple et rapide à utiliser, avec un minimal de contrainte, et qui soit tenu à jour en temps réel. D’où l’usage d’un white board et de post it.
  • Une revue du projet régulière avec le client (parfois à la fin d’un sprint, parfois sur le coup d’un test d’utilisabilité), idéalement hebdomadaire, pour qu’il puisse constater où vous avez merdé (et pas SI), et que vous puissiez corriger. Si votre client possède un site, il peut être judicieux d’avoir un membre de l’équipe sur place en permanence.
  • Faire du pair programming une fois par semaine pour que vos équipe se soudent et travaillent naturellement ensemble.
  • Prendre une journée par semaine où personne n’a le droit de se parler, ni d’être contacté par autre chose que par email (auxquels nuls n’est tenus de répondre) afin de booster la productivité ce jour là.
  • Forcer une intégration du code (installation en pre-prod, lancement de tous les unit tests, etc) une fois par semaine ou de manière continue pour s’assurer que tout le monde est bien syncro. Même si le code est incomplet ou cassé.
  • Inter changer les membres de l’équipe.
  • Désigner un mec qui va s’occuper de toutes les corvées pendant x jours pour que le reste de l’équipe se concentre sur le dev.
  • Commencer par le design de toute l’UI et le test du proto inerte sur un public type avant de coder quoi que ce soit.
  • Mettre un chrono à chaque meeting, et quand il sonne, on arrête. Quoiqu’il arrive. Tant pis pour les égos ou les promotions. Ça inclut le meetings de design d’archi. Et un meeting, c’est uniquement pour ce qui ne peut pas être réglé par un tête à tête, téléphone ou par email.
  • Forcer la livraison, une fois toutes les unes ou deux semaines. Obliger à livrer un truc force à se concentrer sur l’essentiel, et surtout à avoir un truc qui marche assez tôt, même si il est boiteux voir amputé. C’est aussi motivant d’avoir un truc qui tourne.
  • Écrire les tests unitaires avant d’écrire le code.

Le plus important ici est la revue journalière, et le contact avec le client. Le premier assure que votre équipe bosse sur ce sur quoi elle doit bosser. Le second s’assure que ce sur quoi elle doit bosser est bien ce sur quoi le client à besoin qu’elle bosse. Suivre scrupuleusement ces deux points, c’est 80% de l’Agile, c’est booster la réussite de votre projet. Si vous ne faites que ça, tout ira bien.

Là où ça peut merder

Le problème c’est que beaucoup de ces outils amènent:

  • à travailler sur ce dont on a pas envie de se soucier;
  • à révéler à tous ceux qui glandent au bureau;
  • à réveiller les instincts sadiques de certains qui aiment casser du collègue;
  • à laisser tomber les habitudes rapidement car c’est inconfortable.

En clair, on ne peut pas faire de l’Agile sans un bon gestionnaire de projet/d’équipe (ou dans vos rêves les plus fous, une équipe responsable et autonome). Ce responsable doit être là pour s’assurer que les outils sont utilisés de manière consistante (et doit donc avoir de l’autorité) et que l’équipe ne se tire pas dans les pattes. Mais il doit aussi fermer sa gueule quand ils découvrira que telle personne fait de la merde ou glande entre 11h et midi. Sinon tout ce qu’il va gagner c’est que tout le monde va lui mentir. Aucune équipe n’est parfaite, il faut faire avec ce qu’on a. Il est de toute manière illusoire de croire qu’un dev suit toujours les consignes, ou même qu’il programme plus 4 h par jour. Le cerveau d’une personne moyenne ne peut pas se concentrer aussi longtemps.

De plus, l’Agile part du principe que vous allez vous planter, que la communication va mettre ça en avant, et qu’on va pouvoir avancer en le détectant tôt et en corrigeant la course. Ca va demander une sérieuse reconsidération de la vision du travail de la part du chef d’entreprise, mais également de votre réaction face à l’échec. Agile ne marche pas si le boss continue à traiter une erreur comme anormale, ou que vous la dissimilez (ou la niez).

Et l’Agile n’est pas une méthode miracle. S’adapter est le principe, mais suivre la manière dont les autres s’adaptent n’est pas forcément bon pour vous. Au final, toutes les boîtes agiles que j’ai connu avaient adapté le worklow à leurs contraintes, leur philosophie. Peut être que vous avez déjà des très bons rapports techniques avec vos clients (ou que vous êtes votre propre client). Peut être que vous êtes deux dev, et que la réunion quotidienne est parfaitement inutile. Dans tous les cas, Agile n’est pas un diagramme, c’est une invitation à atteindre l’objectif de communication dans l’équipe et avec le client.

Et de livrer un truc qui marche et qui fait ce qu’on lui demande.

Ca n’arrive pas si souvent.

Les bénéfices de l’Agile

Si vous faites l’effort, le projet sortira dans un temps raisonnable (ou alors on s’apercevra tôt que ce n’est pas réalisable avec les ressources données) avec un nombre de fonctionnalités raisonnables, opérationnelles et utiles.

Cela va aussi largement améliorer l’ambiance dans l’équipe et l’intérêt pour le boulot.

Votre client sera plus satisfait, et sera bien plus prêt à pardonner vos erreurs. Il s’appropriera le bébé, car il aura été impliqué dès le début. Par dessus tout, l’utilisateur final aura beaucoup plus de chance d’avoir une relation positive avec le résultats, et pour les pépins futurs, de vous rapporter les problèmes et de supporter l’usage de palliatifs en attendant leurs résolutions. Oh, et la facture sera moins salée.

J’ai aussi entendu des bénéfices concernant la perte de poids et la taille du sexe, mais ça reste à confirmer.

L’Agile n’est pas censé vous bouffer du temps. Comme tout processus nouveau, cela prend du temps de l’implémenter. Mais si à l’usage, vous développez mieux en équipe sans méthode agile qu’avec, il y a un truc que vous faites mal. Les réunions doivent être courtes. Les outils doivent être simples. Les communications doivent être directes et sans chichi. Ce n’est pas une option.

Mais ne soyez pas non plus des nazis de l’Agile: moi aussi je fais des tas de trucs nuls, mal organisés et complètement anarchiques. Moi aussi je glande, et je perds mon temps et j’accuse mes collègues. Il faut savoir se pardonner :-)

26 thoughts on “Aucun plan de bataille ne survit au contact de l’ennemi

  • JEEK

    Je n’ai jamais travaillé dans un service de dev mais j’avoue que ton article m’a donné suffisamment de détails pour que je puisse répondre à des questions sur le pour et le contre concernant le développement agile…

    Merci Sam ! ;-)

    NB: bon, c’est certain que tout n’est pas là, mais n’ayant pas vécu la chose…si un “casse-burnes” vient me prendre le cervelet avec ce genre de question existentielle, je pourrai lui répondre “du-tac-au-tac” sans avoir à chercher des arguments ou des exemples pendant des plombes (…et comme il faut toujours la réponse pour hier soir : priceless) !

  • JEEK

    Mais aviez-vous entendu parlé de Helmuth Karl Bernhard ? Si on met de côté le fait qu’il ai participé à moulte massacres, sa vision de la guerre résume très bien le déroulement d’un projet de développement Web:

    parlé / parler
    ai / ait
    moulte / moult

    Désolé, j’ai pas fait gaffe à la première lecture… :-\

  • JEEK

    Roooh, c’était même pas pour avoir le tampon… Je me suis presque fouetté de ne pas les avoir vu à la première lecture !
    Bon, je retourne me mettre des coups de fouet..
    lol ^_^

  • Pierre

    Merci pour cet article (im)pertinent ! J’ai diffusé sur Twitter et apparemment je suis pas le seul à penser que votre prose mérite d’être diffusé plus largement.

    Bonne continuation,
    Pierre

  • Sam Post author

    Merci Pierre. On a effectivement eu une grosse arrivée de nouveaux venus après ton tweet, ça fait plaisir.

    Par contre, gaffe, http://pierre.ammeloot.fr/ est super mal noté sur WOT et du coup quand on va dessus, on a une alerte rouge qui bloque tout l’écran.

  • foxmask

    Bonjour,
    j’ai bien apprécié cet article, même si je code seul sur mes projets libres (à mon grand désarroi :) ainsi que dans ma vie “pro” – mais agile, est un sujet qui me “parle”.

    Par contre je n’ai pas saisi ceci :

    Agile ne marche pas si le boss continue à traiter une erreur comme anormale, ou que vous la dissimilez (ou la niez).

    quel devrait être le comportement du “boss” ?

    sinon aparté des coquillettes se sont glissées ici :

    Le communications doivent être directes et sans chichi
    […]
    Oh, et la facture sera moins salé.

    Bonne journée

  • Sam Post author

    Une erreur, c’est juste une partie du développement. Il n’y a rien de plus normal qu’une erreur. Quand on en détecte, le worklow ordinnaire c’est:

    1 – trouver qui a fait l’erreur;
    2 – emettre un jugement;
    3 – demander de ne plus la refaire;
    4 – demander la correction.

    Or les parties 2 et 3 sont complètement contre productif. En plus de faire perdre du temps, elles minent l’ambiance dans l’équipe. Si la personne est incompétente, il ne faut pas la garder dans l’équipe, si la personne est compétente, elle sait très bien qu’elle a merdé et n’a pas besoin qu’on l’emmerde avec un speech.

    Quand on trouve une erreur, on fait comme avec une feature: on évalue le temps qu’il faut pour la corriger, on assigne une priorité, et quelqu’un s’en occupe. C’est tout.

    Merci pour les coquilles !

  • Baronsed

    Foxmask : c’est également une chose que permet le libre (sur de plus grandes périodes) : la critique doit viser un objet, pas l’ego de l’un ou l’autre. C’est plus facile quand on sait comment le soft est fait, évidemment.

  • foxmask

    @baronsed : oui ; le libre permet cela, tout comme il permet de confronter son égo à un projet, savoir rester humble face à la critique. pour le coup le libre enrichi par ces aspects et c’est plutôt cool.

  • 6ms

    Super article !

    Encore plus apréciable quand on a connu l’anti agile par excellence chez un boss, ou un n+1 je pense!

    Sinon mini coq :

    à la fin d’un sprint, parfois sur le coup d’un test d’utilisabilité), idéalement hebdomadaire, pour qu’il puisse constatez constater où vous avez merdé

    Qu’il est bon de se

  • 6ms

    Qu’il est bon de se sentir moins seul … en vous lisant !

    Les boulettes c’est pour moi le propre d’un dev, les reconnaître c’est avancer, les cacher ou les mettre sur le dos des collègues c’est lâche.

    Je parle en connaissance de cause ayant été dans une petite structure composée uniquement de deux devs dont une brebis galeuse!

    Sinon pour mon comm précédent, lol je crois que rédiger un com non trollesque avec iphone c’est pas pour moi …!

    On peut pas éditer les com?

    Next feature?

    PS : j’ai cru voir apparaître le trombone d’office 97 qui m’a insulté pour injure, vous avez un “DPI” qui tourne pdt la saisie du com???

  • Sam Post author

    ^^

    Sous le com il y a la preview du commentaire en live, mais on ne tient pas à l’édition car comme on veut éviter de censurer, l’historique des propos est important (et on a pas envie de foutre un histo par comment).

    Vous avez vu clippy ? Bien ! Il apparait uniquement sous de rares conditions normalement (secretes ou presque puisque le JS est en clair). C’est un des easters eggs du site :-D

  • Pierre

    @Sam : merci pour l’accueil. J’avais déjà vu que WOT donnais une mauvaise appréciation sur mon site mais je n’ai jamais compris pourquoi. Et puis je ne connait personne autour de moi qui l’utilise. Je ne l’utilise pas moi même.

    N’hésite pas à me donner plus d’infos sur ton usage de cet outil parce que je ne comprend pas.

    Pierre

  • Sam Post author

    J’utilise WOT pour ne pas me poser de question: il me signal d’avance les liens inutiles à cliquer.

    Les faux positifs sont très rares, et pour cette raison il respecte très bien la loi du 80/20. Je l’installe sur toutes les machines des débutants que je rencontre, ça leur évite énormément de problème sur internet: il n’y a rien à comprendre pour eux, ils voient un truc rouge, ils savent qu’il faut se barrer.

    Dans votre cas, je pense qu’on est dans le cadre d’un faux positif, à moins que:

    – vous soyez un vil connard et que nous l’ignorions :-) Mais vous cachez bien votre jeu.
    – vous avez fais une campagne de mails qui a été perçue comme du spam.
    – votre site a été infecté et délivre maintenant des virus ou contenus malveillant.

    Dans le cas d’un faux positif, le mieux et de défendre votre cause en commentaire sur WOT. L’équilibre devrait se refaire en quelques mois.

    Dans les autres cas:

    1 – heu…
    2 – la note WOT ne bougera pas. Les membres ont horreurs des mails non solicités.
    3 – désinfecter le site mène généralement à une remontée de la note.

  • Sam Post author

    Cela dit, si sebsauvage passe par là, il a un forte influence WOT et en voyant le site, il va peut être conclure comme nous que le site est OK et voter positivement. Son vote à lui seul peut largement remonter la note. (ce qui veut dire aussi, inversement, qu’il vaut mieux ne pas le faire chier :-))

  • Pierre

    @Sam :
    1 – Je ne l’espère pas mais ce n’est pas à moi d’en juger.
    2 – Pas de campagne d’emailing, c’est mon portfolio pro aucun intérêt à spammer mon prochain. :)
    3 – Pas de virus sur le site à ma connaissance.

    Je vient de me créer un compte sur WOT et de demander la révision de mon site.

    Pierre

  • Bobinours

    Ça fait un petit moment que j’ai découvert votre site (merci sebsauvage) et j’apprécie particulièrement votre style d’écriture.

    Cet article ne fait pas exception et m’a permis de me réconcilier avec la méthode Agile. M’étant initié à ces méthodes de façon autodidacte dans le but de l’appliquer à une équipe de 5 personnes, j’avais eu du mal à choisir la bonne solution clé en main (Scrum, Extreme Programming…).

    Ici, tu décortiques la philosophie de la chose et présentes des éléments détaillés pour y arriver plutôt qu’une méthode toute faite qui bien souvent ne convient pas à l’équipe… Grâce à toi, on peut concevoir notre propre méthode à la carte !

    Merci, il ne reste plus qu’à m’y remettre :)

  • roro

    J’ai pas bu my friend…Je conseille juste à ceux qui ont besoin d’Agile pour gérer une équipe, de se recycler dans le gardiennage des chèvres.

    • Sam Post author

      Ah pardon alors c’est de ma faute, je me suis gourré de tampon.

  • roro

    Bon, il faut argumenter…Le mot recycler est il est vrai, un peu définitif. Un stage de quelques jours, avec une journée spéciale de chasse à la chèvre (si la chèvre fait défaut, le porcelet convient bien également). La chèvre est un animal au prés duquel les notions de: “groupe”, d’ “individu”, d’ “initiative” et de “liberté”, prennent tout leur sens.L’acquisition de ces notions dans de telles circonstances, se faisant de façon “sensorielle”, elles sont intégrées sans intervention de l’intellect. Ce qui n’est pas le cas des méthodes construites par “intellect”
    En conséquence, je ne suis pas d’accord avec: “Obligation de livrer….”. Dans la mesure où est respectée ta clause du 07-08: cite:” Si la personne est incompétente, il ne faut pas la garder dans l’équi…..” …..Salut trollesque….

Leave a comment

Des questions Python sans rapport avec l'article ? Posez-les sur IndexError.