spécifications fonctionnelles

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…).
Publicités

Spécifications fonctionnelles: La validation

Publié le

Après une plus ou moins longue phase de spécifications fonctionnelles, vous avez pondu seul (comprendre sans le client) une doc de spécifications fonctionnelles et vous n’avez qu’un seul but: Que le client le signe!

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.

Gestion de projet – étape #2: Les spécifications fonctionnelles

Publié le Mis à jour le

La phase de spécification permet de décrire le besoin fonctionnel (également technique) dans le but d’élaborer un projet.

C’est le temps fort du projet vis à vis du client, le moment où vous devez démontrer vos talents d’homme communiquant. A ce stade du projet, il est impératif que vous ayez une parfaite connaissance du projet – vous avez lu et relu le CCTP -, et vous avez déjà quelques idées de réponse à apporter, voir pourquoi pas,  des pistes d’amélioration.

Il faut absolument déjouer les pièges, tout de suite !
Après il sera trop tard pour revenir en arrière et le client acceptera moins facilement ce changement. Non pas qu’il faille répondre « NON » à toutes les demandes, qu’elles soient implicite ou non au cahier des charges – Là n’est pas la question -. Mais plutôt d’atteindre le même résultat par un chemin plus simple ou bien de démontrer que la fonction demandée n’est pas réellement utile.

«  Souvenez vous, les solutions les plus simple sont toujours les meilleurs « .

Votre rôle sera surtout de vous assurez que ce qui a été vendu (voir sous-vendu) est finalement réalisable. Pour éviter les risques et les surprises, je conseil au chef de projet d’être présent dans le projet dès la phase d’avant vente.

Gardez en mémoire que seulement 45% des fonctionnalités demandées sont réellement utilisées.

Afin d’éviter tout malentendu sur ces fameuses fonctionnalités, je vous conseille de les illustrer au maximum par des schémas. Pour expliquer une solution attendue, une copie d’écran ou un croquis vaut tous les longs discours. Et si vous en avez la possibilité, appuyez votre discours par une démonstration.