Bonjour à tous,
aujourd’hui, je vais partager avec vous la transition vers l’agilité d’un éditeur logiciel, transition à laquelle j’ai pu prendre part directement.
Il y a encore 4 mois, cet éditeur travaillait en mode « prédictif » avec des spécifications fonctionnelles et techniques détaillées. Des pavés de 30 à 60 pages qui décrivaient avec une précision chirurgicale le besoin des utilisateurs. Suite à cela était fait un chiffrage. Evidemment, avec un tel niveau de détail, une précision de l’ordre de la milliseconde pour la date de livraison du projet était facilement atteignable (et était le minimum qu’on pouvait en attendre!).
Flashback, 4 months ago:
Nous sommes en plein milieu de la roadmap. Depuis le début, les projets dérivent régulièrement sur des semaines, car miséricorde, les besoins des utilisateurs mutent (c’est horrible, ils mutent!) au cours des projets! Pour les professionnels de l’informatique en mode Catherine Laborde, rien d’étonnant bien entendu. Cependant, les projets ne font pas qu’éclater leurs plannings, ils sont aussi livrés avec de sérieux défauts de qualité, car ayant perdu du temps, on essaie par tous les moyens d’en gagner. Un levier conséquent pour réduire les délais, c’est la qualité.
Finalement, les efforts pour satisfaire les clients seront tels qu’on constate avec la lèvre inférieure par-dessus la supérieure qu’on doit faire mieux! On peut faire mieux!
Back to now:
Pour réussir le tour de force de livrer dans les temps des projets de qualité, il est plus que temps de modifier les processus!
Mission acceptée.
Mode « Guépard on ». Pour toujours mieux satisfaire ses clients, cet éditeur logiciel décide de modifier radicalement sa manière d’appréhender les projets.
L’approche (pas la méthodologie!!!) agile est alors appelée à la rescousse. Increment, Iteration, User Stories, Story point, Pair Programming, TDD, Continuous Integration… et j’en passe des dizaines, tout est mis en oeuvre quasiment simultanément pour atteindre l’excellence dans le développement logiciel. Célérité rimant peu avec précision (heureusement que je n’écris pas en anglais), on peut alors, sans être Nostradamus, s’attendre à un effondrement en masse de toutes les parties de l’entreprise. En effet, les échecs de transition agile sont nombreux dans le monde de l’entreprise, et bien souvent, mais ça n’engage que moi, cela est dû au fait, que seule l’équipe de développement fait la transition. Il y a alors création de frottements importants avec les équipes projets ou commerciales, selon les organisations, et tout se termine par un échec magistral de projets non livrés et de clients disparus. Ayant cela en tête (ou pas), notre éditeur expérimental fait le choix judicieux d’entamer une mutation agile dans l’ensemble de ses équipes. Une remarque importante que l’on peut se faire en observant cet « editosphère », car cela a peut être contribué à la réussite, est qu’il y a en fait un ou plusieurs leaders actifs prônant l’agilité dans chacune des équipes. Ce n’est parfois pas suffisant mais pour le cas qui nous intéresse, cela a réussi à créer l’inertie suffisante pour entraîner toute la société derrière eux. Toujours est-il que cela fait 4 mois que cet éditeur réussit tous ses projets de développement: respect des dates de livraison, qualité logicielle quasiment irréprochable… et continue sa quête de la perfection en solidifiant ses processus agile pour les prochains mois à venir.
Mission réussie.
Talentsoft Developers 