Méthodologie

Introduction à ‘Lean Startup’ par le Lean Startup France

Publié le

Hier soir j’ai assisté à la première du Lean Startup France où Nicolas Marchand nous a présenté les bases du Lean Startup.

L’objectif de cet événement était double, présenter le Lean Startup et surtout former un groupe.
Nicolas Marchand nous a convié dans ses locaux chez V4x pour suivre sa présentation et échanger autour du lean.
La présentation était très claire et le discours bien rodé. Nicolas maitrise son sujet, il baigne dans le lean depuis quelques années.

L’assemblée était surtout composée de personnes venants le l’IT, avec des connaissances hétérogènes sur le Lean Startup, mais tous semblaient maitriser le monde de l’Agilité (Scrum, Lean, XP…).
Les échanges ont donc été bon train. Avec un tour de table en fin de la soirée (oui, on ne fait pas dans le classique!) très enrichissant. Je regrette de n’avoir pas pu poursuivre ces discussions dehors… une prochaine fois.

Pour ma part, le contrat de la soirée est rempli. Je mets un ROTI de 5.
Plusieurs sujets ont émergé et pourront faire l’objet d’une présentation plus approfondie (comme des REX, et plus particulièrement sur des retours FAIL), mais comme l’indique Nicolas il faut itérer sur les introductions pour diffuser et consolider un groupe. 

Je tiens à remercier Nicolas pour cette initiative et j’espère que cette première rencontre va faire des petits… à suivre.

Conférence au FrenchSUG sur le retour d’expérience Agile chez GENERALI

Publié le Mis à jour le

J’ai présenté une conférence le 5 Octobre au French Scrum User Group, sur l’application de Scrum lors d’un projet réalisé pour GENERALI.

Ci dessous mes notes sur la présentation.
Adoption Scrum chez GENERALI

La dernière étape d’un projet Agile : La fête !

Publié le

Voici le genre de petit message qui vous fait aimer votre métier et surtout les méthodes Agiles :)

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


Generali change d’Intranet
Au cours de la première quinzaine du mois de juin, vous allez découvrir votre nouvel Intranet. Baptisé Leo, ce nouvel outil remplacera le site Espace Generali.Pratique et simple d’utilisation grâce à une ergonomie fluide et un accès intuitif à l’information, Leo propose :

Des contenus plus complets et plus opérationnels pour comprendre Generali, ses métiers, son évolution et sa stratégie,

Un fil d’actualités donnant un nombre plus important d’informations,

Des nouvelles fonctionnalités comme la possibilité de laisser des commentaires ou de personnaliser sa page d’accueil.

Et bien sûr, les incontournables de l’Intranet actuel : l’annuaire, le Google interne…

Autre nouveauté, les contenus de Leo sont produits et mis en ligne par une centaine de collaborateurs-experts, également impliqués dans la production d’actualités à caractère transverse émanant de leurs propres directions, pour une information plus large, mieux actualisée et plus pédagogique.

Comment élaborer une stratégie de tests

Publié le Mis à jour le

Pour bâtir une stratégie de tests, il faut avant toute chose, être le plus pragmatique possible. Votre stratégie doit s’articuler autour d’une vision:

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.

Le Manifeste Agile est mon guide

Publié le

Le manifeste Agile à 10 Ans ce mois-ci !
Et ma première réflexion en apprenant cette annonce, a été :

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 :)

Le processus d’élaboration des Spécifications en méthodes Agiles

Publié le Mis à jour le

Il est faux de penser qu’il n’existe pas de cahier de spécifications en méthode agile.
En réalité c’est son processus de création qui est différent.

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…).

Plan d’action: les 4 étapes clés

Publié le

Un plan d’action se construit en suivant quatre étapes clés défini dans ce schéma:

 

Plan d'action
Les 4 étapes pour bâtir un plan d'action