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.

  • Environnement de développement

    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 !

  • Private joke

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

  • De l'importance de la reflexion

    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 :

    sadt.jpg

    Ce qui donne avec un exemple : "payement de son panier sur un site de vente en ligne"

    exemple-sadt.JPG
    On peut affiner le diagramme en détaillant les box jusqu'à définir les actions élémentaires.

    J'aime bien cette méthode car :
    • ce diagramme est compréhensible par tous
    • même le chef de produit est capable de le réaliser
    • sans ce savoir il me mâche le travail car chaque boite représente
      • une étiquette de mon kanban (une ligne du backlog) et prépare donc le planning de mon sprint
      • en utilisant un framework MVC (zend ou synfony), le développeur visualise le module, le Zend_Controller_Dispatcher (zend) ou les sfActions (synfony) et la listes des tâches organisées (Zend_Controller_Action ou les classes étendues de sfBase)

     

  • De la définition de l'équipe projet...

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

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