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 ^^
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
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 ^^
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.
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 ?Envoyé par kiku127
Pour rappel, un train supprimé n'est pas un train qui arrive en retard !!!
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...
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...
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 !
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.
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"..
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
Il ne faudrait pas oublier que dans le monde de l'entreprise l'informatique est très souvent une part accessoire de l'activité et que les expériences que nous vivons dans ce domaine ne sont pas forcément représentatives de l'ensemble.
Par exemple chez moi on a eu comme projet des déménagements, la mise en place d'enquêtes de satisfaction, l'organisation de journée d'entreprise, refonte des processus métiers, etc.
Répondre avec citation
Partager