A l’invitation de Florent Lothon, je publie aujourd’hui un billet sur la théorie des contraintes (la ToC) sur le blog de l’Agiliste. J’y détaille les principes applicables pour le développement logiciel, en particulier web, et donne quelques astuces de mise en oeuvre.
Je remercie au passage Florent pour son accueil sur un site qui vaut véritablement le détour pour tout praticien francophone de l’agile : c’est une excellente source sur Scrum et le Lean mâtinée d’un peu d’XP et de Kanban.
La gestion de projet web, et plus généralement le monde du logiciel, a tout un tas de particularités qui la rendent peu comparable avec l’univers de l’industrie classique. Dans une production manufacturière, un produit est en effet conçu, prototypé, testé, optimisé, puis passe en industrialisation. Dès lors que cette phase d’industrialisation a débuté, il s’agit de produire des articles identiques ou présentant de légères variantes en très grande quantité. Lors de la réalisation d’un logiciel, l’essentiel de l’activité de « fabrication » de celui-ci est confondu avec sa conception.
Dès lors, il paraît peu vraisemblable que des méthodes venues du monde de la production automobile – par exemple – fonctionnent pour améliorer la maîtrise d’un projet web. Et pourtant, plusieurs de ces méthodes fonctionnent plutôt bien avec quelques adaptations et peuvent compléter de manière très pertinente la vision agile d’un Scrum ou d’un XP.
Un petit tableau Kanban pas cher ! (pioché chez Wikipedia)
Disons le clairement : les dépassements de coûts/délais que peuvent connaître les projets web relèvent souvent plus d’une mauvaise estimation initiale que d’un véritable raté technique. Au moment de faire les comptes, on a bien évidemment toujours des raisons de penser que l’on aurait pu faire mieux ici ou là, que certaines parts des spécifications avaient été incomprises ou que quelques détails techniques subtils avaient fait perdre un temps que l’on n’avait malheureusement pas. Oui, il est certain qu’il y a toujours matière à s’améliorer, mais la perfection n’étant pas de ce monde, mieux vaut se résoudre à faire des estimations qui sauront prendre en compte à l’avance les inévitables aléas que connaissent les projets du monde réel.
En dehors de la bible du développement qu’est « Code Complete« , Steve McConnell a eu le génie de publier il y a près de 10 ans « Software Estimation : Demystifying the Black Art« . Après un peu plus d’un an de suivi des pratiques qu’il recommande, je dresse ici un compte-rendu des principales leçons que j’en tire.
Un précieux grimoire trop peu connu du monde du web
On ne le dira jamais assez : les méthodes agiles ne font pas travailler plus vite, elles diminuent d’une part les temps d’attente entre les tâches et d’autre part le nombre de choses à refaire. Que l’on travaille en agile ou non, diminuer le niveau d’exigence permet de travailler plus vite, mais cela augmente le taux de rebut (et donc le nombre de retouches à faire)… et peut donc reculer la date de livraison finale. A l’inverse, aller trop loin et trop vite dans la qualité fera tomber la vélocité à des niveaux inacceptables pour l’avancée d’un projet. Il y a donc un optimum quelque part, pour chaque projet, et même pour chaque item d’un projet entre sous-qualité et sur-qualité pour livrer un produit acceptable le plus rapidement possible.
Mais indépendamment de cet arbitrage du quotidien entre qualité et vélocité, il existe aussi un certain nombre de pratiques qui permettent d’augmenter l’un des facteurs sans pénaliser l’autre. En voici 3 exemples méconnus (tirés de la communauté Scrum Plop) et pourtant redoutablement efficaces.
« Tous pour le ticket #2130 ! »
J’ai dernièrement eu le plaisir de faire la connaissance de Marie-Aude Koiransky, spécialiste du référencement, une de ces espèces qui croisent parfois le chemin des chefs de projet web et que je regarde toujours d’un oeil un peu dubitatif. Non pas que les référenceurs soient des charlatans, mais certains de leurs discours tiennent à l’occasion plus du maraboutage que de la pratique professionnelle.
Marie-Aude, donc, m’a fait découvrir un article de Jayson Demers et le formidable débat qui en a suivi : « Why modern SEO requires almost no technical expertise« . La thèse de l’auteur est simple : Google a beaucoup changé et est désormais suffisamment intelligent pour ne plus être biaisé par des artifices techniques. Le niveau d’excellence du moteur de recherche de référence offre aujourd’hui une vision réelle de la richesse d’un contenu et de sa popularité. Et même si une astuce peut provisoirement rapporter un peu dans le monde SEO, les mises à jours permanentes des algorithmes Google rendent l’exercice assez risqué.
Influence des changements d’algorithme Google sur le référencement de Linkedin
PRINCE2 est une approche de gestion de projet résolument full-process. C’est véritablement une engeance de l’esprit d’entreprise qui naît dans les années 70, esprit qui va peu à peu dominer la pensée du management puis être progressivement remise en cause dans les années 2000 : toute activité de l’entreprise doit être formalisée en tant que processus documenté, imposé, contrôlé et optimisé.
C’est en quelque sorte l’anti-méthode agile : des processus précis, au sein d’une structure très hiérarchisée, doivent être précisément respectés afin de maîtriser la qualité du projet. PRINCE2 offre ainsi un ensemble de processus-type à documenter, à affecter et à gérer dans chaque projet. Une partie des problèmes liés à la rigidité des organisations appliquant PRINCE2 provient certainement plus d’une mise en pratique trop « mécanique » que de la méthode en elle-même : son étude est donc loin d’être dénuée d’intérêt.
A titre d’exemple, le travail effectué par l’équipe à l’origine de PRINCE2 sur le listing des activités à mener sur un projet est particulièrement riche. Jim Coplien s’est amusé à établir un ensemble de correspondances entre les processus de PRINCE2 et leur affectation dans une équipe Scrum type.
Les activités PRINCE2 affectées aux membres d’une équipe SCRUM (reprise chez Jim Coplien)
La semaine qui vient de s’écouler a été pour moi techniquement éprouvante : c’était ma première création de plate-forme de production pour un gros projet RubyOnRails… et que ce fut compliqué ! Même si Rails est a présent une technologie mature (un peu plus de 10 ans d’existence), j’ai vraiment eu l’impression de revenir 15 ans en arrière, quand le moindre serveur web demandait moult outils aux paramètres mal documentés pour parvenir à quelque chose d’à peu près propre.
Je suis pourtant particulièrement content d’être passé par là, parce que cela a aussi été pour moi l’occasion de découvrir une manière de penser radicalement différente de ce que je connaissais dont quelques méthodes assez puissantes. Mais je suis aussi ravi d’avoir attendu tout ce temps pour aller franchement sur cette technologie, alors que les gens dans le vent se sont souvent détournés de RoR et n’ont désormais plus d’yeux que pour nodejs ou Scala.
Par un drôle de concours de circonstances, j’ai été amené la semaine dernière à faire une modification dans un gros plugin développé par une autre société pour un CMS bien connu. Bilan : 3 heures de recherche dans les entrailles de l’existant pour 20 minutes et 50 lignes de code effectif… et pourtant, le tout était finalement plutôt bien organisé ! Mais cela aurait pu être pire : je n’ai pas eu à toucher à une ligne de CSS, univers bien souvent cauchemardesque à faire évoluer.
J’en parle aujourd’hui puisque je viens de boucler la lecture de « CSS maintenables avec Sass et Compass » et que ce livre vient mettre de l’ordre dans ce qui est jusque là un chaos plus ou moins sous contrôle dans l’essentiel des projets. En effet, après Javascript, CSS aura probablement été pendant longtemps l’autre langage particulièrement maltraité du web, faute de pratiques de références sur le sujet. Des pratiques de référence, le bouquin en donnent justement quelques unes dont je résume ici les plus marquantes. Au menu : de la maintenabilité certes, mais aussi de la productivité.
Un concentré de bonnes pratiques !
Vous avez peut-être déjà vécu cette scène : un ingénieur et un manager s’envoient à tour de rôle des arguments volant de plus en plus bas, et le point Godwin commence à pointer le bout de son nez. Vous décidez d’intervenir et l’on vous explique le débat à l’origine du désaccord : « peut-on faire des entorses au Plan d’Assurance Qualité dans un projet agile ? ».
« Oui », dit l’un, « les règles trop rigides, c’est tout le contraire de l’agile »
« Non », dit l’autre, « le non-respect des principes qualité nuit à l’agilité du projet »
Difficile de trancher dans un tel cas… Votre méthode ne dit rien à ce sujet et les deux arguments sont recevables. Que faire ?
Etant particulièrement en accord avec un grand nombre des écrits publiés dans la Scrum Pattern Community, j’ai décidé de développer ici certaines des idées qui s’y trouvent, en particulier quand elles s’appliquent au delà des projets Scrum.
Ca y est le projet a dérapé. Il faut se rendre à l’évidence, la livraison ne pourra pas avoir lieu à la date prévue. Et là, un super directeur de projet débarque et vous annonce : « Mais si ! On va passer en mode agile ! ». En creusant un peu, vous comprenez que son mode agile consiste à ne plus faire de spécifications, à tester à l’arrache et à s’affranchir de tout un tas de procédures jugées trop lourdes. A ce moment là, je considère que vous avez deux options : lui lancer au visage l’objet contondant le plus proche ou ouvrir un blogue. C’est donc grâce à ma nature profondément non-violente que vous lisez ces lignes.
Pour commencer, autant repartir des bases : l’agilité dans la gestion de projet informatique a été définie dans le manifeste des méthodes agiles. La bible de l’agilité est donc là et nulle par ailleurs. Ce texte remarquablement clair et concis fait passer en 4 principes et 12 pratiques, l’essence des méthodes agiles telles qu’imaginées par leurs créateurs respectifs.
Le web agile 