Il y a  deux choses qui sont partulièrement difficiles en gestion de projet : les relations humaines, et les relations au temps. Cette relation au temps se décompose en deux : le délais et la vélocité qu'il faut fournir (en jour homme) pour atteindre l'objectif.

S'il nous arrive souvent d'être rattrapé par le temps, c'est qu'il est une contrainte forte. Elle est même si forte qu'elle fait oublier les béabas. Le mois dernier je reçois un coup de fil d'un ancien collègue qui en me donne de ses nouvelles :

- Je comprend pas quand tu bossais avec nous, on avait moins de retours clients, on arrive pas à comprendre pourquoi ?

- Tu as des exemples de retours ?

- La semaine dernière on a raté une mise en production, il y a une partie du site qui répondait plus. Les ingénieurs ont réparés en catastrophe, mais le client était pas content.

Tu m'étonnes ! En cherchant à savoir si les exigences de chaque environnement (de développement, de préproduction, tests et production) étaient respectées, je me suis aperçu que la préproduction était devenu l'espace de développement.

En réalité, ce n'est jamais aussi flagrant, et les ingénieurs sont persuadés de faire leur développement en local, et une fois terminé, de le passer en préproduction. Mais ce qui biaise la procédure, c'est que par manque de temps, certains développements, à peine terminés, sont intégrés aux travaux stables en préproduction sans même être testé par le développeur sur son environnement local. Plusieurs raisons sont fréquentes : le délais pour livre la fonctionnalité, l'environnement n'est pas à jour des contributions des coéquipiers, une contrainte spécifique au client l'empêche de reproduire fidèlement l'espace de production. Par suite, le bêta testeur va se focaliser sur les erreurs les plus énormes. Il y aura beaucoup d'aller-retour sur l'environnement de préprod. Au final, les bugs plus "cachés" ne sont détectés qu'en production.

Comment redresser la situation ?

1°) Les indices de ce "glissement d'environnement" font penser illico qu'il faut ajouter une étape à la procédure entre la préprod et le dév : une recette sur l'environnement de développement. En premier lieu j'ai eu le réflexe de conseiller cette méthode, puis me suis raviser.

En fait, oui pour une étape supplémentaire si elle est automatisé (cas de x programming) : jeu de tests unitaires, fonctionnels, ... dans ce cas elle est intégré au build. Non si c'est pour une recette des bêta testeurs : le développeur lui même doit livrer un travail le plus parfait possible et fonctionnel.

Si on ajoute une étape en croyant que cette contrainte sera un passage de plus dans un tamis garantissant moins de bugs, on se trompe. Si on ne contient pas ce phénomène de glissement d'environnement, en établissant les raisons, on ajoutera des tamis et toujours plus de tamis. Cela apportera une rigidité à l'ensemble néfaste pour la bonne conduite du projet. (voir l'algorithme de mon médecin)

2°) Rédiger simplement par écrit les procédures et en faire la communication

Il me semble important que l'équipe comprenne pourquoi le respect de chaque espace est important pour ne pas mettre en péril la qualité des mises en production. Dans la plupart des projets web, les procédures doivent rester à la mesure du projet, donc légères.

Finalement, c'est la communication qui sauvera l'affaire pour expliquer que certains raccourcis ne sont pas à prendre quand le temps presse en fin de sprint ou quand le délais du projet arrive à échéance.

En route vers l'industrialisation d'un projet web : l'environnement de production et passerelles

Pour moi les serveurs de production, c'est un NO MAN'S LAND, littéralement Contrée d'aucun homme (à prendre dans le sens où la contrée en question n'accepte aucune présence humaine, au-delà du sens que cette contrée n'appartient à personne).

L'espace de production doit donc, pour moi, être pilotée si possible depuis l'extérieur. Tout y est automatisé, on a pas le droit à l'erreur, mais tout est prévu pour qu'il n'y ait pas d'inconnue, ce qui signifie :

• Edition de fichiers en direct proscrite
• Mise en place d'une synchronisation des scripts par rapport à une base de préproduction saine et versionnée
• Automatisation des scripts de changements de structure de base de données
• Monitoring quotidien des activités des serveurs
• Interdire les mises ligne un vendredi soir ou une veille de pont
• ... et plein d'autres choses contraignantes.

Mais, expérience à l'appui, un peu de rigueur et de qualité à ce niveau là vous permettra de dormir sur ses deux oreilles, de passer des week-end tranquilles, et des mises en production sans stress.

Autant que je peux, je mets en place des scritps de synchronisation entre les différents environnements.

Un simple script bash avec rsync permet de déployer une copie locale d'une branche versionnée vers un serveur de production. C'est très simple à mettre en place et apporte beaucoup. Les équipes gérant des projets plus gros ont l'habitude de déployer de tels applicatifs avec des outils intégrés à un système de développement continu. Les systèmes de répartition de charge oblige souvent à dupliquer le sources à l'identique sur chaque serveur, un script qui automatise les mise en ligne est un plus. Disons que c'est un premier pas qui montre la voie pour diminuer les erreurs humaines.

Aujourd'hui c'est vendredi et le vendredi c'est récréation. Cette semaine, je vous propose une private joke, car seul les initiés (responsables techniques de projets ou scrum master). Une fois encore je vais me moquer du chef de produit, il faut dire que c'est un bon client ! Vous le connaissez déjà, c'est celui qui tiens les cordons de la bourse et qui demandait d'aller plus vite en baissant la qualité interne (voir ici). Rappelez-vous, il avait fini par abdiquer sur la qualité interne.

Quelques mois plus tard, nous montons un projet avec des méthodes agile (scrum). A la fin de notre réunion de backlog produit, tout le monde était fier des fonctionnalités à développer, les priorités étaient fonctions du besoin utilisateurs. On a même fait les découpes en sprints. Il y en avait 6. Connaissant le chef de produit, qui ne nous avait pas encore donner les délais, je lance :

- 6 sprints, donc grosso modo 6 mois de travail !

Je vois alors les sourcils se froncer, l'air dubitatif, il me répond :

- Mais c'est pas possible ! Attendez, mais il y a vraiment pas moyen de lancer deux sprints en même temps (rire de l'assistance), comme cela dans trois mois c'est fini !

- Non, on ne peut pas coudre la braguette d'un pantalon avant d'avoir cousu les jambes. Les prirorités jusqu'au sprint 3 ont une logique technique !

- Ah, mais c'est dimentionné pour une équipe de combien ? parce qu'on peut embaucher pour doubler l'équipe et diviser par deux le temps d'un sprint.

- Eventuellement, mais à partir d'un moment, le travail en binôme sera le seul moyen d'être éfficace pour ne pas se marcher sur les pieds.

Cette petite expérience montre que la logique de délais technique n'est pas perçu de manière par tout le monde. Pour un chef de produit avec un background commercial ou financier (donc sans bagage technique), il est difficile de comprendre les dépenses sur des dév. techniques : ce n'est pas aussi "proportionnel" que déposer des fonds sur un cours en bourse !

L'avantage d'aborder un nouveau projet avec une méthode de programmation continue, est que l'équipe technique peut livrer tous les mois une version fonctionnelle sur laquelle l'équipe produit fait ses retours. De plus, au vu des délais, j'ai fait comprendre que le seul moyen de réduire les délais, sans mettre en cause le succès du projet et sa qualité interne, était de diminuer le nombre de fonctionnalités. En revenant sur notre backlog produits, nous nous sommes apreçus qu'une version avec les fonctionnalités repondant aux besoins essenciels des utilisateurs était possible dès la fin du sprint 3 ! Donc d'un point de vue utilisateur, 3 mois ont suffit pour livrer l'essentielle des attentes. Les fonctionnalités secondaires, ont pu être revue et repriorisée en fonction du retour des premiers visiteurs. Certains usage du site qu'on avait imaginé au départ ont été supprimé.

En route vers l'industrialisation d'un projet web : les outils de conception

Il existe pour moi deux sortes d'outil de conception :

• les outils qui aident à structurer la pensée (diagramme SADT) en vue d'un développement
• les outils de support (Gantt, Bugtracker, Gestion de tickets clients, ...)

Ceux ci-interviennent à différentes étapes du projet mais garantissent la réussite de celui-ci. Issue d'une formation d'automaticien, j'ai importé les diagramme SADT pour réaliser les sénarios utilisateurs. Voilà à quoi cela ressemble :

Ce qui donne avec un exemple : "payement de son panier sur un site de vente en ligne"

... et des fonctions de chacun.

En route vers l'industrialisation d'un projet web : l'environnement de réflexion et de management

En tant que chef de projets des activités techniques dans des petites structures, j'ai souvent dû faire des maquettes avant de passer aux spécifications techniques lorsque le chef de produits était parti en rendez-vous commercial.

C'est le bonheur des petites entreprises, mais à part que les logiciels de design, ce n'est pas mon fort cela montre :

• la mise en place d'une organisation doit être adapté à la taille du projet
• savoir dire "non, c'est pas dans mes cordes" ou "non, ça peut attendre le retour du chef de produit" n'est pas un aveux d'échec, c'est une alerte qui doit faire penser que le projet "part en sucette".
• l'arbitrage qui est fait pour le chef de produit agissant pour le compte du client lors de la définition des maquettes peut apporter des erreurs.

Je lisais récement une étude du standish group qui estime que seul 25% des projets sont des réussites. Au début, j'étais séptique, et puis en me plongeant dans mes souvenirs, le nombre de fonctionnalités sur des projets web qui sont finalement passés à la trappes faute de temps ou de pertinence, ... Derrière tout cela, il y a une question de rentabilité.

En route vers l'industrialisation d'un projet web

On imagine mal un tourneur fraiseur fabriquer des pièces automobile à la bonne mesure sous une montagne de copeau, sans règle graduée, ni schéma et avec un équipement de bricoleur du dimanche !

En informatique c'est pareil, on ne peut pas concevoir un logiciel de qualité interne satisfaisante avec un environnement de travail n'est pas adapté. La recherche de l'amélioration doit être une quète permanente et adaptée à l'évolution du produit qui est vivant. Aussitôt, que le projet grandi, il mérite que l'on structure et dimensionne celui-ci.

Pour ce faire, je distinguerais 4 environnements :

• un environnement de réflexion / conception / architecture logiciel / management (ce n'est pas usuel de le faire apparaître, mais j'ai mes raisons)
• un environnement de développement
• un environnement de test / préproduction (je regroupe les deux)
• un environnement de production

Pour chaque environnement, nous avons besoin d'outils pour évoluer au sein de l'environnement et des passerelles pour passer d'un environnement à l'autre :

• outils de conception et de management : Lean, GANT, Scrum, Kanban, SADT, bug tracker, gestion de tickets client, ...
• outils pour le développement : infrastructure LAMP, outil de versionning (ex : svn, cvs), framework php
• passerelle : outil de déployement en (pré)production.
• outils de tests : framework de tests unitaires (jUnit, PhpUnit, ...), recette fonctionnelle humaine, ...
• outils de production : monitoring de l'infrastructure (cacti, munin), monitoring des applicatifs, monitoring spécifique (Trafic, Google webmaster tools), analyser de logs

Faire de l'intégration continue, c'est réaliser un lien continue dans le temps. En bonus, nous pouvons donc ajouter un outil pour piloter nos environnements et leurs passerelles :

• outils d'intégration continue : Cruise Control, husdon, Jira ...

Dans les jours à venir, je vous propose en guise de saga de l'été, de découvrir chacun de ces environnements. Je ne m'étalerais pas sur l'utilisation des outils en eux même car il existe beaucoup de documentation, mais plutôt sur la manière dont on peut les utiliser, ce qui à mon sens marche bien et ce qui eu contraire est à éviter.