La théorie des contraintes pour les projets logiciels

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.

Kanban, ToC, 6 sigma, Lean : quand l’industrie inspire la gestion de projet agile

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 !

Un petit tableau Kanban pas cher ! (pioché chez Wikipedia)

Lire la suite

L’art sombre de l’estimation logicielle

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

Un précieux grimoire trop peu connu du monde du web

Lire la suite

Concilier vélocité et qualité en mode agile

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 un ! » : le développement en série continue

« Tous pour le ticket #2130 ! »

Lire la suite

Référencement, technique et maraboutage

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é.

Changements d'algorithme Google

Influence des changements d’algorithme Google sur le référencement de Linkedin

Lire la suite

PRINCE2 et Scrum… compatibles ?

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

Les activités PRINCE2 affectées aux membres d’une équipe SCRUM (reprise chez Jim Coplien)

Lire la suite

Habitude vs coolitude : quand changer ses outils de travail ?

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.

Lire la suite