méthodes agiles

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.

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