Cycle en V

J’ai lu plusieurs articles récemment qui tendent à indiquer que le Cycle en V n’est pas applicable voir que c’est une aberration pédagogique. Pour ma part, je n’ai pas l’expertise suffisante pour dire s’il y a un aspect non pédagogique à l’apprentissage du cycle en V, mais je ne dirais pas que le Cycle en V n’est pas applicable.

J’ai eu l’occasion de pratiquer le Cycle en V à de nombreuses occasions et bien que je sois convaincu de la meilleure efficacité des méthodes agiles, lorsque je parle des mes expériences personnelles, celle que je trouve la plus réussie a été réalisée en Cycle en V … comprend qui peut !

J’étais le chef d’un projet qui consistait a réaliser un système d’arrêt d’urgence d’une centrale nucléaire de Lituanie. Je vous rassure tout de suite, le système est encore en parfait état de marche. Les logiciels de sureté nucléaire doivent être conformes à la norme CEI 60880 et se doivent de suivre un cycle en V très strict, pour vous donner une idée, même les documents de revue de document ont un cycle de vie. Ce projet a impliqué 20 personnes en pic de charge sur une durée de 18 mois, et nous avons commencé par les spécifications, puis la conception, puis le codage, les tests unitaires, l’intégration et enfin la validation. A l’arrivée, nous avons livré avec 3 jours de retard sur le plan initial (pas si mal au bout de 18 mois), pour une charge inférieure de 10% aux estimations et surtout, et c’est ma plus grande satisfaction, sans avoir à aucun moment demandé à l’équipe de travailler tard le soir ou le week-end.

Je pense qu’une grande partie du succès de ce projet est dû à mon approche agile/lean de la situation dont je retiendrais les points principaux suivants:

  • Planning/Gant précis à 3 semaines mais non détaillé au delà (le responsable logiciel n’a jamais vraiment voulu accepter que mon planning dépasse constamment les 18 mois – 29 mois au début – mais je me refusais à consommer du temps sur quelque chose qui allait forcément changer)
  • Point de synchro hebdomadaire d’une heure maximum le lundi à 9h (peu de perte de temps, adhésion des équipes) durant lequel chacun s’exprimait 3 minutes pour dire sur quoi il allait travailler durant la semaine
  • Plus 3 questions hebdo: Qu’avez-vous fait par rapport à ce qui était prévu? Pourquoi n’avez vous pas pu faire ce qui était prévu (bloqueurs)? Qu’avez-vous fait en plus que ce qui était prévu?
  • J’ai toujours demandé aux membres de l’équipe « combien de temps pour finir ta tâche » et ensuite je remettais le planning à jour. Je n’ai jamais dit « je te rappelle qu’il ne te reste que X jours pour finir ».
  • Affectation des tâches 1 par 1 à chaque membre, jamais de multi-tâches. Chaque membre de l’équipe connaissait la tâche qu’il devait commencer à la suite de celle en cours.
  • Planification d’une occupation maximale à 80% dans les plannings (les mercredi et vendredi après-midi étaient toujours chômés … du moins sur le Gant)
  • Souci constant d’anticipation de la synchronisation des échanges entre équipes (afin de réduire ce que je n’appelais pas encore ‘Waste’ ou ‘Muda’ – Cf. Lean Software Development) et des risques
  • Confiance de mise sur les travaux de l’équipe
  • Travail en équipe pour réduire la complexité des documents tout en respectant le format type et en obtenant la validation des autorités de sureté (parfois un peu équilibriste).
  • Proximité avec les équipes, je passais la plus grande partie de mon temps à me « promener » pour aller voir ce que faisais mon équipe, pas pour contrôler, mais pour comprendre ce qu’ils faisaient et comment ils le faisaient.

Je ne conclurais pas que le Cycle en V est une bonne méthode, mais simplement que la méthode n’empêche pas d’être intelligent.  L’être humain se doit de prendre le dessus et de rechercher en permanence des leviers d’amélioration et prendre des risques pour être plus efficace. Cela peut s’avérer payant, comme dans mon cas sur ce projet, ou parfois être source de conflit avec sa hiérarchie, mais le jeu en vaut la chandelle car le succès est plus souvent au rendez-vous.

A défaut de pouvoir être « pur agile », ce qui permet d’atteindre l’efficacité maximale, je dirais simplement à ceux qui sont dans l’obligation de suivre un cycle en V qu’il y a toujours des marges de manoeuvre pour être plus agile … il suffit de vouloir les trouver !

3 réflexions sur « Cycle en V »

  1. Salut Alex,

    Ayant fait parti de cette équipe, du début à la fin (et même un peu après), je dois avouer que c’est l’expérience la plus réussie de ma vie professionnelle. Je n’avais pas à l’époque fait l’analyse de la réussite par rapport à la méthode, en dehors du fait qu’on était entourés de très bon managers. La découverte des méthodes agiles me fais comprendre quels étaient les atouts et les facteurs de réussite.

    Aujourd’hui chez Alstom, j’ai beaucoup de mal avec le cycle en V très rigide et les plannings très détaillés. On va vers de plus en plus de rigidité sous prétexte de qualité et on s’étonne que ça ne marche pas.

  2. Heureux de lire que toi aussi tu partages ce bilan, seb 🙂
    Pour ce que tu décris actuellement, je dirais que c’est du Taylorisme en opposition au Lean. Taylor a écrit sur le « management scientifique » car il était convaincu que le management était une science, c’est à dire que faire plusieurs fois la même action produisait toujours le même résultat, et donc que le comportement humain n’influait pas sur le résultat, grave erreur ! Comme cette logique prévaut dans beaucoup de sociétés, on obtient des processus de plus en plus détaillés qui veulent retirer le facteur humain sous prétexte de garantir la répétabilité des opérations, et comme tu le dis, moins ça marche et plus on rajoute des contraintes.

  3. Bonjour,
    J’abonde également dans votre sens. Félicitations pour la réussite en particulier bravo d’insister sur l’aspect humain (ils n’ont pas fait d’heures sup !).
    Le managment est une discipline des sciences sociales évidemment très mal connue du monde du Génie Logiciel.
    Selon mon expérience (c’est souvent repris dans les bouquins de management) : Une équipe motivée sans aucune méthode peu réussir mais une équipe démotivée court à l’échec quelque soit la méthode utilisée…
    Cordialement,
    Gérard.
    PS : Je cherche à faire le point sur ces méthodes et à prendre le meilleur de chaque et je sais ce qui a de bon dans le Cycle en V.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *