Discussion :

[pmithrandir]

Euh ce n'est pas forcément le développeur qui merde hein... On peut aussi interpréter ça comme étant un moyen de s'assurer et que le client voulait aller à A et non à un B qui serait à 1000 bornes du A ! Sachant qu'en plus si le client sait qu'il veut aller à A (ce qui est déjà un petit miracle en soit) il y ait des chances qu'il ait dit A' voir C...

j ai jamais dit que c'était la faut du dev.

Juste qu'il n'était pas la ou il devait être au bout du compte.
En général, c'est 50% de la faute du client, 30% du chef de projet / gestionnaire des taches et 20% du dev.

Le soucis étant que dans beaucoup d’entreprise, le client est intouchable, le chef de projet non plus, donc c'est le dev qui se prend le reproche en pleine face alors qu'il n y peut rien.
C'est l'intéret d'inclure tout le monde dés le début dans la discussion, on travaille ensemble et on diminue fortement les problèmes potentiels coté client et chef de projet(ou on peut les pointer du doigt)

Par exemple, un client qui se plaint que son projet n'est pas bon, mais qui n'a jamais assisté aux réunions... c'est surement pas de la faute du dev, plus du chef de projet ou du client selon celui qui n'a pas planifié ou assisté a la réunion.

Le dev lui gardera la même dose d'incompétence et de responsabilité, mais sur le projet entier, on aura améliorer la production de 60-70% avec ces méthodes.

[kdmbella]

En général en plus des délais calculés il faut prévoir un délai pour les imprévus c'est plus réaliste à mon avis et ça permet au moins de donner des échéanciers moins farfelus.

[souviron34]

Mais concrètement, et c'est là ma question car lire le manifesto ce n'est oas très parlant car théorique

Tu as dû mal lire, alors, car c'est exactement le contraire : il n'y a strictement rien de théorique mais seulement de la pratique..

Et c'est ça qui fait peur à bon nombre de boites, de CP, et de managers..

Juste qu'il n'était pas la ou il devait être au bout du compte.
En général, c'est 50% de la faute du client, 30% du chef de projet / gestionnaire des taches et 20% du dev.

Euh.....

Moi je met 80% faute du CP/gestionnaire, et 20% faute du dev.. Client 0%.. Si il n'a pas de trucs précis, c'est que le CP n'est pas arrivé à lui faire cracher...


Quand tu fais construire une baraque, tu peux dire "je veux 4 chambres une sDb et une cuisine", mais c'est l'architecte qui va te présenter un plan précis et te le faire raffiner..

[pmithrandir]

Euh.....

Moi je met 80% faute du CP/gestionnaire, et 20% faute du dev.. Client 0%.. Si il n'a pas de trucs précis, c'est que le CP n'est pas arrivé à lui faire cracher...


Quand tu fais construire une baraque, tu peux dire "je veux 4 chambres une sDb et une cuisine", mais c'est l'architecte qui va te présenter un plan précis et te le faire raffiner..

En fait, je parle surtout des mecs qui viennent, pose un sac de 200 000 sur la table, te donne une consigne du type : faite moi un facebook en mieux pour dans 3 mois, puis refuse tout contact parce qu'ils sont en vacances ou juste pas intéressé par les détails.

3 mois plus tard, ils reviennent et gueule parce que rien n'est fait...(ou pire qu'on a fait et dépensé le budget sans qu'il ne reconnaisse rien qui ressemble a son idée)

Un client pouvant être un autre salarié de la boite dans un grand groupe. (et la, la demande envoyée par email a 18h30 avant son départ en congé, c'est du vécu...) On est content quand on a une question et que la personne n'est pas présente.

Ou tout simplement, celui qui doit te fournir une partie du travail(genre le design qu'il envisage, des images, etc...) qui te les fournis 3 semaines plus tard que prévu mais qui espère toujours que tu vas tenir les délais.

[Cincinnatus]

Autre exemple : Tel module doit implémenter une fonctionnalité réglementaire.
L'équipe fonctionnelle (2 responsables successifs), lorsqu'on demande un CdC, rétorque qu'il nous suffit de lire une circulaire administrative...
Evidemment, à la livraison, cela ne convenait pas.

[Luckyluke34]

3 fois plus de temps me paraît extrême, mais j'ai récemment fait l'expérience d'un projet de dev bouclé avec presque 2 mois et demi de retard sur une durée finale d'un an. Voici les causes qui sont apparues :

• Environ 20% des fonctionnalités prévues au départ se sont avérées non nécessaires et n'ont pas été développées.
• Presque 40% des fonctionnalités présentes à la release n'étaient pas prévues initialement et ont été découvertes et ajoutées en cours de route.
• A la marge, les estimations de départ étaient peut-être erronées. Ou pas. En fait, entre les fonctionnalités ajoutées, retirées, explorées, remaniées, les artefacts extérieurs (équipe variable, difficultés techniques imprévues...) on ne le saura jamais vraiment. Et après tout, qu'importe, si le client est satisfait de ce qu'il obtient ?

Justement, il s'avère que le client était plus que satisfait. Vous vous en doutez peut-être, c'était un projet agile où lui-même a décidé d'écouter le feedback du terrain, de l'application en train de prendre forme (retours utilisateurs, tests en tous genres, discussion avec l'équipe de réalisation...) et de revoir son cap de manière régulière au fur et à mesure des découvertes.

Je ne dis pas que c'est représentatif de tous les projets. Je ne dis pas non plus que toutes les releases agiles ont ou doivent avoir du retard, le client avait aussi l'option de garder la date de mise en prod estimée et dire "Stop ! On livre avec ces fonctionnalités", nous étions prêts.

La leçon que nous avons tiré de ce projet peut se résumer à :
"The Map is not the Territory" - le plan le plus léché ne résiste pas à l'épreuve des faits car par définition, on ne peut pas être conscient à l'avance de ce qu'on ne sait pas. Ce qu'on a découvert au fur et à mesure de la réalisation du produit a été au moins aussi important que ce qu'on avait imaginé au départ. Tenter d'y résister pour coller au plan initial n'aurait fait que produire un logiciel peu utilisable car en contradiction avec la réalité du terrain, et de la frustration chez toutes les parties prenantes (client, utilisateurs, développeurs).

[el_slapper]

(.../...)Moi je met 80% faute du CP/gestionnaire, et 20% faute du dev.. Client 0%.. Si il n'a pas de trucs précis, c'est que le CP n'est pas arrivé à lui faire cracher...


Quand tu fais construire une baraque, tu peux dire "je veux 4 chambres une sDb et une cuisine", mais c'est l'architecte qui va te présenter un plan précis et te le faire raffiner..

Ben oui, mais quand le client te répond "demerdez-vous" quand tu demande si il préfère vanille ou caramel pour le papier peint, et bien sur, il t'accusera d'avoir fait le mauvais choix, fatalement, tu ne peux pas l'exonérer.

Variante : le client a fait une spec d'une précision démoniaque...avec des erreurs(parceque sans erreur, ça n'existe pas). Tu trouves des erreurs - et il refuse de les corriger. Tu dois faire ce qui est signé. Ce qui est signé ne fonctionne pas. 60 personnes sur 18 mois de travail à la poubelle. Je ne veux même pas savoir qui a payé.

[souviron34]

Ben oui, mais quand le client te répond "demerdez-vous" quand tu demande si il préfère vanille ou caramel pour le papier peint, et bien sur, il t'accusera d'avoir fait le mauvais choix, fatalement, tu ne peux pas l'exonérer.

Variante : le client a fait une spec d'une précision démoniaque...avec des erreurs(parceque sans erreur, ça n'existe pas). Tu trouves des erreurs - et il refuse de les corriger. Tu dois faire ce qui est signé. Ce qui est signé ne fonctionne pas. 60 personnes sur 18 mois de travail à la poubelle. Je ne veux même pas savoir qui a payé.

Malgré tout, je dirais que c'est principalement la faute du CP/gestionnaire, qui n'a pas su trouver les bons mots, analogies, ou arguments.....

Mais bon, je parle pas de site Web, mais de projets conséquents, et souvent industriels...

Ce qu'on a découvert au fur et à mesure de la réalisation du produit a été au moins aussi important que ce qu'on avait imaginé au départ. Tenter d'y résister pour coller au plan initial n'aurait fait que produire un logiciel peu utilisable car en contradiction avec la réalité du terrain, et de la frustration chez toutes les parties prenantes (client, utilisateurs, développeurs).

C'est absoument vrai...

C'est ce que j'essaye de propager à coups de posts ici et dans les sous-forums concernés...

Mais (maheureusement) il faut seulement le vivre pour accepter cette réalité....

Si seulement les "managers", CP, et autres écoutaient un peu mieux les "anciens"... plutôt que les normes / méthodes / certifs...

[imikado]

Avec l'expérience, on se rend compte qu'il est plus difficile d'estimer un projet.
De plus si la cible ressemble à un projet déjà fait par le passé, on a souvent une poussée d'optimisme en se disant qu'on a déjà fait, que l'on pourra récupérer de l'autre projet

Ajoutez à cela la différence entre ce qui est demandé (le strict minimum) et ce qui est attendu (la version avec le confort en plus) et on obtient le différentiel qui nous font toujours courir après la montre

Sinon pour information, nous utilisons une méthode itérative qui évite les mauvaises surprises à la livraison finale.
Même si cela rajoute du temps, on peut plus simplement justifier les dépassements de délais, voir arbitrer entre des fonctionnalités en cours de développement

[devicenotready]

Dans Agile ou Scrum, derrière la méthodo, on oublie parfois la base humaine :

• Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
• Business people and developers must work together daily throughout the project.

Pour avoir bossé 18 mois sur un *vrai* projet agile, un des points flagrants est la participation active du développeur, en contact permanent avec le client. Cela suppose de s'impliquer pour comprendre le boulot de chaque intervenant, de garder une vue d'ensemble, de refuser d'implémenter une solution proposée sans poser de question et rechercher le vrai besoin. Ne pas accepter des demandes floues qui ne correspondent à aucun besoin concret. Lever toute ambigüité. Prototyper, valider fréquemment.

Le rôle du client est essentiel. On a avait affaire à une boîte jeune, avec des gens très motivés (marketing, compta, vente, RH...), compétents et réactifs.

Rares sont les fois où on s'est complètement plantés, peut-être sur une ou deux fonctionnalités, quand on a pris pour argent comptant une demande sans approfondir, et où on a pas validé un proto d'écran. Et à chaque fois, c'était une occasion de s'améliorer.

Le périmètre de ce qui allait être fait sur 6 mois n'était pas parfaitement connu (encore qu'avec le calcul de vélocité, on en a une idée!), mais le client avait la garantie qu'il en avait pour son argent, chaque jour de développement servant à réaliser un incrément utile du produit.

[Jarodd]

Je suis actuellement sur une mission où je tiens mes délais, je suis même en avance ! Contrairement aux autres, le client a multiplié par 4 mes estimations (déjà larges). Il a un niveau de conscience que n'avait pas les autres clients. Du coup, je suis moins stressé, ce qui m'aide à tenir ces délais !

[NaetoH]

C'est un problème qui ne changera jamais, surtout en France.

La direction pense qu'une deadline très courte permet au développeur de coder plus vite, alors qu'en réalité ils codent surtout plus sale.

[Traroth2]

Exemple très intéressant car ce type de qualification (point bloquant ou non) devrait être définit par l'Usex... Ou la priorité par le marketing. Finalement, est-ce que les clients (donc les commerciaux) se sont investi dans la réalisation ? Car si ils reviennent avec un NoGo à cause du choix d'avoir une autocompletion, le "dev" a fait son job. Et à mon sens, là c'est une erreur commerciale : en attendant, le site n'est pas en ligne, il ne gagne pas en notoriété, la boite continue de perdre de l'argent (ou de ne pas en gagner) alors que la mise en ligne n'aurai pas empêché d'améliorer et faire un upgrade. We ship, then we test...

Idéalement, une bonne méthode serait de faire exactement l'inverse que ce qui a été fait dans le projet dont je parle : choisir le minimum de fonctionnalité, vraiment juste ce qu'il faut pour que l'appli puisse remplir son rôle et qu'on puisse mettre en prod. Ensuite, on enrichit. Ca a l'avantage supplémentaire de permettre d'avoir du feedback des utilisateurs et de développer moins de fonctionnalités inutiles (vous savez, ces fonctionnalités sur lesquelles vous passez beaucoup de temps, et 6 mois après la mise en prod, on se rend compte que PERSONNE ne s'en sert, parce que ça ne correspond à aucun besoin...)

[lvr]

Idéalement, une bonne méthode serait de faire exactement l'inverse que ce qui a été fait dans le projet dont je parle : choisir le minimum de fonctionnalité, vraiment juste ce qu'il faut pour que l'appli puisse remplir son rôle et qu'on puisse mettre en prod. Ensuite, on enrichit. Ca a l'avantage supplémentaire de permettre d'avoir du feedback des utilisateurs et de développer moins de fonctionnalités inutiles (vous savez, ces fonctionnalités sur lesquelles vous passez beaucoup de temps, et 6 mois après la mise en prod, on se rend compte que PERSONNE ne s'en sert, parce que ça ne correspond à aucun besoin...)

Eaxctement. C'est parfois difficile de faire comprendre au client, surtout lorsqu'on a faire à des clients inexpérimentés.

Ma petite recette pour avoir des budgets pas trop foireux (et juste pour la partie développement):
- Ajouter de 10 à 20% aux estimations faites par mes développeurs,
- Ajouter 25% pour les corrections suite aux tests,
- Ajouter 10% à 20% pour absorber les changements de spécifications de la part du client pendant la phase de réalisation.

Ca donne des budgets relativement juste.
Mais cela dépend, à la base, de la capacité des développeurs à donner rapidement des estimations correctes du travail à faire, et (tout aussi rapidement) de remonter les incohérences et incomplétudes dans les spécifications.

Parfois, cependant, être hors budget est voulu, car le budget de base est trop élevé et effraye le client. On tape donc plus bas, sachant qu'on va dépasser.

[ddoumeche]

Les meilleures estimations étaient faites en équipe via "planning poker" agile et portaient sur des petites fonctionnalités, après discussion entre développeurs.
cela permettait de lever la plupart des lièvres et de corriger les erreurs de chacun

[jjnoui]

Dans les années 80 où Cobol était roi une méthode utilisée :

Figer le cahier des charges,
Estimer de façon très serrée,
multiplier par deux le temps estimé,

Toute demande de modification ne sera prise en compte qu'après la livraison dans les temps du projet initial,

Faire admettre qu'il s'agit d'une estimation sur la charge de travail et non sur le délai (si intevention en parallele sur un autre projet, le délai sera impacté du temps consommé ailleurs.

[Frank P]

Les contours, le sable, la tempête... pipeau ! C'est vrai que l'imprévu (le "sable", la "tempête"), ça existe, que c'est même inévitable. C'est vrai qu'un système informatique, dès lors qu'il est un peu plus ambitieux que "Hello World", est un peu comme une réalité fractale (les "contours") : plus on s'en approche, et plus on s'aperçoit que chaque module en apparence simple est en fait un système plus ou moins complexe.

Mais ce n'est pas l'essentiel. Ce n'est pas l'imprévu technique ou informatique qui fait perdre l'essentiel du temps dans un projet : c'est l'être humain, avec ses comportements parfaitement habituels, ses habitudes inamovibles, ses méthodes souvent canoniques, son organisation verrouillée et presque intouchable, ses systèmes de management et de décisions inefficaces.

------------------------------------------

La réalité en face, c'est l'incompétence de personnes qui, exécutants ou cadres, côté client/métier, côté spécification/Maîtrise d'Ouvrage ou côté réalisation informatique/Maîtrise d'Oeuvre, sont incapables de faire correctement leur travail, de communiquer correctement avec leurs interlocuteurs, de transmettre des informations correctes au maillon suivant ou de demander correctement les informations nécessaires au maillon précédent dans cette chaîne qu'est la conception d'un logiciel.

Ce sont souvent aussi des méthodes auxquelles on est attaché et qui oui, ne sont pas agiles du tout, en tout cas pas adaptées au projet à réaliser. Ou des méthodes agiles que l'on n'a pas bien compris, ou qu'on ne maîtrise pas, quant ce n'est pas que l'on rejette : car il y a dans les méthodes agiles de nombreux principes qui peuvent déplaire, aux développeurs, mais surtout à toute la hiérarchie habituelle d'un projet qui voit bousculés ses petits pouvoirs et remis en question le contrôle qu'elle exerce habituellement.

Et ne parlons pas de nos organisations, souvent bureaucratiques à l'excès, parfois rigides jusqu'à la sclérose. Un nombre d'échelons hiérarchiques tels (et des relations hiérarchiques telles) qu'une information essentielle que détient un exécutant n'atteint jamais la moitié de la pyramide (surtout si elle dérange, elle peut même s'arrêter à l'échelon immédiatement supérieur). S'ajoutent à cela des cloisonnements horizontaux, des découpages par domaine, secteur, département, service... avec les éventuelles tensions ou conflits qu'il peuvent exister entre, pour rendre la communication des informations encore plus difficile. L'organisation "verticale" et "horizontale" des sociétés les rend rarement efficaces pour gérer les projets informatiques, surtout quand le logiciel doit être prêt pour dans 3 mois, car dans un an la donne aura changé.

Jetons aussi un œil sur le management : quel est l'intérêt pour un développeur de faire son travail vite et bien quand il sait que c'est quelqu'un d'autre qui en tirera les bénéfices (reconnaissance, promotion, augmentation). Dans certains projets, ce sont ceux qui ne font pas grand-chose mais savent se vendre qui réussissent à s'attribuer les mérites de la réussite de leur collaborateurs. Ceci est rarement de nature à faire avancer correctement un projet, cela n'assure pas dans l'équipe la motivation et la cohésion nécessaire justement quand il y a un imprévu, un "coup de bourre", une "charrette". Par contre, cela encourage les abandons de poste, les congés maladie et toutes choses que l'on va rajouter bien sûr à la liste des "imprévus" qui ont entravé la bonne marche du projet. Pour ceux qui voudraient comprendre pourquoi il y a autant d'incompétents à des postes pourtant élevés dans la hiérarchie, il y a le Principe de Peter (un peu simpliste, mais hélas pas assez pour être faux).

Ajoutons à cela aujourd'hui une incapacité croissante des décideurs à prendre une décision, rapidement et de façon stable ("on va quand même pas se mouiller, ça pourrait nous retomber dessus"), et comme chaque étape d'un projet est souvent soumise à plusieurs décisions, on comprend pourquoi non seulement on n'arrive pas à la date prévue, mais surtout on ne commence pas à la date prévue !

En plus de cela, il y a un vrai piège : dès qu'on fixe des délais, les différents acteurs fixent leur vitesse de croisière sur ces délais (surtout pas plus tôt, on ne voit aucun intérêt pour soi). Autrement dit, au moindre problème, au moindre impondérable, et un acteur prend 1 ou 2 semaines de retard. Le développement d'un logiciel étant un enchaînement d'étapes, c'est tout le projet qui dérape, entre les aléas des uns et les surprises des autres. Mais là encore, il y a pour cela des méthodes et des formes d'organisation pour éviter ces dérapages.

------------------------------------------

Or tout ceci, ça existe avant le projet, ça se voit, et même dans certains cas ça se sait. Qu'on ne veuille pas en tenir compte pour fixer des délais, planifier, alors oui SURPRISE, JE COMPRENDS PAS, ON PEUT PAS TENIR LES DELAIS !

La communication ça s'apprend. La motivation et l'implication des gens, cela s'encourage, la méthode, ça s'adapte (sinon ce n'est plus une méthode, mais un boulet). Et le management, car plus les projets sont importants, plus c'est là où ça pêche, ça s'apprend aussi et ça devrait s'adapter. L'organisation d'une entreprise, c'est censé s'améliorer aussi pour permettre l'atteinte des objectifs de l'entreprise, et non pour satisfaire les appétits de pouvoir des uns et des autres.

Dans tout cela, il n'y a rien d'imprévisible, rien dont on ne puisse tenir compte pour établir des plannings cohérents, réalistes. Et si l'état des compétences, des motivations, des méthodes, de l'organisation, du management ou du système de décision ne permettent pas de planifier, alors arrêtons de fixer des délais intenables et commençons d'abord par soigner le malade pour qu'il soit en état de marche !

Dans les gros projets, les problèmes informatiques, c'est 80% d'humain et 20% de technique. Les vrais imprévus sont peu nombreux et, à moins d'une destruction des locaux informatiques, jamais susceptibles de repousser notablement la fin de réalisation prévue.

En clair : IL N'Y A AUCUNE LOI QUI FAIT QU'INELUCTABLEMENT, UN PROJET DERAPE. Presque tout est "under control", le tout est de regarder les choses en face, et d'essayer de les changer si besoin pour que les projets puissent enfin suivre un cours normal.

Si nous ne sommes pas capables de regarder en face la réalité, pour voir où sont les vraies sources de dérapage d'un projet, si en plus nous n'avons pas l'envie ou le courage de changer cette réalité pour qu'enfin les projets puissent progresser normalement, alors oui, il faut multiplier par 10 pour être presque certain de ne pas déraper.

[souviron34]

Toute demande de modification ne sera prise en compte qu'après la livraison dans les temps du projet initial,

Et c'est pafff !!!! en plein dans le mille !!!!! L'erreur de fond du "cycle en V"

Vive la satisfaction du client

[rawsrc]

Et c'est pafff !!!! en plein dans le mille !!!!! L'erreur de fond du "cycle en V"

Vive la satisfaction du client

Totalement d'accord : grossière erreur.

Sur un de mes projets, on est parti d'un cahier des charges qui au fil des réunions/releases s'est avéré incomplet, incohérent, voire parfois erroné sur certains points (personne n'a la science infuse non plus). J'ai adapté l'application en intégrant les commentaires et évolutions proposés lors de ces réunions pour, au final, lister toutes les différence entre le cahier des charges initial et l'applicatif afin de négocier un avenant en bonne et due forme aux conditions de signature du premier contrat.

Conclusion : c'est le meilleur des mondes et tout le monde a été satisfait. Souplesse des deux parties.

[LSMetag]

J'ai bossé à la fois en cycles en V et en agile :

------------------------------------------------------------------------

En Agile, la communication directe avec le client est omniprésente, y compris par nous, simple développeurs exécutants, qui n'hésitons pas à vérifier que nous avons bien saisi le besoin, ou à communiquer sur tel ou tel problème qu'un besoin pourrait entraîner et discuter alors de solutions.
Chaque jour un point est fait avec le chef de projet qui nous confirme notre ligne directrice, s'enquérit de l'état d'avancement ou nous redirige.

Résultat, globalement le client est content et l'on tient nos délais avec en général juste des bugs à corriger ou des deltas mineurs par rapport au besoin du client.

Les seuls inconvénients, c'est les clients dits "chiants" qui n'arrêtent pas de modifier leurs besoins en cours de route en imposant la même deadline.

--------------------------------------------------------------------------

En cycle en V dans une grande entreprise, c'est complètement autre chose. L'organisation est extrêmement rigide avec beaucoup d'interlocuteurs entre nous et l'interlocuteur recherché (le demandeur en général).

Il y a le client, la MOA qui relaye la demande du client, la MOE qui récupère le besoin formulé par la MOA et écrit une spécification qu'il fait ensuite valider par la MOA. La MOE qui transmet les spécifications au chef de projet, qui effectue des chiffrages, qu'il retransmet par la MOE au client qui le valide ou non. Et enfin après tout ça, le CP dispatche avec les développeurs.

Mais voila, on obtient l'effet téléphone Arabe où le besoin peut être déformé. De plus, si la MOE ou la MOA lambine (ce qui est arrivé dans le dernier projet où je bossais), le développement commence très en retard, pour la même Deadline...
Si les Devs remarquent des problèmes avec la spec ou une limitation technique, c'est trop tard. Tu peux en parler à ton CP qui va transmettre à la MOE mais ça ira rarement plus loin (le client est Dieu) ou alors la réponse viendra dans plusieurs jours/semaines, ce qui entame encore le délai...

Les points sont aussi plus rares entre CP et développeurs.

Au final, impossible de tenir des délais, on fournit un résultat soit qui ne correspond pas au besoin, soit qui n'est pas fiable car les développeurs n'ont pas été écoutés, soit bâclé.
Résultat => Ce sont les développeurs et le CP qui sont l'objet de toutes les plaintes du client et des utilisateurs et une mauvaise ambiance se met en place...

-------------------------------------------------------------------------

Bref, ce problème est hélas dû à nos méthodologies rigides et cette politique d'échelons hiérarchiques.

Avec une méthode Agile maîtrisée, qui simplifie toute démarche pour la communication entre l'exécutant et le demandeur, qui permet de rester sur le bon chemin et de déceler en amont toute difficulté, on peut éviter pas mal d'écueils souvent rencontrés dans les cycles en V.