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.

extrem programming

  • Gestion de tickets clients

    error404ek2.jpgUne des clés des méthode Agile, c'est de répondre au besoin des clients. Ainsi les priorités de développement sont celles du clients et non de la facilité de développement cet tel ou tel module. Les itérations de développement, cycle d'environ un mois qui répond à un objectif déterminé à l'avance, sont priorisés pour répondre aux fonctions essentielles du projet. A la fin de chaque itération, il est toujours temps de faire des retours ce qui ne remet pas la totlité du projet en cause. Il est entendu que l'intégration du client (ou client interne) au sein du projet est un bénéfice, car lui est mobilisé pour la réussite du projet et les développeurs sont obligés de sortir de leur "mutisme" légendaire de l'informaticien. Pour organiser, à la fois les retours lors du développement et ensuite lors de la maintenance, mettre en place un outil de tickets clients permet une meilleure maîtrise des coûts de retours qui doit être obsession pour chasser le gaspillage.

    Faire son possible pour que les développements soient cadrés, c'est intégrer de la qualité continue grâce à l'extrem programming, qui permet de baisser le nombre de retours, car les bugs sont corrigé au plus tôt grace aux tests. Pour savoir si un projet a déraillé, il faut absolument mettre en place des indicateurs de performance, le nombre de retours clients est l'un d'entre eux.

    J'ai testé OTRS un outil de gestion de tickets. Conserver l'historique des demandes des clients et leurs réponses permet d'allier la qualité de service, tracer les échanges, organiser les échanges et améliorer les chances de succès du projet et des suivants. Un client envoie un mail au service maintenance qui est reçu et archivé par OTRS, comme un help desk digne de ce nom ! Les statistiques du help desk permettent de suivre l'activité des retours. Seul bémol à cet outil, les API encore dans la "todo list". La conséquance est évidente, impossibilité de remonter les stats dans l'outil de X-Programming (Hudsons).

     

    Liens utiles :

  • Un ami nommé Hudson

    Comment dire ? Je suis litéralement tombé sous le charme de Hudson. Bon je sais, je m'emporte, mais en 2 heures, je suis arrivé à ce que je voulais !

    Nous avons un outils de versioning pour faire nos branches, patch, .... Pour le déployement en préproduction ou production, nous utilisons des scripts bash (via rsync). Nous avons des tests unitaires à jouer mais ils étaient joués quand quelqu'un y pensais. Nous avons un bug tracker pour rapporté les bugs des développeurs...

    Nous avions pleins d'outils mais ils se sentaient seuls, limite ils faisaient de la dépression ;). Alors nous avons décider de les réunir autour d'un superviseur. Je préfère ce terme à "outil d'intégration continu" car c'est de cela qu'il s'agit. En fait derière Hudson, il n'y a rien, c'est juste un outil qui réuni tous les autres et qui permet d'avoir une vue consolidée de tous les autres.

    hudson.jpg

    Nous débutons un projet PHP, qui tourne avec le framework Symfony. Alors j'en ai profité pour installer Hudson. Je vous avoue que la première fois que j'ai installé Hudson, je me suis démandé à quoi ça servait tellement c'était vide. Et, j'ai installé quelques plugins et en moins de deux heures, j'ai configuré un environnement qui check le style du code PHP, déploye une version en préproduction en utilisant lançant mes scripts habituels (script + nouvelle base de données) et jeu de tests unitaires via le framework de test de symfony. Si un test casse toute l'équipe reçois un mail (avec le reporting du test qui a cassé). Les tâches s'enchaînent sur le succès des uns et des autres.

    En peu de temps on peut installer un environnement pour commencer à s'aguerrir à l'intégration continue. Me consernant, je me pose encore des questions d'organisation :

    • Comment organiser les tâches ?
    • Ne vaut-il mieux pas découper au niveau de Hudson chaque taches élémentaires et les enchaîné ?
    • Est-il plutôt préférable de regrouper plusieurs actions (déployeemnt et jeu de test) au sein d'un "build" (tache hudson) ?
    • L'intégration de Phing est-elle nécessaire car l'exécution de script bash est possible directement via Hudson ?

    L'usage me donnera les réponses ?

  • Environnement de travail

    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.

  • Agilité

    Je dois dire que depuis que je connais la méthode Agile, j'ai été séduit par ce que j'ai lu sur internet. Il existe de nombreux blogs qui traitent du sujet. Je veux l'aborder sous l'angle de la pratique. C'est cette petite ligne sur ma fiche de poste qui a fait "tilt" : extrem programming, agile.

    J'ai clairement la mission de mettre en place de nouvelles méthodes de travail au sein d'une équipe qui a doublé en 1 an.

    Ce blog me permettra avant tout d'éclairer mes pensées, tester des idées personnelles ou empruntées. J'essayerais de justifier leur utilisation.