Comme chaque année, décembre lance la période des vœux et des listes de cadeaux ... alors voici la mienne :

J'y mets les formes, c'est important !

"Cher père Noël, pour Noël je souhaite que mes développements respectent les contraintes suivantes :

• Qu'ils répondent à ce qu'attend mon client (cela suppose que j'ai bien compris ce qu'il veut) ;
• Qu'ils aient subi une large couverture de tests fonctionnels et techniques ;
• Qu'ils soient réalisés dans le respect des délais et des charges prévus ;
• Que leur facilité de maintenance démontre mon excellence technique."

Ma fille de 8 ans arrivant, elle me stoppe net : "Papa le père Noël n'existe plus (pas ??) depuis que j'ai 6 ans" (ouf le petit dernier n'a rien entendu !!)

J'encaisse le choc, reviens peu à peu à moi, prends une douche et me rase (important pour la suite) : là, seul face au miroir (je vous avais prévenu), je me dis que ce résultat doit quand même être accessible, père Noël ou pas !

Alors j'en appelle à vos nombreux commentaires pour répondre à cette question simple mais importante : "Quelles actions dois-je mettre en place sur mes projets pour démontrer à ma fille que le père Noël existe ??"

Pour ma part voici mes premières réponses issues de mes succès ... et aussi de mes erreurs !

1. Pilotage / Suivi

• J'associe mon client au respect des engagements calendaires avec un suivi régulier tous les 15 jours et un accès permanent à mon tableau de pilotage (à détailler dans un prochain billet) : le PAQ rappelle les engagements des acteurs en terme de date de livraison mais aussi de délai de validation des travaux ;
• Je mets en place dans la première semaine du projet, les accès client et équipe à la plateforme documentaire (ALFRESCO) et à l'outil de suivi de recette (JIRA) ;
• Je valide la création de l'affaire et l'affectation des membres de l'équipe dans l'outil interne des comptes rendus d'activité (CRA) au lancement du projet ;
• J'envoie un ordre du jour au moins 3 jours avant chaque réunion ;
• J'envoie aussi un compte rendu au plus tard 3 jours après chaque réunion ;
• Je demande au client de me fournir les documents applicables (à inscrire dans le PAQ) dont les tests techniques auxquels l'application sera soumise ;
• Je réponds dans la journée à chacun des mails du client, au minimum pour l'avertir que je creuse la question ;
• Je fais un point d'avancement quotidien avec mon équipe ;
• Je remonte à mon manager direct (chef de projet ou directeur de pôle) tout risque de dérapage identifié.

2. Conception

• J'implique les utilisateurs finaux du futur produit dans les travaux de conception en mettant en place par exemple des ateliers fonctionnels ;
• Si je mets en place des ateliers fonctionnels, je m'appuie systématiquement sur une maquette réalisée avec le support de notre équipe infographie et accessibilité ;
• Je respecte les outils retenus par le cadre normatif de mon client quand il existe, sinon je mutualise les succès en proposant les outils qui ont démontré leur efficacité sur nos autres projets ;
• Je couvre les aspects organisationnels, fonctionnels, ergonomiques (dont l'accessibilité), techniques et sécuritaires ;
• Je demande au client d'organiser une rencontre avec ses équipes d'exploitation et de validation technique de la future solution (quand elles existent) ;
• J'identifie toutes les contraintes du projet et les fais valider par le client ;
• J'adopte le langage UML.

3. Développement

• Je demande à mon concepteur fonctionnel ou à mon chef de projet si un point de la spéc n'est pas claire
• Je m'appuie sur la plateforme d'intégration continue (Maven, Hudson, Sonar) ;
• Je m'appuie sur les plugins mis en place dans mon IDE pour identifier mes écarts par rapport à l'état de l'art ASAP (JDepend, Checkstyle, PMD, EclEmma, ...) ;
• Je couvre mes classes métiers et mes classes complexes de tests unitaires (JUnit, DBUnit, ...) ;
• Je fais participer au maximum les développeurs dans la définition des charges. Afin que l'engagement de l'équipe soit respecté et que ce soit l'équipe qui s'engage et pas forcément que le chef de projet ;
• J'essaie de mettre en place des ateliers techniques pour que les développeurs puissent s'entraîner sur certaines tâches ;
• Je n'hésite pas à renseigner Trac ou tout autre outils qui permettent de faire partager le savoir sur un point technique du projet ou sur la bonne pratique à avoir pour pouvoir implémenter tel ou tel code ;
• Je n'hésite pas à demander à mes collègues leur opinion ;
• Je croise certains développements et/ou tests afin de s'assurer que les bonnes pratiques sont effectivement utilisées et que l'implémentation des fonctionnalités de l'application soit compréhensible et maintenable par tous. Ne pas hésiter à remonter d'éventuels points trop complexes ou difficilement compréhensibles et proposer un refactoring ;
• Lors de l'arrivé d'un nouveau développeur au sein de l'équipe, ne pas hésiter à faire, dans des proportions raisonnables, du pair programming afin qu'il puisse devenir opérationnel plus rapidemment.

4. Tests internes

• J'automatise mes tests fonctionnels à partir d'outils type SELENIUM ;
• Je valide tous les tests techniques (identifiés lors de l'étape 1) avant de livrer au client.

5. Livraison

• Je package la livraison (application et documentation) en fonction des attentes du client ;
• Je préviens le client au moins 15 jours avant la livraison et lui rappelle 3 jours avant par mail.

6. Support aux tests du client

• J'accuse systématiquement dans la journée la prise en compte de sa demande et le préviens de la date de mise en place du traitement dès que je la connais.

Voilà donc mes premiers éléments de réponse, assez généraux, largement incomplets mais j'attends maintenant vos compléments ... alors à vos claviers !!