Ok

En poursuivant votre navigation sur ce site, vous acceptez l'utilisation de cookies. Ces derniers assurent le bon fonctionnement de nos services. En savoir plus.

développement

  • La règle du ticket d'entrée dans des chantiers à forte valeur ajoutée

    Après avoir traité la stratégie face au chantier d'élimination du muda (gâchi), nous allons nous détailler la mise en place d'une organisation lean pour le développement de logiciel.

    Le cercle vertueux de développement logiciel

    Voici les actions que nous allons mener dans les mois qui viendront. Nos produits sont relativement jeunes et ont besoin de souplesses. Leurs contours initiaux éolluent en fonction des projet et des besoins clients. Lors des premiers cycles de développements, il faut prendre garde à ne pas trop marquer le produit par les volontés d'un unique client.

    cercle-produit.jpg

    Ce cercle vertueux est un cycle d'étude et développement que l'on peut retenir pour concilier la qualité, la rapidité d'exécution et la souplesse dans la gestion de la Road Map produit.

    Comment cela se passe ?

    Le backlog produit c'est la liste des fonctionnalités à développer. Quand on gère un produit web qui n'est pas encore mature, on vend au client un projet web. C'est les idées du client qui enrichissent fonctionnellement le produit. Une réunion mensuelle, réunion de planification, permet à la lumière des études du mois passé de sélectionner en fonction des priorités et de la charge, ce qui rejoindra le développement. Les éléments sélectionnés constituent la release ou backlog de sprint.

    Un cycle (sprint) dure un mois. Cela permet d'entamer des gros chantiers. Parallèlement, une livraison hébdomadaire des développements permet d'assurer des recettes sur les serveurs de préproduction plus courte et livrer des projets qui demande certaines fonctionnalités. Un cycle comprend une partie étude technique préléminaire au gros chantier du mois à venir et une partie développement. En cela, je m'écarte de la méthode SCRUM pure, nous ne sommes pas suffisamment nombreux. Je considère qu'une étude de faisabilité est souvent plus importante que le développement que c'est un travail apparentière.

    Pour les développeurs les plus juniors, j'ai mis en place des fiches de développements. Un chef de projets ou produits décrit fonctionnellement le besoin puis je détaille techniquement, en relation avec le responsable R&D, la meilleure manière technique d'arriver à la solution.

    Les bénéfices

    • Préparer le terrain par des études c'est s'assurer de ne pas avoir de surprise et de ne pas exploser le sprint.
    • L'autonomie dans les livraisons permet d'évaluer son rythme et de se mettre une pression "seine" en fonction des attentes des clients.
    • Avoir une idée des chantiers à 3 ou 6 mois (c'est beaucoup dans le web) permet d'anticiper (son plan RH, la sortie d'un nouveau produit, ...)
    • Les arbitrages fonctionnelles du produit sont fait par le chef des produits par le feedback permanent avec le développeur.

    Conclusion

    Les cycles permettent une remise en cause régulière de ce que l'on fait. Même si on jette à la poubelle un sprint car le besoin n'est plus là on a perdu qu'un mois. Le cahier des charges suit le besoin au plus près. Imaginez faire six mois de dévelloppement et arrive au constat que l'on est à côté de la plaque car le cahier des charges a été construit au début à partir d'arbitrages fonctionnelles judicieux à la hauteur des connaissances du démarage d'un projet.

  • Jouer à cache cache pour aller à toute vitesse

    Tour d'horizon des solutions de cache Open Source en environnement LAMP.

    Problématique :

    tortue-fusée.jpgLes prix des serveurs, ce n'est pas un scoop dépendent des performances de ceux-ci. Or quand on gère un parc de plusieurs centaines de machines, chaque serveur à une fonction dédiée : serveur web (apache), base de données (mysql), de fichiers, de cache, d'email, ... Cela permet de conserver une simplicité dans la maintenance et ram.jpgsurtout d'adapter les caractérisques aux besoins : de la RAM et des disques rapides pour les BDD, etc. Ces dernières années, l'apparition des web service impose des temps de réponses de plus en plus court pour ne pas pénaliser des utilisateurs. D'un autre côté le prix de la RAM a considérablement baissé au contraire de la performance des disques où pour obtenir des vitesses d'accès au données il faut débourser de plus en plus. Il apparaît donc évident que nos logiciels doivent de plus en plus passer par des systèmes de cache en mémoire vive et limiter les accès au disque dur.

    Principe :

    N'accéder à une donnée située un disque qu'une seule fois sinon c'est gâcher ! Or gâcher, c'est Muda et Muda c'est pas Lean !

    Tour d'horizon par type de données (classé par impact sur l'équipe de développeurs) :

    • Cache opt-code

    Quand vous développez avec un language interprété comme PHP, un point noir ralentissant le temps de réponse de l'applicatif se situe dans le besoin pour du serveur web (Apache) d'accéder et d'interpréter à chaque requète les fichiers PHP. C'est souvent un point critiqué et critique des framework PHP (Synfony et Zend) ! Il existe donc des solutions comme EAccelerator ou X-cache. Ces softs mettent en cache une version compilée des fichiers PHP ce qui permet de gagner du temps. J'ai réalisé une étude sur le sujet l'année dernière qui montrait un gain de 40% ! Ce genre d'optimisation n'a aucun impact sur les méthodes de développement et apporte un gain significatif.

    • Cache de fichiers statiques

    De plus en plus de fichiers statiques sont chargés sur les sites. On entent par fichier statique des fichiers javascript, css, images, ... Les interfaces de plus en plus conviviales du web 2.0 proposent des effets visuels certes sympa mais qui alimentés par des librairies javascript parfois lourdes donc longue à charger. Comme ces fichiers changent rarement et sont souvent chargées, l'idée est de les monter en mémoire et de ne plus accéder au disque. Un serveur de proxy cache comme Squid permet de faire cela. Là encore, cela ne changent pas les habitudes des développeurs. Il faut pense à placer les fichiers sur un domaine différent pour faciliter la mise en place.

    • Cache de page dynamique

    Pour ne pas avoir à éxécuter toutes les requètes en base de données tant qu'une modification n'a pas été apportée, il est fréquent de placer le contenu d'une page en cache. Memcached est une solution pour placer variables et contenu en mémoire vive. Cela permet de placer des données fréquents utilisées (configuration, ...) ou la home d'un site. Là encore cela court-circuite des étapes longue et couteurse en temps. L'impact pour le développeur est pas nulle il devra prendre conscient de l'intérêt du cache. Le fonctionnement en développement (sans cache) et en production (avec cache) peut être sensiblement différent. Il conviendra donc de tester tous les cas d'utilisation ce qui peut ralentir les recettes et complexifie légèrement le développement.

    • Cache de base de données

    Il y a plusieurs possibilités. Les plus simples sont de mettre en cache (dans memcache par exemple) le tableau de résultat d'une requête. La librairie ADODB, qui est une somme de classes PHP permettant de se connecter sur plusieurs type de base de données relationnelles. Pour pousser plus loin il est parfois préférable de monter en mémoire le contenu intégrale d'une ou plusieurs tables et de faire des manipulations sur le jeu de données pour exclure des enregistrements qu'on ne souhaiterait pas retourner. L'expertise pour savoir quelle méthode est la plus adaptée est déjà plus avancée. Pour les requêtes de type "full text", il conviendra d'utiliser un moteur d'index (de recherche). Les solutions comme Sphinx, Lucene Sol'R sont parfaitement adaptées pour des usage intensif de ce genre de requêtes. Elles gèrent des caches mémoires en fonction de l'utilisation des données ce qui garantie une efficacité dans les temps de réponses. De plus, elles peuvent être distribuée et redondée garantissant une évolution sans contrainte. Il suffit de plugger un nouveau serveur et c'est parti. Les index sont des sortes de bases de données non relationnelle c'est pour cela qu'elles sont plus évolutive (scalable). Une nouvelle tendance de 2009 est justement la vague NoSQL. CoucheDB par exemple est une solution de stockage de données "à plat" (une seule table avec des entrées appelées documents). Il existe plusieurs solutions qui ne sont pas encore dominant car pas suffisamment mature. Ces bases de données vont changer radicalement la façon de développer et pour le coup l'impact pour une équipe de développement est très fort.

    Projection pour 2010 :

    Puisque c'est la fin de l'année, voici ma vision pour 2010. A mon sens, les bases de données NoSQL ne l'emporterons que celles sauront être efficace en recherche full text. Il y a un enjeu considérable à présenter de manière efficace les données texte (courbe de buzz d'un tag, analyse sémantique et du sentiment) parmi les contributions du web 2.0.