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.

Qualité

  • 2011 arrive avec plein d'espoir

    2010 s'en est allé avec une grosse fatigue. Souvenez-vous, nous avons lutté contre les bugs, nous avons rejeté les idées reçues, nous avons rêvé en faisant des plans sur la comète...

    bouton.jpegGrosse fatigue, disais-je ! Oui, parcequ'entre les fêtes et son traditionnel "Rallye gastrique", il y a le travail. Vous savez les petits travaux ménagers dont vous dites tout au long de l'année : "là j'ai pas le temps, je ferais ça quand ce sera plus calme !".
    Tenez par exemple, j'avais laissé un bouton de chemise. Mais figurez vous que j'ai trouvez le moyen de le coudre sur la partie intérieur. Pourquoi vous le partager ? Parceque 2010 était comme celà : pressé par le temps, avec une équipe jeune, nous avons trop souvent cousu le bouton à l'envers !

    chaussures.jpegMais ce n'est pas tout. En 2010, j'ai changé à minte reprises les lacets de mes mocassins. Tout ça parceque un oeillet est tranchant et sectionne lentement mais irrémédiablement et invariablement le lacet au même endroit ! Il a lâché pour la dernière fois ce 31 décembre. Ah ces petits grains de sable laissés au milieu des algorithmes, que les clients découvrent irrémédiablement et invariablement au même endroit, c'est fini en 2011. Espérons !

    Sinon en 2009 et en 2010, il y avait des petites digressions, des petites histoires, des parallèles avec la vie quotidienne, ça il y en aura toujours en 2011.

    Voilà les leçons que j'ai retenu de 2010. Voilà donc les résolutions de mon équipe, sinon ça va barder...

    Bonne et heureuse année 2011 à tous mes lecteurs !

  • Le bug est parmi nous

    bug_vs_feature.gifL'histoire est banal.
    Le manager dit à son développeur : "t'as fait ton taf ?".
    - ah ben oui cette semaine j'ai tout fini. Pis alors j'ai développé le synchro routeur dans le nouveau framework Ajax. C'est génial s'truc là, on va pouvoir instancier une session oauth même avec Facebook Connect.
    - Et t'as corrigé le bug du man (1 man, des men...) ?
    - euh le bug de la modération à partir de 23h ? Celui là oui il est bouclé pour de bon. Je me suis couché à minuit pour vérifier. Ça tourne au poil.
    - c'est chouette...

    Là, la pile de dossier, la fatigue de la semaine, j'ai laisse filer l'argument. Je ne suis pas un manager héroïque. Que je suis faible : méfions nous du développeur qui vous dit réaliser ses tests en vérifiant ... sur le lieu où il a commit son forfait ! A quoi servent les tests unitaires bon sang !

    Le weekend arrive et le samedi, coup de fil du client.
    - Grrrrrrrrr ! je comprend pas la modération marche plus.
    Et flute ! Le samedi et le dimanche c'est modéré en permanence, et là rien. Une bête erreur de condition si "on est samedi ET dimanche" au lieu de "on est samedi OU dimanche".

    Une fois de plus mon médecin avait raison "décidément on ne trouve que ce que l'on cherche".

  • Le hudson de la Fondation Apache

    J'ai déjà parlé sur ce blog de Hudson, un serveur d'intégration continu, c'est à dire un logiciel qui permet de jouer des tâches conditionnels et déployer pas à pas les nouveaux développements d'un projets. Pour mémoire, voici les étapes de développement de logiciel :

    1. Concevoir l'idée, c'est non seulement avoir une idée mais surtout savoir comment on va la mettre en oeuvre.
    2. Planifier ses développements. L'utilisation de méthode Agile inspirée de SCRUM permet d'avoir une démarche itérative priorisant les actions les plus importantes en premier.
    3. Développer avec une méthode comme le développement piloté par les tests (TDD : tests driven developpement). Cela permet de s'assurer à tout moment de la non regression d'un développement en jouant des tests unitaires.
    4. Jouer les tests quotidiennement pour s'assurer que tout avance pour le mieux

    Hudson qui est un logiciel à plugins permet de greffer de nombreux modules d'en faire un tableau de pilotage depuis le developpement jusqu'au déployement voire à l'exploitation de ses produits avec pour obsession le respect qualité.

    J'ai découvert par hasard le Hudson de tout les produits de la fondation apache (ant, subversion, spamassassin, solr, ...). Cela donne une excellente idée de l'organisation de cet outil !

    Solr-Hudson.jpg
  • La dictée de Pivot

    Premier postulat :

    Un bug c'est comme une faute d'orthographe. Parfois, c'est grave et empêche de fonctionner ou de comprendre, parfois moins grave et purement cosmétique. Quand on se relit on ne voit pas toujours ses fautes ou ses bugs.

    Deuxième postulat :

    Il y a des applicatifs et développements web qui sont plus complexes que d'autres. La multitude de fonctionnalités fait qu'un produit devient de plus en plus difficilement maîtrisable pour un seul homme. Pouvoir échanger sur les dépendances entre les fonctionnelités permet d'envisager la suites des développements de manière plus sûre.

    Conclusion :

    Bien souvent certains développements deviennent tellement complexe à force d'ajouter des modules sans architecture logicielle que c'est comme la dictée de Pivot, c'est dure de faire zéro bug !

  • Processus, procédures et automatisation

    Après un long bavardage entre collègues, nous sommes tombés d'accord sur la finalité de la description des processus et des procédures. Pour moi qui suis un ultra procédurier, qui aime bien tout fixer et figer, j'avoue que trop de procédure nuit au bon fonctionnement des procéssus. C'est d'ailleurs presque toujours dans des environnements non maitrisés que l'on met en place des procédures. Mais si on ne prends pas le temps de savoir ce que l'on cherche à cadrer à travers ces procédures, on peu se tromper de cible et le remède devient pire que le mal.

    J'ai vu une entreprise qui a mis en place des procédures pour cadrer le travail des ouvriers en pensant que le problème venait de l'organisation des tâches alors qu'il s'agissait des outils de travail qui n'étaient pas adaptés !

    Donc pour les entreprises qui poussent je précaunise la description des processus pour commencer. Il s'agit de décrire de manière non figée, donc évolutive les us et coutume de l'entreprise. Dans les start-up qui grossissent comme des champignon, prendre le temps d'écrire l'histoire, c'est s'assurer que construire des bases solides. Les employés de seconde, troisième (et plus) génération n'ont pas le même tempérament de créateur d'entreprises et ont besoin d'être rassuré et cadré par rapport au devenir et aux ambitions de l'entreprise encore jeune.

    L'autre intérêt d'écrire les processus, c'est l'automatisation des tâches. C'est particulièrement vrai en production ou exploitation informatique. Je me souviens de précédentes expériences où je regardais circonspect un directeur technique vouloir automatiser un procédé sans même le maîtriser manuellement. On ne peut automatiser un procédé que si l'on maîtrise manuellement toutes les étapes.

  • Croire que c'est pas grave

    Une diférence entre l'exploitation d'un site web en B2C par rapport au B2B réside dans le niveau de confiance que le client peut avoir.

    Prenons l'exemple de failles de sécurité : c'est un problème grave qu'il faut absolument corriger.

    D'une manière générale, faire confiance sur internet est difficile et des sites buggés et peu fiable il en exsite à la pelle. Seulement en b2b l'exploitant prend seul la responsabilité, et le danger est souvent restreint à l'infrastructure et au données éventuellement stockées des utilisateurs. La plupart des services web sont modestes en visiteurs, en revenus, donc en ressource.

    Quand on travaille en B2B2C (les services de forum sur les sites web des média tv ou papiers), le client payant un service à l'utilisateur finale, le livrable est un contrat de confiance. Le fournisseur ne peut pas ignorer les vis de fonctionnement, ni les failles de sécurité. S'il s'agit d'un client grand compte il aura d'autant plus de facilité à se retourner qu'il a de moyen de faire pression. Son image est en jeu, il n'aura aucune pitié.

    Il y a quelques années, j'avais installé le soft de ma société sur l'infrastructure d'un client. En général, l'hébergement restait dans notre périmètre de sorte que nous maîtrisons mieux certains paramètres. Une nouvelle version logicielle était mise en place car nous avions passé l'applicatif de php4 à php5. Pour limiter les coûts et éviter de déployer le soft et réinstaller les serveurs à quelques mois d'intervalle, nous avons livré la nouvelle version tout juste terminée (fonctionellement oui mais tous les tests de sécurité non). Ils étaient content mais une fois notre job terminé, le client a commandé un audit de sécurité. Toutes les failles de sécutité ont été corrigées en une semaine, mais la négociation commerciale qui s'en ait suivi à été très houleuse (pénalité, ...).

    Depuis, quand je suis sur un nouveau projet, je fais des tests, et à tous les coups, je trouve quelques choses. Depuis quelques temps, j'ai élargis les vis de sécurité à tous les vis fonctionnels (bugs critiques) de sorte d'évaluer de manière binaire ce qui marche vraiment sur un service web... Seule 30% des projets informatiques sont des succès (répond au besoin, à été livré à temps en respectant le budget) d'après une étude récente, maintenant, je le comprend.