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

3 réflexions au sujet de « Le processus d’élaboration des Spécifications en méthodes Agiles »

    Choulant Noham a dit:
    17 décembre 2010 à 8 h 48 min

    Bonjour,
    Je partage votre avis, je commence à prendre ces habitudes que vous indiquez, il reste néanmoins un point sur le quel j’ai quelques soucis de gestion:

    Chiffrer le projet dans son ensemble, car bien que le but est de fournir une application à mon client, il me faut tout de même lui donner un chiffrage afin qu’il sache le coût du projet. Je partage la vision de la gestion du changement tout au long du projet, mais je doit m’engager sur des jalons, des livraisons. Si les spéc ne sont pas faites au début du projet :

    Comment gérez vous les jalons, la charge, les délais ?

    Merci

      Gwénaël Bonhommeau a répondu:
      17 décembre 2010 à 12 h 49 min

      Bonjour Noham,

      si ton projet est en mode « date fixe », il faut donc que tu gères ton projet à l’aide de release dont le paramètre est le périmètre.

      Il faut tout d’abord que tu effectues une estimation de ton backlog complet, si ce n’est déjà fait. Ce que l’on appelle La réunion d’estimation.
      Ensuite il faut que tu connaisses la vélocité de l’équipe pour déterminer la capacité de celle-ci pour un sprint. On ne la connait réellement qu’après 2-3 sprints.
      Après c’est mathématique, tu comptes le nombre de sprint dans ta release, puis tu multiplies ce nombre par la capacité.
      Ainsi, tu connais le total de points que l’équipe peut produire dans le temps imparti.

      Bien évidemment, tout ceci n’est basé que sur des estimations, il y a donc une part d’incertitude liée au niveau de spécifications du départ.
      Après ton rôle est de contrôler la complexité des US, si l’estimation du départ est remis en cause (un nouvel élément plus complexe) le PO devra décider de réduire le besoin oubien de retirer autant de point de complexité dans la release.

      Gwenael.

        Noham a dit:
        5 janvier 2011 à 9 h 54 min

        Bonjour,

        Merci pour ce complement d’information.

        Bonne année :)

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s