Bonjour,

Offrir un nouvel Intranet à tous les collaborateurs du groupe est un événement interne fort.

Sans vous, la naissance de Leo (demain !) n’aurait pas été possible. Nous souhaitons donc fêter cet événement avec vous et en présence de Marie-Louise Antoni, membre du Comité de direction générale.

Nous espérons avoir le plaisir de vous voir très bientôt !

Marie-Christine Lanne
Directrice de la communication

Efficace, pertinente et efficiente.

rédiger une stratégie de tests

Une stratégie de tests se décompose en trois axes:

Évaluation; le contexte du projet détermine l’orientation stratégique de vos tests (on ne teste pas avec les mêmes objectifs et priorités, une application e-commerce ou un site institutionnel), il est donc primordiale d’amasser certaines informations du projet. Cette étape débute donc par l’analyse des informations significatives du projet. Cette étude doit contrôler la faisabilité d’une transformation des exigences en test, à partir de la qualité des informations à disposition (anticiper sur les futurs livrables).

Une partie importante de cette analyse consiste à identifier et évaluer les risques. L’autre sujet de cette phase consiste à évaluer l’effort de test nécessaire à la validation du livrable.
Pilotage; la communication est le pivot d’une stratégie de tests. L’élaboration d’une matrice RACI permet de contrôler cette communication en établissant des règles.

Piloter une stratégie de tests consiste à orienter les efforts de test, sur les bons composants et fonctionnalités, au moment opportun. Pour gagner en efficacité, réaliser un pilotage des tests par les risques (RBT – Risk-Based Testing, qui constate qu’une couverture à 100% des exigences fonctionnelles et non-fonctionnelles relève de la théorie, et recommande de mieux cibler ses efforts). Ces objectifs de tests régentent le plan de tests.

La conduite de tests réclame un suivi efficace, qu’il faut établir à partir d’indicateurs pertinents. La communication autour de ces rapports doit se mettre à niveau en fonction des interlocuteurs. Cette activité de contrôle doit être opérationnelle tout au long de votre campagne de tests.

Gestion; les facteurs contraintes/budgets/Délais déterminent la consistance de la stratégie de tests. Il est fondamentale de lister les contraintes, et de les suivre dans un planning. Les ressources techniques et humaines sont jaugées en fonction du budget. La composante « délais » fixe le planning, qui doit être adapté en continue en fonction des contraintes et du pilotage.

La typologie des tests est variée et caractérisée dans une phase du projet.

DEPLOIEMENT et INTEGRATION CONTINUE

• Lancement des tests d’assurance qualité (SONAR)
• Assemblage  des composants (MAVEN)
•  Lancement des tests de non régression (TELLURIUM)
• Génération de Release Notes (intégration JIRA)
• Tests d’acceptation (FitNess)
• Tests Fonctionnel (SELENIUM)

PILOTAGE

• Référentiel des projets et des demandes associées (JIRA)
  (Description – Estimation de l’effort – Due Date – etc.) inscrites dans des Road Map de version d’application

RECETTE (TEST & QA)

• Référentiel des Tests Cases, Campagne de tests (TESTLINK)
• Enregistrement des résultats des tests (TESTLINK)
• Suivi par campagne de tests et test case des avancements de correction de bug ( (TESTLINK interfaçage MANTIS et JIRA)
• Reporting (Chart – HTML – EXCEL)
• Référentiel et gestionnaire des Bugs (JIRA/MANTIS)

PRODUCTION

• Tests de performance (JMETER/The Grinder)
• Tests de charges (JMETER/Sonde)
• Tests de sécurité
• Tests d’exploitabilité

Une stratégie des tests peut être incluse dans une TRA (Tierce Recette Applicative). Son rôle est d’accompagner le pilotage de la qualité globale du projet et de certifier à tout moment la conformité d’une livraison.

Pourquoi ais-je mis 10 ans pour réussir à le mettre en place ? :)

J’en profite pour vous donner le lien vers la version française Manifeste pour le développement Agile de logiciels (autre version par Jean Claude GROSJEAN).
Pour fêter ces 10 ans, j’ai imprimé les 12 principes et je les ai affiché dans mon scrumBoard :)

Tout d’abord, comme vous le savez déjà, en mode Agile il n’existe pas de phase « lourde » et « laborieuse » de spécification en début de projet (et uniquement en début ! Oui Mr. le Client vous devez penser à tout avant même de commencer, après il sera trop tard…).
Au contraire, les spécifications sont élaborées tout au long du projet, juste avant d’être développées (Just-in-time). Oui mais voilà, être en flux tendu n’a pas que des avantages et surtout impose davantage de rigueur.

Voici les avantages et pièges à éviter:

• Le gain le plus significatif sur la rédaction par itération, est le cumul de l’historique sur le projet au moment de la rédaction.
  En d’autres termes, lorsque vous rédigez une spécification en milieu de projet, vous le faite en intégrant les informations recueillies tout au long du projet. De fait, elles sont plus juste et prennent en compte les contraintes connues du projet (c’est encore plus vrai sur un projet basé sur un progiciel).
• Un second avantage indéniable est la « fraicheur » des spécifications.
  J’entends par là, que les spécifications étant saisies Just-in-time, elles sont de fait toujours fraiches dans la tête de l’équipe. On gagne donc en efficacité !
• Le fait de rédiger les spécifications de manière unitaire, pour chaque User Story, permet un meilleur focus et donc une meilleure attention sur le besoin.
• Pour une meilleure traçabilité, je vous suggère de nommer chaque document de spécification par l‘identifiant de la User Story.
• La première précaution à prendre avec ce flux tendu, est de prévoir un cycle d’initialisation des spécifications en avance de phase par rapport aux Sprints de développement.
  Il y a plusieurs raisons à cela, la plus pertinente est d’avoir ce document au moment du découpage en tâches des US, permettant ainsi une meilleure estimation de la charge du Sprint.
• Une fois le document initialisé par le Client (PO/MOA), je préconise de mettre en place une séance de relecture avec toute l’équipe. Le but étant de confirmer la faisabilité, de proposer des alternatives et de vérifier le périmètre de l’US (il n’est pas rare de s’apercevoir à ce moment-là qu’il manque des US).
• Après chaque modification, cette séance de relecture doit être systématiquement mis en place, pour les mêmes raisons, plus surveiller que la complexité n’augmente pas drastiquement.
• Une autre raison pour laquelle je mets en place cet échange, est le fait qu’un développeur fait involontairement une lecture technique du document. Et de fait,  passe à côté de points importants pour le client. Il est donc important de rappeler les points à prendre en considération pendant cet atelier (par exemple, le wording, le zoning…).
  

By jeanclaude35

Savoir dire « non »

Tout l’art de cet échange consiste à rester ferme et honnête envers son client. Ce qui je vous l’avoue demande courage et ténacité :)
Il est évident qu’un « non » brut pour point, peut être mal perçu et je vous le déconseille vivement ! Il faut toujours arrondir les angles, être diplomate,  et surtout argumenter. Il est également primordial de parachever votre discussion par une ouverture, veuillez donc à toujours proposer une solution alternative.

Plusieurs cas de figures peuvent provoquer un refus: une demande au delà des limites du périmètre, des jalons imposés et intenables ou encore client mal préparé… Et plus délicat, une expression du besoin insuffisante ou difficile à obtenir. Dans cette dernière situation, il est impératif d’informer le client qu’il faut stopper le projet, que vous refusez de continuer. J’ai personnellement rencontré cette problématique sur un gros projet, et nous avons pris la décision de ne pas lui dire non… je m’en mords encore les doigts !

Un « non » est positif

Sachez qu’un refus renforce votre légitimité et votre crédibilité. En effet, un non c’est aussi ne pas promettre au delà du possible. Ce qui conduirait vers  une situation délicate, voir encore plus conflictuelle. C’est montrer que vous maitrisez votre projet et que vous envisagez les conséquences. Savoir dire non, c’est aussi donner plus de point au oui, c’est une preuve d’engagement.
C’est aussi rétablir le rapport de force avec le client: le client est roi, oui mais Non :)

Si vous ne savez pas dire non, je vous conseille la lecture de ce billet Dire “NON” : comment ? Voici comment apprendre à dire NON.

Il est donc important d’adopter une attitude ouverte, compréhensive envers les obligations mutuelles, tournée vers une solution acceptable pour les deux parties.

Gestion des risques projet: schéma global

Le schéma est visible sur le site de mindmap en ligne mindmeister.

Et là, je vous dit Attention aux fausses idées !

Déjà, ne vous croyez pas intouchable avec ce document. Bien souvent, le prestataire se cache derrière ces spécifications. Il a tendance à braquer ce document tel un arbitre de foot avec son carton rouge: c’est écrit dans les spécifications vous l’avez signé, l’affaire est clos…

Il n’est pas rare d’avoir un client qui signe ce document sous la contrainte, ou pire pour cacher son incompétence. Ce dernier point n’est pas péjoratif, il est important de vérifier si votre interlocuteur possède les qualifications requises pour réaliser cette tâche.

Je préconise la mise en place, systématique, d’un atelier de relecture des spécifications avec le client.

Il ne faut pas se voiler la face, il est rare de clôturer un projet informatique dans les temps. Il y a plusieurs causes à cela:

• Un planning initialement intenable, mais obligatoire pour remporter l’affaire (merci l’avant vente! )
• Une date de mise en production inébranlable
• Une équipe projet mal taillée (qualitativement ou quantitativement)
• Un problème de ressource inopiné (ressource sur plusieurs projets, absence…)
• Une mauvaise estimation de la charge
• Une gestion des risques inefficace
• …

Une solution possible, pour répondre aux deux ou trois premiers points, est d’allotir le projet.
L’allotissement est un outil très efficace s’il est bien maîtrisé.

Pour réussir cette pratique, il faut:

• Que le client accepte (même si l’équipe projet approuve, il n’est pas toujours facile de vendre cette idée en interne, il faut accompagner le client)
• Que le client concède de redéfinir le périmètre et reporter les fonctionnalités secondaires
• Que les fonctionnalités indispensables soient présentes dans le premier lot
• Et que les conséquences ci-dessous soit maitrisées et approuvées

Évidemment, cette gestion comporte également des contraintes, comme:

• L’allongement de la durée du projet
• La répétition des phases (spécification/Développement/Recette/Installation)
• Le maintien des équipes en place
• La surcharge sur le budget (notamment dû à la répétition des phases et à une gestion de projet plus complexe)

Je précise, ce billet ne parle pas de l’allotissement dans le cadre d’une consultation d’un marché public, qui compte d’autres spécificités non décrite ici.