Qu'est-ce qu'un manque fonctionnel

C'est une fonctionnalité qui semble prévue dans l'application mais qui n'est pas codée, par exemple :

  • un bouton où il ne se passe rien lorsque l'on clique dessus,
  • un formulaire qui semble fonctionner mais qui ne fait pas les traitements backoffice attendus,
  • des données statiques affichées dans un bloc de l'application, car le webservice utilise toujours des données des tests (un mock),
  • etc...

Tous ces trous sont créés à cause d'un mauvais état d'esprit lors des livraisons d'itération.
Evitez l'effet gruyère dans vos projets Agiles

Les 5 états d'esprit d'une livraison d'une itération

Voici les 5 niveaux que j'ai constaté sur différents projets :

Niveau 1 : Livraison pour les développeurs (ou Scrummaster)

Le plus bas des niveaux, l'équipe de développement livre l'application à chaque fin d'itération mais personne n'utilise cette application.
On voit bien les trous se créer, en fait non, personne ne les voit, car il n'y a aucun feedback sur le produit.
Néanmoins, savoir livrer est une qualité importante, donc n'arrêtez pas.

Niveau 2 : Livraison pour un chef de service

C'est un peu mieux que le niveau 1, mais là le chef de service utilise l'application.
Si l'intérêt n'est pas le contrôle mais le feedback, utiliser le temps de votre chef de service, mais ça ne suffit pas.

Niveau 3 : Livraison au Product Owner

Et oui c'est bien, mais pas suffisant :)
Regarder le niveau 4 et 5.

Niveau 4 : Livraison à des utilisateurs sélectionnés

Ce niveau permet d'être certain que votre application est opérationnelle, que vous n'avez pas oublié de fonctionnalités.
Néanmoins, vous acceptez quelques petites imperfections ou finitions que vous présenterez à vos chers utilisateurs.

Niveau 5 : Livraison en production

Le niveau ultime.
Votre application part en production à chaque fin d'itération : Tout ce que vous livrez est nickel.


Disclaimer, je ne parle que de l'état d'esprit de vos livraisons, il est bien sur très difficile de livrer son application en production à chaque fin d'itération (difficile mais pas impossible...).

Et qu'est-ce que cela change ?

Pourquoi livrer en pensant que l'on va mettre en production à la fin de l'itération (ou 3 itérations) peut changer la qualité de votre logiciel, voici les 4 raisons qui me viennent à l'esprit :

Vous ne partez pas dans tous les sens

Vous suivez votre StoryMaps et vous focalisez sur une, deux ou trois Minimally Marketable Feature (MMF) en fonction de la taille de votre équipe et par conséquent tout le monde est focalisé sur ces MMF; vous ne traînez pas un stock de Users Stories inutilement (Cf : http://www.bouzin-agile.fr/?post/2010/04/11/Les-7-Muda-appliqu%C3%A9s-au-d%C3%A9veloppement-logiciel))

L'équipe de développement a une bonne vision de ce qu'il faut développer

Dans le cas où vos Users Stories sont sur une dizaine de MMF, les développeurs sont en mouvement permanent, ils doivent se souvenir du contexte de la MMF concernée, ils font des choix d'architecture en fonction des US qui arrivent, vous pouvez vous retrouver avec un coût important de refactoring (refactoring complètement justifié).

Vous savez où vous êtes

L'une des questions les plus fréquentes sur les projets est : "Quand c'est qu'on arrive ?"
Mais enfin, sur un projet Agile on ne négocie pas la date, on négocie le périmètre, la question devient donc :
"Ok pour la date, mais il y aura quelles fonctionnalités dans notre application ? "
On se rend compte des fameux trous du gruyère quand on prépare une présentation à un utilisateur ou que l'on refait un tour complet de l'application (sic) et bien sur cette nouvelle fonctionnalités ne sont pas négociables pour la livraison donc vous avez un problème : livrer une application presque utilisable ou respecter la date !!!

Vous gagnez du temps

Chaque fonctionnalité oublié peut être vu comme de la dette et la dette peut vous coûter cher. Plus vous attendez pour payer votre dette, plus celle-ci est chère.
Prenons un exemple simple d'une page avec des simples fautes d'orthographes :

  • Si vous la remontez durant la validation de la User Story, la faute (d'orthographe) peut être corrigé en moins de 5 minutes,
  • Si vous la remontez à la fin du Sprint, elle peut vous coûter le double,
  • etc...

Et cela uniquement pour une simple faute d'orthographe....

Pourquoi cela n'est pas fait

Dans les différents projets où j'ai constaté cette dérive, j'ai noté 3 raisons :

  • Nous ne savions pas : Ok mais maintenant tu sais :-),
  • C'est plus compliqué : Oui, je veux bien admettre que cette rigueur est contraignante mais ce n'est pas parce que l'on fait de l'Agile que l'on peut faire n'importe quoi,
  • Des évènements extérieurs perturbent nos planifications (non réception du Design, de Webservices, de règles de gestion,...) : Ok, mais il y a bien des actions mises en place suite à ces perturbations, car maintenant vous voyez bien que ces retards vont finir par vous impacter.


Conclusion

Communiquez vos plans de Release et sur le contenu des itérations de la release en cours.
Ecrivez, Développez et Validez vos Users Stories comme si elles allaient être mises en production, c'est aussi simple que cela.