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 :-)