Tag: projet

Comment (bien) rater un projet ?

Posted by – December 20, 2008

Préambule

Il y a plusieurs contextes à la réalisation d’un projet, et j’en compte notamment 2 : en tant qu’équipe d’une SSII qui travaille pour un client, en tant qu’équipe interne d’une entreprise finale pour développer des projets internes. Je me situe dans la 2eme catégorie. Chaque organisation a une dimension politique, et la mienne ne déroge pas à la règle, voire un peu plus que la moyenne, où pour arriver à son objectif, il faudra alors parcourir un terrain jonché d’obstacles qu’il faudra lever.

Chaque catégorie aura ses propres contraintes : ne pas dépenser plus de jours à ses frais qu’il n’en faut pour l’un et que ça rapporte un max, contrôler ses projets et son S.I. pour l’autre. Les points ci-après ne constitue en rien une liste exhaustive, juste tirés d’un vécu tout personnel, on pourra la compléter si besoin.

More

Gestion de projets : quelques outils en ligne

Posted by – November 5, 2008

Un de nos apprentis ingénieurs m’a demandé conseil sur les outils de gestions de projets, en mode collaboratif.

En gros, les besoins remontés étaient :

  • en ligne
  • accès par plusieurs membres d’une équipe
  • avoir la possibilité de déposer des fichiers
  • repository de sources

Parmi les applications disponibles, une liste non exhaustive de ce qu’il peut exister :

  • Google Code : gratuit – intégration SVN (rajoutez bien entendu TortoiseSVN), Wiki, dépôt de fichiers, plusieurs membres. Je l’utilise pour mes exemples de codes, et ça marche plutôt pas mal (http://code.google.com/p/mysampleapp)
  • Redmine : gratuit – certainement le challenger (développé en Ruby On Rails) le plus sérieux à Trac (en python et un peu une galère sans nom pour l’installer) – à héberger chez vous.
  • GitHub : gratuit pour une version allégée – intégration Git, interface très bien faite (à la Web2), user friendly dira-t-on et une approche sociale, Wiki, indicateurs graphiques (commits, langages utilisés, …) – beaucoup de projets RoR sont gérés sur cette plateforme. Git, développé à l’origine par Linus pour gérer les sources du noyau en mode distribué. Au passage, un cheatsheet sur Git.
  • Codeplex : la plateforme MS d’hébergement de projets. Intégration TFS / SVN, Wiki, stats., évolutions proposées aux votes. Pour l’avoir essayé, l’inscription est assez laborieuse, et surtout, si votre projet n’est pas actif, il est, purement et simplement effacé.

Pour une gestion de plus haut niveau, c’est à dire, liste de tâches, milestones, on pensera à Basecamp, gratuit pour une utilisation légère (1 projet) : interface simple, usage cohérente d’Ajax, intégration OpenId, pratique pour ne rien oublier.

Mise en ligne : méthode pour (semi-)industrialiser ses développements

Posted by – January 13, 2008

En fin de semaine dernière, ce fut la mise en ligne de la V8 de notre [superbe] plateforme d’applications. Nous éditons/développons sur cette dernière plusieurs applications Web en mode extranet pour quelques milliers d’utilisateurs.

Ce qui peut-être intéressant, c’est d’expliquer les différentes étapes du développement d’une nouvelle version d’un logiciel à son déploiement le jour J, pas LA méthode, mais au moins une qui est utilisée depuis quelques années et qui s’avère efficace.

En préambule, le délai entre 2 versions est dans la mesure court (2, max 3 mois) afin de réduire au maximum le taux de bugs1 et de faciliter la mise en ligne2. Egalement, un gestionnaire de sources (VSS, SVN) est hautement recommandé lors de développements en équipe. Idéalement, la plateforme de validation/recette est à l’identique de la plateforme d’exploitation : si cette dernière a 3 serveurs alors la validation en aura 3, etc.

Phases entre une version V, et une version V+1 :

développement de la V+1

Le développement des évolutions d’effectue sur la branche de développement (plateforme de développement). Cette branche est continue, et elle est juste flaggué ou libellée (étiquette sous VSS) à chaque nouvelle version. La dernière étiquette est par exemple v7.3 (version V). On peut ainsi retrouver les sources d’une version d’il y a 5 ans si on le souhaite.

Chaque chantier ou projet est bien évidemment mené en mode projet.

Chaque développeur qui est chargé d’un chantier doit remplir au moins 2 fichiers :

  • chaque modification de configuration est noté dans un fichier : ajout de clé, suppression, …
  • chaque modification du schéma de base est scripté (ALTER, CREATE, DELETE, …)

phase de validation, recette – tests

Cette phase permet de valider les nouveaux développements, d’un point de vue fonctionnel (est-ce le besoin attendu a bien été développé), et technique (en gros…les bugs).

Une fois la planification d’un mise en ligne (mise en exploitation de la version V+1), les développements sont arrêtés au moins 2 semaines avant : plus d’ajout de code n’est toléré, la correction de bugs (pannes franches, performances) est la seule possibilité.

La plateforme de validation-recette est préparée à l’identique de ce que sera l’exploitation V+1. Plusieurs itérations peuvent être nécessaires, cette validation sert non seulement à recetter les applications mais aussi la mise en ligne qui aura lieu le jour J :

  • on part d’une base de données à l’identique de l’exploitation (backup exploitation, restore sur validation), avec certaines données modifiées pour la validation (principalement les e-mails).
  • déroulement du script SQL sur cette base
  • déploiement des sources sur la plateforme de validation : utilisation d’un script avec des commandes XCOPY afin de recopier dans un répertoire de déploiement les application (web ou pas) à installer
  • modification des configurations par application

Une fois la plateforme en place, la recette peut commencer.

A chaque ensemble de dysfonctionnements, bugs corrigés, un nouveau déploiement des applications devra être effectué, et recetter ce qui a été corrigé. Cette phase de validation est itérative, jusqu’à ne plus trouver…de bugs, même si le 0 défaut reste utopique.

mise en ligne

Les applications sont recettées, prêtes à être déployées sur la plateforme d’exploitation. Le jour J à telle heure est le jour de la mise en ligne de la nouvelle version.

Avant le jour J, nous établissons une todo list qui énumère de façon la plus exhaustive possible toutes les opérations qui seront à effectuer sur chacun de serveurs pour la mise en ligne le jour J. Par exemple :

frontal :

  1. sauvegarde des configurations
  2. sauvegarde des répertoires sources des applications Web (typiquement c:\\inetpub\\wwwroot)
  3. pages de maintenance
  4. mise en place des applications : copie manuelle dans les répertoires idoines ou exécution des setup pour les applications packagées
  5. modification des configurations selon le fichier tenu lors des développements
  6. etc.

sql :

  1. backup des bases
  2. déroulement du script de modification de schéma de base
  3. copie des procédures stockées
  4. etc.

serveur y :

  1. tâche 1
  2. tâche 2
  3. etc.

Les tâches ne sont pas forcément linéaires, certaines seront effectuées en parallèle, certaines sont subordonnées à d’autres (page de maintenance avant les backups par exemple) : plusieurs membres de l’équipe participent au déploiement.

Cette todo list sert notamment à réduire au maximum la réflexion (ie : que dois-je faire précisément) durant la mise en exploitation, que celle-ci soit dirigée par des tâches à dérouler simplement. En effet, toute mise en ligne reste toujours stressant (je vous assure que d’arrêter une plateforme pour des milliers d’utilisateurs reste toujours impressionnant), donc elle doit être très préparée.

L’improvisation est anecdotique et doit être limitée. Cela évite d’entrer dans une routine qui conduit forcément à faire des erreurs : malgré des dizaines de mises en ligne, le stress est toujours présent et doit le rester pour garder toute vigilance lors d’une mise en ligne.

L’heure arrêtée pour la mise en production, nous déroulons les grandes phases pour une mise en ligne réussie.

  • upload des sources (script de déploiement xcopy + FTP) sur le serveur
  • page(s) de maintenance (‘le site XY est en cours de maintenance, veuillez nous excuser de la gêne occasionnée, bla bla’), un fichier App_offline.htm vous sera bien utile pour une plateforme .NET.
  • déroulement de la todo list (backup bases, sites, scripts, …).

Une fois toutes les opérations effectuées, nous pouvons remettre en ligne l’ensemble de la plateforme, et allumer un cierge ;)

Normalement, avec les itérations de recette sur la plateforme de validation (test applications, test mise en ligne), nous avons jamais eu à revenir en arrière. Les seuls dysfonctionnements sont souvent liés à des questions d’optimisations3 (services Web, ORM, moteur de recherche, …) qui se révèlent bien souvent qu’en exploitation (nombre de connexions plus élevées qu’en validation). Pour éviter cela, nous pourrions stresser la plateforme de validation, c’est à dire de simuler un grand nombre d’accès (avec ab) afin de relever les problèmes à ce stade le cas échéant.

La plateforme étant rouverte, nous effectuons des tests unitaires (manuels) sur les différentes applications, sur les grandes fonctionnalités, et sur les nouvelles. Certains batchs sont également lancés en mode simulation.

l’après mise en ligne

Nous laissons au moins 2 jours avant de flagguer, voir si nous avons des retours de dysfonctionnements de l’application (notifications des erreurs d’applications) ou directement par le support. Pendant cette durée, les développements restent figés (ie : personne n’écrit de code).

Une fois que nous estimons que la version est stable, ou du moins qu’il n’y a pas de pannes franches qui font tout planter, nous finalisons la version :

  1. libellé (flag) de la version courante sur le gestionnaire de sources (VSS) : on libelle la racine de la version mise en exploitation (v8 par exemple, branche d’exploitation) : cela a pour but de créer une branche à l’identique de l’exploitation : à ce stade, les développements peuvent reprendre sur la branche historique de développement.
  2. mise en place d’une station avec l’extraction (grâce au libellé précédent) des sources à l’identique de l’exploitation (branche exploitation), et de la solution Visual studio prête. Cette image de la plateforme d’exploitation (sources, bases de données) servira uniquement à la correction de bugs (fix), correctifs déployés sur l’exploitation. On y gagne en efficacité d’avoir une station dédiée à la correction. Les correctifs sont bien sûr répercutés sur la branche de développement.
  3. rapatriement d’une image de la base de données d’exploitation : servira à la station précédente.

conclusion

Comme on peut le voir, le développement logiciel est affaire de rigueur et de professionnalisme, peu de place ici à l’improvisation sauf cas d’urgence (correction d’un gros bug bloquant par exemple). Un seul objectif : descendre au maximum le risque de dysfonctionnements, et d’arrêt des services, pour la plus grande satisfaction des utilisateurs, enfin, nous l’espérons.

Et comme j’aime bien quantifié, depuis le dernier décompte du nombre de lignes de code, nous passons de 219 000 à 221 000, soit +2 000 lignes de code (C# + HTML (aspx) + JS). Cela reste négligeable en regard des nouvelles fonctionnalités apportées. Ceci peut s’expliquer par le refactoring automatiquement fait sur le code existant, en plus de développer de nouvelles fonctionnalités. Le refactoring consiste à revoir le code, en le factorisant, en fédérant toujours plus les services (approche SOA), et éviter ainsi la répétition de code (principe DRY).

1 très lié au nombre de nouvelles fonctionnalités (fonctionnelles, ou techniques)

2 du changement des schémas de base de données, à la modification des configurations, ou tout simplement au déploiement des applications.

3 ou plus récemment, d’un problème lié au composant RssToolkit et à sa méthode de cache qui semble poser problème en exploitation (vraisemblablement un effet de bord de l’anti-virus).

La réunion

Posted by – December 9, 2007

Depuis le temps que je pratique la réunion et le nombre d’heures de vol, cela méritait bien un billet sur le sujet.

Avant la réunion

Mais qu’est-ce qu’une réunion ? on peut déjà répondre que ce n’est pas une rencontre informelle, qui ressemblerait à un salon de thé, à discuter sans but précis, et sans limite de temps ou d’espace. Même si par expérience des réunions informelles peuvent se créer à l’improviste…

La réunion commence avant même d’y participer, quelques questions qu’il faut se poser avant de la lancer : est-elle nécessaire ? autrement dit, a-t-on besoin de se réunir pour régler telle ou telle question, un mail, ou une courte discussion ne seraient-il pas suffisants ? quel objectif a-t-on à provoquer une réunion : une réunion sans objectif et but précis ne présage rien de bon.

A ce stade, nous avons une raison suffisante et nécessaire de faire une réunion : un objectif (réunion de point projet, d’équipe, de recette, de lancement de tel projet, d’information, de présentation de tel produit, …).

Maintenant que nous savons pourquoi nous avons besoin d’une réunion, il reste pour la préparation à : déterminer les participants et la pertinence de leur présence, ainsi que d’établir un ordre du jour assez exhaustif. Parfois, dans cet ordre du jour, j’inclus la durée de chaque partie, à titre d’indication et pour tenir l’objectif de ne pas dépasser la durée que je me suis fixée (30 mn, 1h30, max 2h).

Invitations

J’ai un objectif, un ordre du jour, des participants. Au niveau logistique, réserver une salle (avec ou sans rétroprojecteur, tableau blanc, etc.). On évitera dans la mesure du possible son bureau : pas de téléphone, pas de mails, pas de visites impromptues.

L’invitation que l’on envoie aux participants (mail, calendrier) contient l’objectif de la réunion, l’ordre du jour, heure de début et de fin.

Pendant

La réunion commence à l’heure et finie à l’heure. Le respect de la durée est important, si l’ordre du jour est trop large alors soit le réajuster, soit planifier une autre réunion. Les retardataires s’installeront et prendront en cours les débats.

Avant de commencer : bien accueillir les arrivants (café, …). Une fois assis, remercier les personnes d’avoir répondu présent, et également toujours rappeler l’ordre du jour afin de s’assurer que tout le monde est d’accord avec ce dernier, quitte à rajouter des points (en restant raisonnable) que souhaiteraient aborder les gens. On demande un volontaire pour rapporter (compte-rendu) l’ensemble des débats.

Toute réunion devrait se dérouler avec bienveillance : cela signifie écoute et respect du point de vue de l’autre, donc on évitera dans la mesure du possible les sarcasmes, ou autre second degré.

Lorsqu’il s’agit de projets, celui-ci aura certainement plusieurs réunions de programmées. Aussi, à la fin de la rencontre, proposer et arrêter la prochaine date (voire plus) de réunion.

Après

Le livrable d’une réunion est constitué par le compte-rendu. Celui-ci contient tous les points abordés, ainsi – important – que le plan d’action (X fait Y) à mettre en oeuvre pour accomplir le ou les objectifs de la réunion. On pourra bien entendu faire recetter le compte-rendu par un ou deux participants pour sa validation avant une diffusion à l’ensemble.

Le compte-rendu permet d’acter les décisions, et surtout de bien s’assurer que tout le monde a bien compris les mêmes choses. Il servira aussi de fil conducteur dans le cas où d’autres réunions sont prévues : rappel de la précédente, ajustement le cas échéant de points mal compris , à modifier, …

Conclusion

Comme on peut le voir, une réunion constitue déjà un projet à elle-seule (un mini projet) dans la méthode : objectif, participants, planification, recette, livrable, qu’il conviendra de bien gérer afin de garantir un maximum d’efficacité. De part cet aspect, entre la préparation, le déroulement et l’après-réunion, prévoyez dans votre agenda de 2h à 1/2 journée voire plus, selon le rôle que vous tenez.

Maintenant, à vos agendas !

Evolutions d’un logiciel ou d’un produit : votes en ligne

Posted by – October 14, 2007

Intéressé par phpmyvisites1, j’ai pu voir que les auteurs avaient mis en place un site dédié aux demandes d’évolutions, et plus spécifiquement, orienté feedback. J’avais déjà vu cette méthode sur CodePlex : soumettre les demandes d’évolutions aux votes des utilisateurs.

Ce type de solution peut être clairement bénéfique, lorsque l’on voit la difficulté de décider de telle ou telle évolution sur un produit : laquelle sera la plus légitime, cohérente, utile, pertinente…

On rend ainsi la responsabilité aux utilisateurs de décider, et d’arbitrer les choix. Cela les implique aussi, se sentant plus concernés par le produit.

Vive la démocratie, produit à essayer, une bonne idée à tester.

1 la version 2.3b4 intégre un plugin d’analyse de zones chaudes. Fonction qui peut être utile pour l’analyse des clics des visiteurs, afin d’optimiser au mieux sa disposition de page.