Discussion :

[Marco46]

On appelle ça souvent le modèle en V.

Non c'est pas la même méthode.

Le schéma du waterfall c'est ça : \
Le schéma du cycle en V ben c'est ça : V

[Heziva]

Le schéma du cycle en V ben c'est ça : V

Connais tu un projet en V où :
- Les tests de recette ont été écrits avant de commencer à rédiger les spécifications
- Les tests de validation ont été écrits avant la conception architecturale
- Les tests d'intégration ont été écrits avant la conception détaillée
- Les tests unitaires ont été écrits avant le développement ?

[nonoxp]

Oui, attention le cycle en V met en relation presque "contractuelle" les phases préliminaires avec les phases finales d'un projet, afin d'avoir des indicateurs mesurant l'écart spécs-réalisation.

On le confond souvent à tort avec le waterfall qui est vraiment un tube partant du début et allant à la fin du projet d'un trait (le niveau 0 d'industrialisation des process).

Dans la pratique, c'est vrai qu'on appelle les "cycle en V" quelquechose qui est plus proche du "waterfall". Mais tout ça c'est de la comm. pour rassurer le client final en lui faisant croire qu'on a pensé à tout.

[andry.aime]

C'est ça pour moi qui cause les plus gros problèmes dans le planning. L'ajout de fonctionnalités en cours de projet !

Ben c'est pas un retard si c'est pour l'ajout de fonctionnalité. On a un retard si on dépasse le deadline prévu dans le contrat. Ajout de fonctionnalité --> un autre petit contrat --> projection du deadline.

[ram-0000]

Un planning prévisionnel n'est que ça, prévisionnel. Tenter une prévision au jour près, ce n'est pas de la bonne gestion de projet, c'est de la divination.

Un planning prévisionnel sert à prévoir à partir de quand on va annoncer du retard

[Patriarch24]

Si on prends en compte :
- le coût
- la qualité
- le périmètre fonctionnel
- les délais
je pense qu'on est largement plus près des 90% que des 25%. En effet, boucler un projet en le bâclant, le rognant et masquant les problèmes, c'est non seulement faisable, mais malheureusement courant : alors oui, on "termine" dans les temps, mais à quel prix ?

A ce propos, ni les cycles en V ni les cascades (aucune méthode ne le permet d'ailleurs) ne permettent de gérer correctement tous ces paramètres en parallèles, sauf dans les rares cas où les besoins sont déjà connus exhaustivement, ainsi que les coûts. C'est un jeu de tiroirs dans lequel il faut fixer un ou plusieurs paramètres et faire varier les autres : il est concrètement impossible de maximiser toutes les valeurs (délais courts, coût minimal, qualité maximale, périmètre fonctionnel maximal), d'autant plus que le périmètre fonctionnel change au cours du projet. Les méthodes agiles permettent d'ajuster ces paramètres au cours du projet, afin d'atteindre une configuration proche (coûts réduits, délais respectés, périmètre fonctionnel maîtrisé, haute qualité). Et surtout, elles permettent de clore le développement d'un projet au plus tôt (réduction du coût) si on estime ne pas pouvoir respecter ces contraintes.

[kh4y3m]

Bonjour,
un rapport d'un organisme américain prétend qu'à peine plus de 30% des projets sont livrés à l'heure.
www1.standishgroup.com
Je suis pas loin de les croire!
++
H

[istace.emmanuel]

Pour ma part c'est souvent du Rational Unified Process avec des touches d'agilité en plus et du TDD pour les core implémentation/test et ça tiens +/- les délais.

Mais de la à dire qu'il n'y a jamais de retard... C'est une autre histoire ^^

[parrot]

Pour les projets en waterfall, on mesure les dépassements de délai. Et ce n'est pas très brillant!

Pour les projets agiles, il faut plutôt mesurer le pourcentage de fonctionnalité qui n'a pas été réalisée dans les délais impartis. Et je pense que cela ne sera pas très brillant non plus!

Pour prévoir avec précision dans quelle situation un projet se trouvera dans une, voire deux années, je ne vois pas de meilleure solution que de faire appel à Elisabeth Teissier

A mon sens, le plus important avant le développement est de se livrer à une analyse "coût/apport à l'utilisateur" de chaque fonctionnalité. Il devient ainsi possible d'implémenter d'abord les fonctions importantes. Les "nice to have" peuvent même être ignorées sans pour autant trop impacter l'utilisateur. Le calcul de ce rapport coût/apport est demandé par la méthode scrum (peut-être aussi par d'autre méthodes agiles, je ne suis pas au courant), ce qui fait à mon avis une part de son succès.

[fregolo52]

Connais tu un projet en V où :
- Les tests de recette ont été écrits avant de commencer à rédiger les spécifications
- Les tests de validation ont été écrits avant la conception architecturale
- Les tests d'intégration ont été écrits avant la conception détaillée
- Les tests unitaires ont été écrits avant le développement ?

(en effet !!!)

25% je trouve ça faible, surtout qu'il y a souvent des changements de specs en cours de réalisation.
Est ce que les 25% intègre ça : Un énorme (l'Etat français) dit à son fournisseur (énorme industriel français) : "C'est clair, vous livrez en temps et en heure. Mais vous livrez de la merde."

[marten.cylemb]

Si le pourcentage de projets qui ne respectent pas leur planning est de 25%, c'est surement parce qu'ils ne compte pas dedans les projets qui n'arrivent pas à leur terme, non ?

[fregolo52]

Si le pourcentage de projets qui ne respectent pas leur planning est de 25%, c'est surement parce qu'ils ne compte pas dedans les projets qui n'arrivent pas à leur terme, non ?

Tu veux dire que c'est les mêmes que ceux qui font les stats des retards à la SNCF ?
Pour rappel, un train supprimé n'est pas un train qui arrive en retard !!!

[saymoneu]

Dans les entreprises ou je suis passé c'était plus du 50% voire plus de projets en retard.

Ca n'avait d'ailleurs pas l'air de beaucoup les inquiéter...

[psychadelic]

Les retards seraient dûs, pour un tiers des entreprises interrogées, au manque de compétences nécessaires à la réalisation de leurs projets, de méthodologie dans la gestion de projet et de qualification sur les principes de planification. L'absence de culture de projet ainsi que le manque de formations ont également évoqués.

Donc, si j'ai bien compris...
les retards sont dus pour
1/3 => manque de compétences dans la réalisation du projet.

et les 2/3 restants ?
d'apres mon expérience (et les nombreux témoignages que j'ai pu lire ici), ils sont du au "clients qui ne savent pas vraiment ce qu'ils veulent, et chnange d'idées plusieurs fois au cours de la réalisation du projet".

Il y a aussi le cas du projet réalisé dans les délais et répondant parfaitement au cahier des charges, mais dont le client se rend compte que c'est complètement à coté de ses besoins, et qu'il ne s'en servira pas...

[marten.cylemb]

et les 2/3 restants ?
d'apres mon expérience (et les nombreux témoignages que j'ai pu lire ici), ils sont du au "clients qui ne savent pas vraiment ce qu'ils veulent, et chnange d'idées plusieurs fois au cours de la réalisation du projet".

Je suppose que certains en ont déjà parlé, mais dans ce genre de conditions les méthodologie de gestion de projet telles que Scrum me semble particulièrement adaptées.

En effet Scrum, part du constat que le développement logiciel est par essence sujet à d'énormes changement, changement récurrent de spécifications, nouvelles fonctionnalités, abandon de certaines, etc.

Un contrat est alors passé avec l'équipe en charge des développements : L'équipe de développement obtient la garantie que le périmètre à développer dans la période en cours (appelés : Sprints) ne changera pas, en contrepartie de quoi, le périmètre des sprints suivant reste totalement modifiable par la personne en charge du produit (Produc Owner).

Bien entendu, tout ceci n'est qu'une partie de Scrum et n'est en rien représentatif de la méthode en soit, c'est juste un exemple qui peut en intéresser certains

A vos recherches !

[zaventem]

Il ne faut pas oublier que les entreprises ont également beaucoup de projets non liés à l'informatique; cela explique sans doute la différence de perception entre la majorité ici et l'analyse.

[souviron34]

comme il a été dit , d'une part 75% des entreprises ne répondent pas, et d'autre part pour celles qui répondent, ça m'étonnerait qu'elles disent la vérité (en particulier celles qui se vantent d'être "certifiées").

On tombe donc bien sur un chiffre de 30 à 40% minimum, et de 70% si on compte entre délais et bâclage et réponses non données.

Ce qui n'est en rien différent des chiffres dans les années 80 ou 90.


Et donc tous les trucs-bidules-machins-choses (langages, paradigmes, métholodogies, outils, frameworks, ...) dont on se gagarise à longueur de pubs, d'argument commercial, et de posts ici-même, n'a rien changé sur le fond du problème..

D'une part ça ne m'étonne pas (j'ai déjà cité longuement les pourquois ailleurs), et d'autre part ça devrait relativiser un peu les élans de beaucoup ici...


Comme le disent ram-000 et Patriarch24...


Contrairement à la théorie on a "l'expérience montre que"..

[Rams7s]

Et donc tous les trucs-bidules-machins-choses (langages, paradigmes, métholodogies, outils, frameworks, ...) dont on se gagarise à longueur de pubs, d'argument commercial, et de posts ici-même, n'a rien changé sur le fond du problème..

Ca dépend non?
On a quand même des défis qui ont évolué en terme de quantités de données, de fiabilité, etc.
Les temps de développement aussi. Je ne pense pas que parce qu'on met 6mois en J2EE on serait aller beaucoup plus vite il y a 10ans pour faire la même chose avec une autre techno.

Ou les projets sont peut-être encore plus ambitieux, a l'aire de tous connecte ca parait simple et normal de pouvoir tout faire en un click de souris ... quand on est la MOA.

Ne parler de l'aspect projet en retard qu'a travers l'évolution des technologies et des méthodes de gestion de projet (ou pas!) c'est peut-être un peu réducteur. Il y a aussi une évolution de ces projets en eux même, des attentes, des points sur lesquels on se focalise (design technique VS graphique, rapidité de codage VS maintenance).

+1 parrot sur la mesure des fonctionnalités dans les méthodes agiles

[Génoce]

Ou les projets sont peut-être encore plus ambitieux, a l'aire de tous connecte ca parait simple et normal de pouvoir tout faire en un click de souris ... quand on est la MOA.

"Tu peux rajouter un bouton qui fait mon taf? Ca devrait pas être trop dur c'est un bouton..."

[el_slapper]

"Tu peux rajouter un bouton qui fait mon taf? Ca devrait pas être trop dur c'est un bouton..."

En plus de soutenir souviron sur ce sujet(mais pas pour les mêmes raisons que lui, à mon sens les méthodologies modernes entre de bonnes mains font gagner du temps, juste elles sont rarement entre de bonnes mains), je souscris à cette ironie.

Parceque mon expérience est parsemée d'exemples où les outils modernes étaient manifestement sous-optimisés par rapport aux vieux machins.

Exemple 1 : la MOA exige qu'une grande partie de la nouvelle chaine soit faite en cobol Z/OS, alors même que le début part d'un ETL sous unix, et la fin de chaine est aussi sous unix. Pourquoi? Les développements cobol(techno des années 60, sans objet, sans fonctions définies par l'utilisateur, et sans niveau d'accès des données) est bien moins cher en jours-hommes que les ETL ou on tire des traits.

Exemple 2 : j'arrive pour faire de l'homologation sur un grand projet de migration COBOL-MVS vers SAP-UNIX. Il y a 12 programmeurs prévus sur 18 mois pour ça. Je regarde la spec. Je fais une estimation rapide : en cobol, tout seul, il me faut 6 mois. Parceque je ne passe pas mon temps à me battre avec des problèmes de performances et que je me contente de coder ce qui est spécifié. C'est tout.



alors effectivement, la MOA qui ne connait pas le cout des ETL et qui croit que coder ça se fait en claquant des doigts, c'est un classique. Ici on a pas ce problème, ils ont un progiciel ETL-like qui leur permet de faire certaines choses, et ils ont appris à leurs dépens que ça n'était pas si simple que ça.