Scrum & Agilité

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

Scrum: Que pensent les sociétés de cette méthode agile ?

Publié le

Une enquête nous révèle le nom des sociétés qui utilisent Scrum, et surtout nous dévoile leurs retours d’expérience.
Dans les grandes lignes, il en ressort que Scrum est:

  • plutôt pratiqué en Ile de France et Rhône-alpes
  • dans les sociétés de plus de 1000 personnes
  • dans le secteur de l’information et communication
  • adopté pour les raisons suivantes:
    • la capacité à s’adapter au changement,
    • les livraisons plus fréquentes,
    • l’accroissement de la qualité,
  • en cours de généralisation et récemment utilisé
  • souvent couplé avec l’Extrême Programming
  • introduit par une personne externe pour être ensuite être internalisé
  • mis en difficulté si le management n’est pas impliqué
  • pratiqué pour les bénéfices suivants:
    • le respect des délais,
    • la fréquence des livraisons,
    • la motivation des équipes

Un grand bravo au Scrum User Group France et la Scrum Alliance pour ce travail, voir l’enquête entière ici.

Google gère ses projets avec Scrum

Publié le Mis à jour le

Jeff Sutherland (co-créateur de Scrum) présente son retour d’expérience de Scrum chez Google.

Exemple de scrum chez google
Scrum chez google

Cette conférence est une source d’informations très enrichissante. On y apprend évidemment les fondamentaux de cette méthode Agile et les avantages de cette pratique (je ferai également un billet sur mon retour d’expérience -très positif- sur mes projets) . Et également le fonctionnement interne de gestion de projet chez Google.

Voir cette présentation ici.