Produits et projets web

En route vers l'industrialisation d'un projet web : l'environnement de développement

L'environnement de développement LAMP nécessite forcément un outils  de versioning, et à mon sens, c'est la clef de voûte du projet. Si celui-ci est absent ou mal organisé, le projet aura du mal à être automatiser, car il est si simple d'éditer un fichier sur un serveur pour corriger rapido un bug, n'est-ce pas ?

Les outils que j'ai l'habitude proscrire pour développer, en environnement de développement :

• pusher des fichiers en ftp sur un serveur LAMP
• utiliser winscp pour la même chose

Ce que je préfère :

• un serveur samba + LAMP ou chaque développeur pourra éditer ses fichiers. De cette manière on gagne du temps. Vous rendez-vous compte du temps perdu à pusher des fichier
• un serveur SVN ou chacun "checkout" les projets
• putty pour les configuration apache de chacun. Quelques liens symboliques font souvent l'affaire !

Certain vont rigoler, mais j'ai souvent vu la solution 1. La deuxième, plus élégante, nécessite que l'on prenne du temps pour organiser cela. Au fond, je sais pourquoi on arrive à la solution. Au début, l'installation 2 est nickel et puis, le temps passe, le serveur devient de plus en plus "crade" à force de mettre des applicatifs et puis il y a un bout qui lâche, ou la personne qui a mis en place ce serveur est parti, ou on installe un autre serveur de dev car le premier est plein, et, et, et ... il faut bien se débrouiller, alors, on fait du ftp !

Pour la gestion des branches, c'est la même chose. J'ai remarque que tout le monde s'en sors pour installer cvs ou svn, mais beaucoup ne s'en servent pas avec efficacité. Je vais donner ici, une méthode simple pour commencer sous svn :

• On crée un projet avec trois répertoires : trunk, branches et tags
• Chaque utilisateur développe dans trunk
• Une fois les développements finis ou que l'on veut montrer le site en production, faire un svn copy vers un nouveau répertoire branche
  • ex : svn copy http://svn.localhost/mon_projet/trunk http://svn.localhost/mon_projet/branches/2009-08-31/
  • cela va recopier et figer ce que vous avez dans trunk
  • c'est cette version qu'il faudra envoyer sur un serveur de production
• Pour faire évoluer un fichier :
  • faire une comparaison entre les répertoires trunk et branches/date/ et passer les modification commité dans trunk
• Si vous avez trop de modification recréer un branche.

Cette méthode, convient pour un faible nombre de développeurs, et garanti relativement bien les non-régressions de code. Utiliser Eclipse sous windows permet d'avoir les diiférence de manière visuelle. En mettant en place un script de déployement de la branche d'un serveur de dev vers vos serveurs de production, vous garantirez qu'ils sont tous à jour avec la même version (cas des serveurs load balancés). Vous pouvez déployer en locale votre branche ou sur un serveur de préproduction, ainsi faire une recette fonctionnelle avant même de modifier vos fichiers.

Cette configuration de vos projets sous svn est très légère, on pourrais aller plus loin, mais pour commencer, elle apportera un peu de rigueur dans les déployements. Ce sera déjà un progrès !

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.

C'est vendredi alors c'est un peu récréation.

Plutôt que de vous détailler l'efficacité de la méthode kaban, dont je n'ai pas encore l'expérience pour faire un retour fin, je vais détailler ici ce que j'ai retenu pour mon tableau de Kanban.

Pour votre atelier bricolage entre collègues de bonne volonté, il vous faut :

• Une bombe de colle repositionnable
• Un rouleau de papier kraft prévu pour l'emballage
• Des post-it de différentes couleurs
• Un rouleau de scotch crèpé (que l'on utilise pour faire de la peinture ou des dessin pour les architectes)
• Des fluos
• Des vignettes autocollantes

Ce matériel se trouve facilement sur les catalogues de fourniture de bureau.

Pour les étiquettes, vous trouverez dans le zip le kit nécessaire.

Et voilà le travail après :

• matérialisation des colonnes avec le scotch
• enduction de colle
• mise en place des étiquette de titre et post-it

Dans le monde du web open source, il est assez difficile de recruter. Les profiles d'expérience sont essentiellement des autodidactes. Les jeunes recrues sortant d'écoles d'informatique, quant à elles, possèdent un bagage théorique souvent intéressant qui leur confèrent plus de rigueurs et d'idées.

Je ne cracherais pas dans la soupe, ma formation d'école d'ingénieur généraliste à dominante mécanique m'a permis de faire du web. Toutes les personnes qui m'ont fait confiance pour me former (stages et embauches) avaient le même profil. Les entreprises françaises ont une forte culture du diplôme et je dois dire que le mien a été souvent un précieux césame. J'ai souvent pu constater que pour un recrutement où l'on cherche un "potentiel", une école d'ingénieur accessible depuis une prépa, ça percute plus vite.

J'ai pourtant souvent remis en cause ma formation, trop génraliste ! Certes on apprend à apprendre, mais je m'en suis souvent voulu de passer à côté de concepts qui pourtant étaient sous mes yeux. Il n'y a rien de pire que de ne pas imaginer qu'une solution puisse exister car même la curiosité ne sauvera pas. Il s'agissait là, certainement, d'un manque d'expérience. N'avez vous jamais eu un stagiaire à former qui empile 10 fonctions, alors qu'il existe une fonction qui nativement fait la même chose ?

Finalement de l'autodidacte ou du diplômé, je prend toujours celui qui a la plus forte intuition à penser à l'avance qu'une bonne solution existe. C'est un profile de bon fainéant : refléchir à faire plus simple, plus solide, de meilleur qualité avant de démarer un quelconque développement pour économiser du temps et de l'énergie.

Thalès est connu pour être un leader de l'industrie. Son service informatique qui développe les logiciels qui seront intégrés dans leurs produits l'est beaucoup moins. Cette vidéo montre comment les techniques chères à l'industrie conserve tous son sens dans la gestion de projet informatique.

Il y a quelques temps j'ai été confronté à l'optimisation SEO (Search Engine Optimisation) d'un site. Une société en consulting avait fait une tonne de recommandations très pertinentes du genre "sculpter le linking interne", travailler les balises title, ... Au final, les couches de code se sont accumulés formant un projet web sans contour, ou les erreurs de mises en production se sont accumulés. Quand je suis arrivé, le patron m'a dit fièrement : c'est mathématique, si on projette la courbe d'audience dans 6 mois, on sera à 1M de visiteurs uniques par mois, en faisant quelques optimisations on sera à 1,5 M ce qui voudra dire que la société sera rentable.

Quand j'ai lu les premières lignes de codes, celui-ci était codé en PHP de "base" sans objets, sans fonction avec beaucoup de requètes sql au milieu du code HTML, aucun log d'erreurs, ma première réaction avant même d'être en poste fût, ce n'est pas possible ce site ne tiendra pas 1 M de VU. J'ai expliqué au patron : "Tu me demandes de faire rouler une 2CV à 200 km/h, combien même on arrive à pousser le moteur, il va y avoir une soudure qui va cèder avant !" ce à quoi je me suis vu répondre : "oui mais j'ai pas les moyens de me payer une Ferrari, alors qu'une 2CV ça me va très bien !". C'était pas gagné.

1°) La qualité interne

Je l'ai compris, il y a peu, mais ce que demandait le patron, c'était de "tirer" sur la qualité interne du projet.

Il a été assez simple de montrer qu'elle était la cause des soucis, mais plus dure de prouver son utilité. C'est paradoxal, n'est-ce pas ?

En effet, nous avons mis en place des facteurs clef de performance (KPI) en maillant toutes les statistiques sur les points qu'appréciaient les moteurs de recherche. Nous avons utilisé Google Webmaster Tools (GWT) qui est très utile pour faire des relevés quotidiens des pages en 404, duplicate content, suggestion d'améliorations... Ce fut un progrès considérable mais pas une fin en soit. D'une part on c'est aperçu que la croissance précédente était lié à une émoragie qu'il fallu corriger rapidement, d'autre part, à chaque mise en production, on voyait les bugs !

Au vue des bugs, le patron voulait d'abord que l'on colle un patch et basta. Mais j'ai opté in fino pour une migration progressive des parties du site buggé dans un framework. Cela nous a permis de stabiliser durablement les KPI. Nus avons gagné la confiance du patron par la baisse des retours et bugs. Ceci donna enfin l'impression au patron que la qualité interne était une base fondamentale.

2°) La qualité perçue

Il s'est écouler 6 mois et j'ai eu l'ordre de tout migrer dans le framework, la confiance du patron en prime : "C'est vache maigre depuis 6 mois car le site est buggé de partout, je te donne 1 mois pour tout passer dans le framework cela stabilisera toutes les KPI, avec ça si les visiteurs ne reviennent pas faut que l'on fasse autre chose !".

Nous l'avons fait et pourtant le trafic n'est pas revenu comme escompté, pourquoi ?

Google via les GWT nous a montré qu'il fallait être attentif à la qualité interne. Notre agence SEO également. Mais ce qu'on oublie trop souvent c'est le service rendu à l'utilisateur. Est ce que la qualité perçue est satisfaisante ? La puissance de Google c'est d'intégrer dans son algorithme cette qualité perçue, mais elle est difficilement mesurable. D'ailleurs, Google utilise des approximations en considérant que le taux de rebond, le temps que reste l'utilisateur, ... est un critère de satisfaction utilisateur. Il a dernièrement mis en place un système de vote sur les résultats.

Les axes de travail purent être dès lors la qualité perçe.

Conclusion :

• La qualité interne est un facteur de non échec du service web proposé.

• La qualité perçue est le facteur clef du succès du service web proposé.