Les 4 étapes de votre projet sont présentées sur le graphique suivant :
Vélocité Château de sable

Etape 1

Votre projet commence, vous ne connaissez pas votre vélocité (jusque là : tout va bien).

Etape 2

Cela ne va pas assez vite pour vous, votre PO, Manager, DSI ou autre, vous décidez donc d'utiliser (par exemple) la technique 3 (arrêter de coder les classes de test).
Bah oui, votre projet n'est qu'à son début, il n'y a pas grand chose à tester, autant focaliser son énergie sur de la production PURE.
Et là, votre vélocité passe de 40 à 100 en 2 itérations : une petite voix vous souffle à l'oreille :

Tu vois, tu as fait le bon choix, tu as présenté une application pleine de fonctionnalités à ton PO et donc ta vélocité a augmenté.
Ok tu as eu quelques bugs durant la démo, mais c'est l'effet démo, tout le monde connait cela.

Fin de l'itération 5, votre équipe a produit environ 270 points de complexité (20 + 30 + 40 + 80 + 100) sans aucune classe de tests. Il y a bien quelques soirée Pizza de tests d'intégration sur l'application, mais vous ne pouvez pas tout tester à chaque démonstration et encore moins à chaque démo.

Noté qu'inconsciemment vous avez déjà mis en place la "technique 10 : Augmentez les plages horaires" pour faire des tests.


Bonne nouvelle, votre PO part en congés pour quelques semaines, vous allez pouvoir remettre de l'ordre dans le Bouzin !!!

Etape 3 : Le plus dur sera la chute.

Vous perdez 10 points sur l'itération 6 (90 points contre 100 à l'itération 5) et hop vous en reperdez 10 (80 points pour l'itération 7).
Bon alors, à situation exceptionnelle techniques exceptionnelles, qu'est ce que je peux utiliser comme petit artifice pour corriger tout cela :

  • Technique 1 : Surestimez vos Users Stories : Mouais, on surestime déjà un peu
  • Technique 2 : Vous arrêtez le Pair Programming : déjà arrêté (même jamais commencé)
  • Technique 3 : Ne codez pas les classes de test : On devait le remettre en place, mais on a eu d'autres trucs plus chauds...
  • Technique 4 : Utilisez le frigo : avant d'utiliser le frigo, il faudrait peut-être avoir des choses à y mettre !!!
  • Technique 5 : Ajoutez des Users Stories techniques dans les itérations : on en a déjà quelques unes...
  • Technique 6 : Transformer les Bugs en Users Stories : on l'a déjà fait, ça va finir par se voir
  • Technique 7 : Dites à votre PO que vous avez 1 ou 2 développeurs qui sont malades : on est en régie, cela ne marchera pas
  • Technique 8 : Oubliez la notion de "Propriété collective du code" : j'affecte déjà les tâches aux développeurs
  • Technique 9 : Interdisez toutes les cérémonies à vos développeurs : il leur reste leur pose Pipi de 10h et 15h
  • Technique 10 : Augmentez les plages horaires : on est déjà tous crevé, j'ai déjà annulé mes vacances pour ce projet.


Il me reste la technique du sang de poulet.

  • Je verse du sang de poulet sur les Users Stories terminées et si c'est un soir de plein lune, ça peut fonctionner...


Aller, inch'allah, le pire est derrière nous.

Etape 4 : Toute le monde commence à tomber malade

  • Itération 8 : 40 points : la moitié que l'itération précédente,
  • Itération 9 : 30 points : moins pire que la précédente, mais surtout vous faites autant qu'à l'itération 2,
  • Itération 10 et 11 : c'est la fin 20 points et 18 points, plus rien ne marche, vous passez vos journées à corriger des bugs dans l'application qui ressemble à un château de sable après avoir pris une grosse vague.


Conclusion : Vous avez fait au moins 3 erreurs

Erreur 1 : La qualité n'est jamais négociable

Vous ne pouvez pas faire de l'Agilité en livrant une application toutes les 1 à 2 semaines SANS que votre application soit auto-testée.
Vous voyez bien qu'au fil des itérations, votre application grossie, grossie, grossie à un point où il vous faudrait plusieurs armées Mexicaines pour tester l'application AVANT de la livrer à un utilisateur.
Plus vous livrer du code non testé plus vous exposez à des Bugs et donc l'équipe de développement se transforme progressivement en équipe qui écope un bateau percé.
Vous ne produisez donc plus de valeur pour votre Product Owner et vos utilisateurs.

Erreur 2 : Refactoring

La refactorisation (anglicisme venant de refactoring) est une opération de maintenance du code informatique. Elle consiste à retravailler le code source non pas pour ajouter une fonctionnalité supplémentaire au logiciel mais pour améliorer sa lisibilité, simplifier sa maintenance, ou changer sa généricité (on parle aussi de remaniement). (Source Wikipedia).

Oui le REFACTORING pénalise aussi votre productivité mais il vous permet de simplifier votre application et donc de la rentre plus maintenable.

Erreur 3 : Vous avez cru au hasard

Dans le développement logiciel il y a rarement de hasard : vous construisez des fondations solides que vous "bichonnez" ou bien vous reconstruisez votre immeuble au bout du 2ième étage.


J'espère que maintenant vous prendrez soin maintenant de votre vélocité sans essayer de la dominer.