Un Electron Libre...

Aller au contenu | Aller au menu | Aller à la recherche

Intégration

Réflexions liées à mon emploi au sein de l'équipe Intégration chez JCDecaux

Fil des billets - Fil des commentaires

jeudi 9 octobre 2008

SSII & Certification

Par NiCoS le jeudi 9 octobre 2008, 23:07

Il n'est pas rare qu'une SSII soit retenue de part l'expertise qu'elle possède sur un produit (jusque là rien d'anormal) mais aussi car elle ou plusieurs de ses collaborateurs sont certifiés sur le produit X. Cet argument de certification étant forcément utilisée d'uen façon ou d'une autre par l'équipe commerciale pendant la phase d'avant-vente.

Le client, dans sa phase de choix entre plusieurs prestataires, peut donc retenir cet argument (mais pas uniquement) pour sélectionner le prestataire à qui il confiera au final la réalisation de son projet.

Cependant, pendant la phase de réalisation, il arrive que les personnes travaillant sur les projets ne soient pas les personnes certifiées ou aient une expérience faible à moyenne de l'outil en question. Ceci pouvant générer des problèmes sur la qualité du livrable final ou sur les délais de réalisation. Ceci ayant pour conséquence une insatisfaction du client au final. (Je n'aborde pas le cas où tout se passe bien, car dans ce cas "tant mieux").

Je me pose du coup les questions suivantes :

  • Faudrait-il demander à la SSII en question que si elle use de cet argument, alors elle s'engage formellement à fournir les profils certifiés ou dans la cas d'une certification globale au niveau de la société, de fournir des profils avec une expérience suffisante et pouvant se présenter pour la certification ?
  • Faudrait-il que la SSII présente deux grilles de prix pour un projet donné ? Une grille avec les profils certifiés et une grille avec les profils "standards" en partant du principe que la qualité se paye... Libre ensuite au client de choisir la grille en fonction de son budget...

D'autres idées ? Vos avis ?

Si le sujet de la section d'un prestataire vous intéresse, je vous invite à lire les billets d'Olivier Mansour dans la série Acheter des prestations informatiques, qui sont je trouve assez pertinent.

9 commentaires

vendredi 3 octobre 2008

Bien réussir son exercice de PRA

Par NiCoS le vendredi 3 octobre 2008, 23:46

Ci-après différentes notes liées aux deux exercices de PRA (un de test sur un périmètre limité et un vrai sur un périmètre complet) que j'ai vécu au mois de septembre :

  • Il est impératif de communiquer et de s'assurer que la communication est bien descendue à travers toute l'entreprise. Cela évite les mauvaises surprises pour les utilisateurs et les grognements de ces mêmes utilisateurs pendant l'opération de PRA (et qui font perdre du temps et de l'énergie aux équipes mobilisées)
  • Pour un exercice de PRA à une date donnée, il est impératif d'impliquer le plus tôt possible les principales personnes impactées par l'opération afin de s'assurer que rien n'est oublié et que tous les environnements sont bien pris en charge (et par extension, que les utilisateurs de ces environnements soient bien prévenus de l'opération)
  • L'ordre d'arrêt est en général applicatif > base de données > service "bas niveau" (Annuaire, Messagerie, Contrôleur de Domaine, DNS, etc) > Système d'exploitation. Pour redémarrer, faire l'inverse. Le faire dans un autre ordre est contre productif
  • Dans le cadre d'une exercice préparatoire ou d'une simulation, il faut jouer le PRA dans des conditions de PRA et non des conditions approchant celles du PRA.
    • Une machine éteinte, cela n'est pas la même chose que la machine allumée mais avec l'applicatif éteint/arrêté par ex
    • Ca permet aussi d'avoir de bonnes surprises (oh tiens, un lien de secours est en place) et des mauvaises (tiens, une machine qui n'aurait pas du être impactée l'est suite à des histoires de routage par ex)
  • Pour les applications qui n'ont pas de PRA et qui ne seront donc pas disponible pendant l'exercice de PRA, s'assurer que par effet de dépendance, elles ne vont pas vous mettre une application hors service.
  • Pour les applications ayant un PRA actif, que ce soit pour le passage en PRA ou le retour en état nominal, veiller à ne pas perdre d'information et données (synchronisation de bases, fichiers, etc) et que les applications pointent bien vers les bons environnements (et non un mix d'environnement de prod et pra par ex). La désactivation des environnements de PRA peut aider à valider que le retour en prod est bien complet. Cela peut se faire en deux temps : arrêt des services, puis arrêt des environnements.
  • S'assurer bien sur que l'on a des sauvegardes et faire des tests de restauration
  • Avoir du matériel en stock pour palier aux pannes (alimentation, disques dur, etc)
  • Tester, tester et tester que tout est ok tant techniquement que fonctionnement.

Avis ? Questions ? Retours d'expérience ?

aucun commentaire

lundi 8 septembre 2008

En 2008, ça se fait encore...

Par NiCoS le lundi 8 septembre 2008, 13:38

Besoin : afficher les 8 dernières actualités et mettre en place un système de pagination pour accéder aux actualités

Réponse obtenue et livrée d'un développeur d'une SSII :

  • Récupération de toutes les news (via l'équivalent d'un joli SELECT *) dans un tableau en PHP
  • Parcours du tableau pour conter le nombre d'éléments du tableau obtenu précédemment et gérer ainsi la pagination
  • Récupération en base des 8 dernières news en vue de leur affichage (ce serait trop bête d'utiliser le tableau obtenu précédemment)
  • Pas d'utilisation du mécanisme de cache fourni par le CMS (eZ Publish) - donc à chaque rechargement de page, on recommence...

Quand il y a une 20aine d'actualités, coté temps d'affichage ça va encore - lorsqu'il y en a >1000, ça le fait tout de suite moins.

Réponse attendue d'un développeur sensible aux bonnes pratiques du web et conscient des problématiques de charges :

  • Utilisation de COUNT (ou plutôt de son équivalent dans le langage du CMS utilisé)
  • Récupération en base des 8 dernières actualités en vue de leur affichage
  • Mise en cache du résultat obtenu

C'est dans ces cas aussi que l'on souhaite une professionnalisation des métiers du web. Certains diront que la qualité se vend mal. C'est sur que si les clients ont déchanté face aux promesses de qualité faites par les SSII/Editeurs, ils vont avoir du mal à acheter une telle qualité annoncée. Le problème tient au fait pour les SSII de prouver à leurs clients que la qualité annoncée sera au rendez-vous et de former le cas échéant ces collaborateurs. Pour le bien de tous (développeur, SSII, client), il est évident que cette professionnalisation se fasse mais faut-il encore le vouloir et le financer... Dans ce cadre, on ne peut pas demander à un collaborateur de se former sur son temps libre ou chez un client...

15 commentaires

mercredi 27 août 2008

Intégration : Recette interne

Par NiCoS le mercredi 27 août 2008, 17:49

La recette arrivant en bout de course d'un projet, elle est souvent sacrifiée pour compenser les retards de développements pour des bonnes et/ou mauvaises raisons. Il arrive donc souvent que la version livrée en recette a peu été testée (voir pas du tout ou pas de façon suffisamment significative).

Cela conduit à différentes choses :

  • Les jours payés par le client ne sont pas utilisés à cet effet,
  • L'effort de recette coté client explose puisqu'il doit assurer la recette en lieu et place du prestataire
  • L'effort de recette coté presta va également exploser coté prestataire et non être réduit comme escompté car il aura (souvent) tendance à :
    • multiplier les livraisons correctives partielles
    • générer de nombreux aller/retour pour cause de non-correction voir régression
    • exploser le cout de livraison (packaging, documentation, etc)
  • Désorganise tant le prestataire que le client du fait de cette charge à absorber dans des plannings qui ne le permettent pas forcément
  • Au final, une tension croissante va pourrir les relations entre le client et le prestataire, sans compter la démotivation croissante de part et d'autres pour faire avancer le projet. Sans compter que cela ternit l'image de marque du prestataire et peut mettre fin à tout travail potentiel entre le prestataire et le client.

Au final, tout le monde est clairement perdant.

Quelques pistes d'amélioration :

  • Mieux estimer les périodes de recette (structurellement sous estimée) et qu'elle fasse partie du budget du projet. A croire qu'annoncer une période de recette est une honte en matière de programmation... Attention, il faut quand même que cette durée reste cohérente avec la taille/complexité de l'application.
  • Etre transparent/honnête avec son client en disant qu'il y aura un retard de livraison le temps de faire la recette. Après tout, c'est logique, le temps perdu au niveau du développement ne se rattrappe jamais par magie...
  • Mieux résister à la pression interne de livrer "à tout prix et/ou au plus vite" au client
  • Prendre le temps de faire cette recette
  • Coté presta, prévoir des zones tampons si des projets doivent se succéder afin qu'un retard sur un projet n'en condamne pas un autre. Cela suppose aussi que le chef de projet remonte les infos à temps à sa hiérarchie.
  • Dans le cas de plusieurs itérations, faire en sorte d'en avoir le moins possible pour ne pas se démotiver dans les phases de recette,
  • S'il y a des applications auxquelles se connecte le projet, soit vous êtes en mesure de mettre en place réellement cette plateforme chez le prestataire, soit il faut venir faire des tests d'intégration chez le client
  • Faire venir le prestataire sur site pour pouvoir travailler de concert et éviter les parties de ping-pong par mail ou téléphone,
  • Se dire que ce retard sera compensé par le fait que tout ce qui a été dit dans le paragraphe précédent ne se produira pas... ou dans une moindre mesure

Enfin, si le jour de la livraison il y a un retard de dernière minute ou une opération plus longue que prévue, prévenir le plus tôt possible le client et le tenir informé des éventuels reports de livraison. Ou alors se donner une vraie marge pour tenir les horaires. Cela évite en outre que le client excédé vous appelle pour savoir où vous en êtes et à quelle heure vous allez livrer.

Tout cela suppose également que le chef de projet ait une visibilité suffisamment bonne sur le travail de ces développeurs et qu'il connaisse suffisamment bien le produit sur lequel il travaille pour que ces estimations soient les plus justes possibles. Faute de quoi, il risque de se trouver dans une fort mauvaise posture (vécu inside).

A ce jour, une telle méthode m'aurait épargné un gros nombre des 100 bugs trouvés juste en cliquant à droite et à gauche (sans prendre en compte les specs fonctionnelles d'un projet) et les 5 livraisons que j'ai réduit à 3 intégrations. Je tairais le nom de la SSII, vu que ce n'est pas propre à cette SSII et que j'espère que d'autres équipes projets de cette SSII travaillent de façon plus satisfaisante. Pour avoir de l'autre coté, j'en garde également des mauvais souvenirs et des conditions de travail déplorables, se retrouvant entre le marteau (le client) et l'enclume (sa hierarchie).

aucun commentaire

jeudi 21 août 2008

Intégration : Cahier de recette (cet ami qui vous veut du bien)

Par NiCoS le jeudi 21 août 2008, 17:45

Je vais lancer une série "Intégration" dans laquelle je vais parler de points vue dans mon quotidien ou dans mon passé en SSII.

Cela faisait un moment que je voulais écrire ce billet, convaincu de plus en plus que le cahier de recette devient un élément de plus en plus crucial dans un projet informatique.

Idéalement, je vois une première version réalisée à l'issue de la phase des spécifications. Sans aller parler de "Test Driven Development" (Développement piloté par les tests, qui l'on peut résumer synthétiquement par le fait d'écrire les tests avant de coder quoi que ce soit), l'idée de rédiger le cahier de tests à l'issue de la phase de spécifications a tout son sens selon moi. Rédiger le cahier de recette (technique et/ou fonctionnel) à cette étape apporte les avantages suivants :

  • Cela permet de consigner par écrit ce qui semble parfois "tellement évident" à certains membres du projet et qui peut ne pas l'être pour d'autres ou bien pas si évident que cela (périmètre de tests, éléments à tester, conditions de tests, etc).
  • On peut s'apercevoir qu'il y a des manques dans les spécifications que l'on peut alors enrichir (règles de gestion, cas non imaginés de premier abord, etc) : imaginons par ex un intranet groupe avec une authentification intégrée, par défaut, on imagine très bien le cas du français se connectant sur l'application depuis son poste france, mais que se passe-t-il s'il se déplace dans une filliale pour laquelle l'authentification intégrée n'est pas en place ? L'utilisateur pourra-t-il se connecter malgré tout à l'application ?).
  • Dans le cas d'une relation avec un prestataire, cela évite les mauvaises surprises en phase de recette (le cas de recette 12, pourtant tellement évident coté client et absolument pas (pré)vu par le prestataire)
  • A l'issue de la phase de développement, vous pouvez demander au prestataire de vous indiquer le résultat de sa recette vis à vis de ce cahier de recette (qui aura pu être complété/détaillé entre temps).
  • Lors de la phase de recette, vous avez un référentiel sur lequel peut s'appuyer votre démarche de recette.

En tout état de cause, il est important de faire vivre votre cahier de recette : de test très macro (état initial > étapes > résultat) réalisés dans un premier temps, vous pourrez le compléter (nouveaux cas) ou bien le détailler/préciser ou encore définir des "sous-cas" de tests.

Il est également important de communiquer ce cahier de recette aux parties impliquées pour avoir leur réaction et échanger. Cela peut le cas échéant donner lieu à des avenants/aménagements des phases de développement (cas d'évolution). Le fait que ce soit dans votre cahier de recette ne veut pas forcément dire qu'il doit être accepté systématiquement par votre équipe de développement / prestataire ; en effet, si cela n'est pas dans le périmètre de départ ou a un impact trop significatif sur les développements, il vous faudra en discuter (c'est sur qu'en cas d'engagement au forfait...)

Pour être honnête, moi même en SSII, j'ai très peu appliqué cette méthode - seulement lors de mes dernières missions en AMOA lorsque j'étais en SSII ou pour un projet interne actuel chez mon actuel employeur. Dernièrement, lors d'un POC (Proof Of Concept / Prototype), j'avoue avoir été étonné que personne ne s'en est pré-occupé avant que j'en fournisse un - permettant d'ailleurs de découvrir le cas du français en déplacement dans une autre filliale par ex. Tout le monde savait qu'il fallait tester deux fonctions "authentification" et "indexation" et il a bien été démontré que cette soit-disant évidence des tests n'allait pas de soit sur de nombreux sujets ou tout bonnement sur le périmètre même du POC.

La seule explication au fait que cela ne soit pas plus utilisé à présent dans les méthodes de développement est un temps de spécification mal estimé conduisant à ce qu'il soit négligé / repoussé à la phase de tests. Vous en voyez d'autres (bonnes|mauvaises) raisons ?

4 commentaires