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.

Produits et projets web - Page 8

  • Définition, théorie et stratégie parce que les projets sont partout

    Je vous propose une histoire en trois volets, pour les trois prochains jours. Aujourd'hui, nous verrons la partie théorique avec une théorie, une définition et une stratégie. Demain et après demain, deux exemples d'application de cette stratégie.

    La théorie de la côté de bœuf :

    cote-de-boeuf.jpgThéorie qui consiste à découper le morceau de viande. Plus le morceau est gros, plus on va mastiquer longtemps en bouche. Par analogie, découper un projet permet d'aléger sa "digestion".

    Le ticket d'entrée :

    Je défini le ticket d'entrée d'un projet par le temps absolu (opposé au temps homme) qu'il est nécessaire d'attendre (pour le chef de produit ou travailler pour un développeur) avant de disposer d'une première solution minimaliste mais fonctionnelle de A à Z. Exemple : le développement d'un site Internet communautaire avec le nombre nécessaire et suffisant de fonctionnalités pour répondre au besoin immédiat et délivré en ligne peut prendre 2 mois tandis que le périmètre fonctionnel final peut prendre 6 mois. Le ticket vaut deux mois. Expérimentalement, le ticket d'entrée d'un projet ne doit pas excéder dans nos start-up 3 mois. Le ROI d'un projet ou chantier en dépend.

    Pourquoi ne pas prendre en compte le temps homme ? Si le projet est vital pour l'entreprise on sera toujours enclin à lui allouer plus de ressource en lui affectant une priorité plus élevée. Plus de trois mois ça doit donner la puce a l'oreille que quelque chose est mal dimensionner ou que l'imprévu prend le dessus.

    Stratégie de l'escalier qui déssert deux étages :

    Stratégie qui consiste à utiliser la théorie de la côte de boeuf afin de mutualiser une partie des efforts dans le but de diminuer le ticket d'entrée de plusieurs projets qui auraient des parties communes. Aussi appellée stratégie "faire d'une pierre deux coups". Cette stratégie est une méthode lean car elle permet d'économiser des temps de muda.

    J'espère vous avoir mis l'eau à la bouche. Les deux prochains articles donneront des exemples concrêts des ces théories. A demain.

  • Evaluer son projet

    Principe : "On ne peut gérer que ce qui se mesure."

    projet1.jpgIl y a quelques semaines je vous parlais du Kanban sur lequel j'affiche des "fiches projets". Ces fiches projets d'une format A4, se veulent synthétiques et résumer pour tous les acteurs du projet l'objectif. Elle se compose de plusieurs paragraphes :

    • Les contacts (emails et téléphones)
    • Le résumé du projet (concept)
    • Les users story (développements spécifiques)

    J'ai organisé la fiche projet en 3 étapes :

    1. Avant le projet : la période de "conception" qui récolte toutes les données (maquettes graphique, ...)
    2. Pendant le projet : la période d'intégration et développement pour le montage du projet
    3. Après le projet : récolte du feedback

    La fiche projet n'est jamais figée. Elle est remplie au fur et à mesure en fonction des nouveaux éléments.

    Les temps d'intégration sont conciliés sur cette fiche ce qui permet de calculer le ROI de chaque projet. Depuis 2 mois que j'ai installé ce système (20 projets environs), il me permet de consulter l'historique pour évaluer les temps d'un nouveau projet par similarité.

    Au final, il devient possible de mettre en évidence l'équilibre Coût / Délais / Qualité / Satisfaction-client.

    D'ici quelques semaines, à la lumière de notre tableau papier, nous pourront développer un ERP sur mesure.

  • Quand mes deux vies se rejoignent

    La première est ici et la deuxième . J'aurais pu écrire ma note sur l'un ou l'autre des blogs. Figurez-vous que le projet d'installation d'une micro-centrale hydroélectrique auquel je participe est dans sa phase de "recette". Dans notre cas on dit mise en route. Pour une usine hydroélectrique refaire de A à Z, c'est 6 mois de boulot : un peu plus que la recette d'une site web !

    Côté organisation, c'est semblable à toutes les recettes en pire. On s'aperçoit que certaines choses ne vont pas. Des petites qui prennent quelques heures et d'autres plus longues qui nécessite du matériel, du technique, de l'administratif, ... Notre soucis est de démarer le plus rapidement possible, question de rentabilité. Ce business étant saisonnier, il faut si possible décaler pour l'été.

    Recetter et résoudre les problème en suivant est d'expérience chronophage. Il est souvent préférable d'avoir une vision globale des problèmes, de les lister, de les classer par priorité et de trouver les solutions.

     

     

    Urgent

    Moins Urgent

    Post production

    Court

    (1 jour max)

    - Chauffe du palier => mettre de l'huile

    - Brancher les capteurs du vérin

    - Courroie non centrée

    - Serrer la poulie sur son axe

    - Lancer abonnement EDF => appeler

    - Connecter la vanne sur l'automate

     

    Long

    - Passage de la courroie => modifier palier

    - suivi chantier toiture

    - creuser le fond du canal de sortie

    - carte d'acquisition

    Ce tableau présente un format de check list classé. C'est génrique pour l'industrie ou le web ...

    L'avantage, c'est que l'historique des solutions peut-être conservé au cas où le problème revient quelques années plus tard.

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

     

  • L'humilité des développeurs

    Vous trouverez cela surprenant, voire choquant que je puisse ici reproduire une photo des toilettes de nos bureaux. Pardonnez l'indélicatesse, mais les solutions aux problèmes métaphysiques (sic) se résolvant souvent dans des lieux incongrus, je vous livre telle quelle ma réflexion. Je commencerais donc par une question : y-a-t-il sur cette photo quelque chose qui vous choque ? Non ?

    P1040456.JPG

    Le détail est que le rouleau est posé à l'envers et qu'il faut, quand on est placé sur le "fauteuil" tirer vers le fond pour déchirer une feuille de papier toilette, obligeant une contorstion ! C'est un petit détail mais qui à l'usage à son importance. J'aurais pu me plaindre pour qu'on daigne changer la situation, mais auprès de qui ? il faut que je croise le technicien de Elis ... Cela en vaut-il la peine ? Qui l'avait vu ? On peut faire avec ?

    Voilà toutes les remarques que se posent tous les jours mes clients à propos des logiciels que nous fournissons, surtout ces clients. L'exigence du petit détail c'est important, même plus : primordiale.

    Je me suis longtemps demandé comment qualifier l'état d'esprit d'un développeur qui réussi parce qu'il se pose les bonnes questions. Je crois que j'ai touché du doigt il y a peu la solution. Pour moi un bon développeur doit être avant tout humble devant le problème posé. Humble cela veut dire... Tiens cet exemple, plus haut, qui n'a rien à voir bien sur mais qui permettra à tout le monde de voir de quoi je parle. Dans la pratique le technicien de Elis qui pose le rouleau à l'envers, car c'est plus simple pour lui quand il le met en place, s'est-il mis à la place de celui qui va l'utiliser ? Le développeur humble, c'est celui:

    1. qui sait se met à la place de celui qui va utiliser son produit.
    2. qui doute à tout moment de ce qu'il faut dans le sens qu'il sait se remet en cause.
  • De l'art et la manière de gérer les projets web des clients

    Ma société a géré en 2009 plus de 150 projets clients avec en moyenne une centaine d'heure de travail pour une équipe de 6 personnes. Avant d'aborder 2010, il nous fallait préparer la croissance en utilisant un outil adapté. On pense souvent qu'un ERP permet de gérer de A à Z les processus d'une entreprise. C'est pas toujours vrai. En période de croissance rapide, il est souvent difficile d'utiliser un outil lourd et long à mettre en place que tout le monde doit s'approprier et pour lequel connaître son activité est essentiel pour la réussite de sa mise en place.

    KANBAN.jpg

    Pour 15 Euros (tout compris), voici un ERP "maison" qui nous permettra d'étudier plus souplement notre business et développer en interne l'outil informatique qu'il nous faut pour piloter notre activité.

    Objectif :

    • améliorer la visibilité sur les projets en cours
    • fiabilité les rendus
    • rendre plus autonomie chaque acteur
    • communiquer sur l'état d'avancement d'un projet
    • alerter des retards d'un projet

    Pour cela nous avons mis en place un Kanban : tableau d'étiquettes.

    Pourquoi une méthode japonaise et pourquoi pas scout non plus ?
    Les japonnais et surtout Toyota ont inventé des méthode d'une efficacité redoutable appliqué dans de nombreux domaines. Si ça marche dans l'industrie, pourquoi pas chez nous.

    On a déjà essayé des calendriers géant ça n'a pas marché, pourquoi Kanban marcherait-il ?

    Parceque Kanban n'est pas un calendier. Il a pour but et finalité d'apporter plus de solution que de contraintes et permet de responsabiliser tous les acteurs d'un projet.

    Comment ça marche ?
    Il s'agit d'une liste de tache (workflow) à réaliser et dont on bouge l'étiquette au fur et à mesure du "cap" qu'elle franchi. Il existe 5 caps :  signé (une fiche projet est alors crée avec le détail de la mission), conception (les inputs sont rassemblé et les développements custom font l'objet de spécifications), intégration (le développeur et l'intégrateur sont en cours de travail), en recette puis en production. Si une tache pose problème, on peut coller un post-it de couleur pour indiquer au chef du projet ou produit qu'un point de blocage empêche de poursuivre, ou que la tache nécessite un arbitrage (choix d'ergonomie par exemple).
    bulle-kanban.jpg

    Entre chaque étape, les conditions de passage d'un projet sont soumise à condition. Des bulles sont là pour mémoriser les "check points" de la gestion du projet.

     

    Sur quel projet cela s'applique ?
    Tous les projets clients de plus de 2 jours.

    Qui met a jour les étiquettes ?
    Chacun à son niveau : développeur, intégrateur, exploitation.

    Qui choisi les tâches à effectuer ?
    En général, une réunion quotidienne appelée daily standup meeting, devant le kanban, permet d'affecter à chacun des tâches. D'un coup d'oeil, tout le monde sait où en sont les autres membres de l'équipe. Donc si un membre est absent, on sait où il en est.

    Sur quels critères sont-elles partagées ?
    Ce n'est pas encore une habitude de travailler ainsi et le Kanban permet de raccourcir les temps de développements (puisque que plusieurs développeurs ou intégrateurs travaillent sur le même dossier en même temps). Cela permet d'être plus réactif auprès des clients et de fournir un travail de meilleur qualité.

     

    Parrallèlement à cette mise en place papier nous travaillons sur un outil informatique pour récencer et historiser toutes les données des projets et relier l'ensemble des services de l'entreprise (technique, exploitation, communication, facturation, bureau commercial, SAV, ...).