Discussion :

[SlashEne]

En temps que développeur ce qui compte à la réussite d'un projet ce n'est pas le pognon que ça a rapporté au directeur ni le nombre d'actionnaire de la boite.

Pour qu'un projet réussisse dans la tête d'un développeur, il lui faut un environnement de travail impeccable et calme (téléphone des clients dans le bureau bani). Il faut que tout les développeurs de l'équipe travail car c'est amusant et non pas "car c'est une étape obligatoire pour devenir chef de projet". Et bien sur une bonne capacité de communication.

Du point de vue du chef de projet c'est le triangle du Cout/Delai/Qualité (choisissez en 2).
Il faut qu'il entretienne le fun des développeurs, (via des formations et des passages de certifications qui sont très motivantes), et qu'il sache parler à la fois au client et aux développeurs.

En effet ce point est très important, si le chef de projet est considéré comme l'interface entre le client et le développeur, si il n'est pas capable de parler techniquement aux développeur, autant faire parler le développeur directement avec le client... vous avez déjà vu un adaptateur qui ne peut pas se brancher à la fois au périphérique à ladapté et à la cible ?

Après tout ce qu'il manque au développeur pour parler au client c'est une connaissance métier, et je veux bien parier sur le fait que tout développeur étant heureux d'en apprendre plus sur le métier de son utilisateur final, aura aussi les qualité de communication requises.

Les cotés organisationnel pour moi ne contribut qu'a 20% à la réussite du projet (le coté sociologique serait 80%).

Je n'ai aucune donnée objectives sur cette affirmation, je constate juste que ceux qui travaillent sans avoir l'impression de travailler font des choses de meilleurs qualité, et n'ont pas besoin d'être suivi pour savoir si ils font bien leur boulot. Et donc le chef de projet devrait mettre ses diagramme de coté 5 minutes pour améliorer la vie de ses développeurs.

Voila mes best practices pour qu'un projet soit mené a bien.

Pour moi la réussite numéro 1 d'un projet n'est pas tant technologique ou organisationnel que sociologique.
c'est la thèse défendu dans Peopleware de Tom DeMarco.

[ZeRevo]

Pour qu'un projet réussisse dans la tête d'un développeur, il lui faut un environnement de travail impeccable et calme (téléphone des clients dans le bureau bani). Il faut que tout les développeurs de l'équipe travail car c'est amusant et non pas "car c'est une étape obligatoire pour devenir chef de projet". Et bien sur une bonne capacité de communication.

Passage très subjectif. Certains trouves qu'un projet a réussit car ils ont eu une prime ou car ils ont rien glandé et que d'autres dév. ont bossé à leur place.
On peut trouver qu'un projet a réussi simplement parce qu'on y a participé et que le projet a été mis en prod. sauf que l'ambiance était difficile (pression, délais courts, chef de projet imcompétent, etc etc...) et qu'il n'y avait pas de test unitaire ni d'intégration et pas mal de bugs (sauf bugs bloquants).

[Garulfo]

[...]un projet a réussi[...]

Un projet a réussi parce que le client est satisfait du résultat et reste satisfait par la suite. C'est aussi simple et complexe que ça.

[B.AF]

Oui enfin c'est surtout les deux côtés :

C'est quoi un projet qui a réussi :

Un projet a réussi parce que le client est satisfait du résultat et reste satisfait par la suite. C'est aussi simple et complexe que ça.

"C'est comment qu'un projet réussi" :
Là je suis 100% en pahse avec slashene.

Après on peut tout voir, mais c'est vrai que si dans la chaine, tout le monde prend du plaisir et de la satisfaction, y compris le client, c'est plutôt bon signe...

Après, mesurer les échecs, c'est une autre histoire...
Mais là où je prône le même discours que slashene, c'est que pour moi l'informatique est un domaine suffisamment complexe pour qu'il ne puisse pas y avoir une personne à avoir la vérité. Moi j'aime me dire que je travaille avec des gens avec lesquels le débat d'idée existe, car souent c'est de là que naisse les vraies bonnes idées.

Et puis au global c'est plus motivant de travailler avec des personnes impliquées qui ont la banane.

Bref, l'informatique, c'est une grande aventure humaine.
Et comme je ne suis pas "pur" jus informaticien, j'ai commencé par un autre corps de métier, sans écouter, point de salut.

[ZeRevo]

Un projet a réussi parce que le client est satisfait du résultat et reste satisfait par la suite. C'est aussi simple et complexe que ça.

C'est une vision très idéaliste d'un projet informatique. La plupart du temps le développeur est détaché de la notion de client. De plus, on fait pas de livraison toutes les semaines, donc s'il faut attendre 6 mois pour être content de son travail, ca laisse beaucoup de temps pour déprimer. La motivation se cultive au quotidien.

De plus on choisit pas son client, des fois le projet peut avoir réussi au niveau informatique du terme et raté au niveau recette, délais, etc...

Mais là où je prône le même discours que slashene, c'est que pour moi l'informatique est un domaine suffisamment complexe pour qu'il ne puisse pas y avoir une personne à avoir la vérité. Moi j'aime me dire que je travaille avec des gens avec lesquels le débat d'idée existe, car souent c'est de là que naisse les vraies bonnes idées.

Et puis au global c'est plus motivant de travailler avec des personnes impliquées qui ont la banane.

Bref, l'informatique, c'est une grande aventure humaine.

La je suis bien d'accord. Rien de tel que s'amuser au quotidien dans son travail et de travailler avec des personnes compétentes et motivées

[souviron34]

C'est une vision très idéaliste d'un projet informatique. La plupart du temps le développeur est détaché de la notion de client. De plus, on fait pas de livraison toutes les semaines, donc s'il faut attendre 6 mois pour être content de son travail, ca laisse beaucoup de temps pour déprimer. La motivation se cultive au quotidien.

De plus on choisit pas son client, des fois le projet peut avoir réussi au niveau informatique du terme et raté au niveau recette, délais, etc...

NON

Ce que dis Garulfo, c'est que le seul critère de réussite d'un soft c'est qu'il soit utilisé, et que l'utilisateur soit satisfait...

Je suis désolé de te décevoir, mais un projet informatique n'est pas le fait que les développeurs s'éclatent....

Un projet informatique est une réalisation correspondant à un besoin ou une demande...

Quelle que soit la technologie utilisée ou le style de code ou n'importe quoi de technique, l'utilisateur s'en fout complètement....

Aimerais-tu attendre 12h au guichet de la SNCF pour avoir un billet de train parce que les développeurs se sont éclatés avec tout un tas de langages et features ????

Par conséquent la seule mesure de la réussite d'un projet est que cela soit utilisé et qu'il y ait satisfaction...

Mais t'en fais pas.. Des beaux projets qui ne servent à rien ou ne sont jamais utilisés, ça existe... Ceux-là sont peut-être une réussite pour le Chef de Projet (si c'est un labo de recherches), mais c'est un échec dans tous les autres cas....


L'informatique n'est qu'un OUTIL pour faciliter la vie d'utilisateurs...

[ZeRevo]

Ce que dis Garulfo, c'est que le seul critère de réussite d'un soft c'est qu'il soit utilisé, et que l'utilisateur soit satisfait...

Non il parle de projet pas de software, c'est pas la même chose. Le projet est tout les actions entreprises avant de fournir le software (en production).

L'informatique n'est qu'un OUTIL pour faciliter la vie d'utilisateurs...

Quel entreprise se soucie de l'ergonomie des applications ? Combien de fois on voit des projets où la charte graphique a été créé par les développeurs ? (Palette de couleur mal adaptée, ergonomie mal fichu, taille de police trop grande ou trop petite, temps de chargement trop long etc etc...).

J'ai un peu du mal à vous suivre quand vous dites que seul compte le plaisir du client, car je trouve que j'arrive à produire du code de qualité quand j'ai des outils adaptés, que l'architecture est cohérente, que le projet contient des tests unitaires et fonctionnels, ...
Si je me focaliserai uniquement sur le besoin du client je ferai de la merde...

[souviron34]

Non il parle de projet pas de software, c'est pas la même chose. Le projet est tout les actions entreprises avant de fournir le software (en production).

Cela fait partie du tout..

Tu peux avoir la meilleure équipe possible, suivre la norme CMMi nveau 3, et que ton projet échoue, car il n'est pas utilisé ou les utilisateurs non satisfaits..

J'ai un peu du mal à vous suivre quand vous dites que seul compte le plaisir du client, car je trouve que j'arrive à produire du code de qualité quand j'ai des outils adaptés, que l'architecture est cohérente, que le projet contient des tests unitaires et fonctionnels, ...
Si je me focaliserai uniquement sur le besoin du client je ferai de la merde...

Mais quand tu utilises un logiciel, tu la vois, la qualité du code, l'architecture du projet, le nombre de gens dans l'équipe, quelle méthode ils ont utilisé, ??????

Et encore, tu es "sensibilisé" à l'informatique...

Tu as un point de vue de "développeur", mais encore une fois ce n'est pas la mesure de la réussite d'un projet..

Et si, comme tu dis Si je me focaliserai uniquement sur le besoin du client je ferai de la merde..., eh bien je te souhaite bien du plaisir dans ta future carrière.... Je dirais qu'au moins 75% des bons softs sont bons justement parce que ils se sont focalisés sur le besoin du client.... et que 90% de ceux-là sont plus ou moins artisanaux... ne suivent pas de nomenclatures, de méthodes, d'outils de développement "adaptés", etc etc... 90% des codes industriels existants ont été developpés avec des éditeurs directs style Emacs , vi, TextEdit, etc...


Si le soft qui aide un pilote de 747 à piloter n'est pas exactement suivant les besoins de son utilisateur, je ne donnerais pas cher des voyages que tout le monde fait !!!!!

Tu crois que le pilote il en a quelque chose à cirer que tu aies utilisé CMMi ou ISO-9002 ou n'importe quoi ?? Tu crois que ça le préoccupe de savoir si l'architecture est correcte (et qu'est-ce que ça veut dire ??) ou que les développeurs aient eu en leur possession un bon IDE ??? Il s'en fout royalement... Tout ce qu'il veut, c'est que le soft fasse ce dont il a besoin, et soit facile d'accès et que son ergonomie corresponde aux situations d'urgence.. Un point c'est tout....

Et c'est aussi ce que nous on veut en tant que passager.... Que le pilote soit capable de piloter sa machine...

[B.AF]

Dans mes bras Souviron !!!!!!!!!!

[chaplin]

Et si, comme tu dis Si je me focaliserai uniquement sur le besoin du client je ferai de la merde..., eh bien je te souhaite bien du plaisir dans ta future carrière.... Je dirais qu'au moins 75% des bons softs sont bons justement parce que ils se sont focalisés sur le besoin du client....

- Ok

Tu crois que ça le préoccupe de savoir si l'architecture est correcte (et qu'est-ce que ça veut dire ??) ou que les développeurs aient eu en leur possession un bon IDE ??? Il s'en fout royalement... Tout ce qu'il veut, c'est que le soft fasse ce dont il a besoin, et soit facile d'accès et que son ergonomie corresponde aux situations d'urgence.. Un point c'est tout....

- Ok, c'est le point de vue des utilisateurs

De dire:

Tu as un point de vue de "développeur", mais encore une fois ce n'est pas la mesure de la réussite d'un projet..

Il ne faut pas oublier:

J'ai un peu du mal à vous suivre quand vous dites que seul compte le plaisir du client, car je trouve que j'arrive à produire du code de qualité quand j'ai des outils adaptés, que l'architecture est cohérente, que le projet contient des tests unitaires et fonctionnels, ...

Je me suis battu comme un tigre pour avoir des formations et des mises à jours pour avoir une vision comme celle-ci:

Mais là où je prône le même discours que slashene, c'est que pour moi l'informatique est un domaine suffisamment complexe pour qu'il ne puisse pas y avoir une personne à avoir la vérité. Moi j'aime me dire que je travaille avec des gens avec lesquels le débat d'idée existe, car souent c'est de là que naisse les vraies bonnes idées.

Et puis au global c'est plus motivant de travailler avec des personnes impliquées qui ont la banane.

Bref, l'informatique, c'est une grande aventure humaine.
Et comme je ne suis pas "pur" jus informaticien, j'ai commencé par un autre corps de métier, sans écouter, point de salut.

Pour arriver à ce résultat:

Par conséquent la seule mesure de la réussite d'un projet est que cela soit utilisé et qu'il y ait satisfaction...

C'est la finalité, mais ça ne tombe du ciel et il faut de la compétence, de l'énergie et une foi quasi religieuse pour convaincre et changer les mentalités ou plutôt les mauvaises habitudes.

[ZeRevo]

Mais quand tu utilises un logiciel, tu la vois, la qualité du code, l'architecture du projet, le nombre de gens dans l'équipe, quelle méthode ils ont utilisé, ??????

L'utilisateur ne le vois pas mais derrière, le logiciel sera mieux adapté au refactoring, aux évolutions, à la maintenance et la relation cout/qualité/rapidité sera bien meilleure que dans le cas où on se focalise uniquement sur les besoins du client et qu'on ne prend pas le recul nécessaire pour avoir un projet de qualité autant au niveau utilisateur qu'à la maintenance et évolution.

[souviron34]

L'utilisateur ne le vois pas mais derrière, le logiciel sera mieux adapté au refactoring, aux évolutions, à la maintenance et la relation cout/qualité/rapidité sera bien meilleure que dans le cas où on se focalise uniquement sur les besoins du client et qu'on ne prend pas le recul nécessaire pour avoir un projet de qualité autant au niveau utilisateur qu'à la maintenance et évolution.

ça c'est la théorie...

Et la pratique pour les meilleurs...

Mais encore une fois, ce n'est pas ce qui fait le succès (et donc la réussite) d'un projet...

Il y a beaucoup de projets industriels qui sont le fait d'une ou 2 personnes, et/ou qui survivent 20 ou 30 ans... Même si ils sont mal foutus à l'intérieur..

Le client étant celui qui a le mot de la fin, ça simplifierais le travail, oui, mais ça n'empêche aucunement de maintenir et faire évoluer un outil existant...

Je peux te citer en exemple le soft sur lequel j'ai bossé l'hiver dernier : 2 millions de lignes, écrites en Fortran il y a 30 ans, puis re-factorées en C il y a 15, puis en ce moment dans le processus d'être refactorées C++. Vendu - très cher (plus de 1 million d'euros pièce) - à 800 exemplaires dans 150 pays, et dont dépend notre sécurité tous les jours (formation des contrôleurs du ciel).

Le code est plein de hacks, de features non documentées, de bouts de code fait par l'un ou l'autre, pas avec la même philosophie, patchés, re-patchés, re-repatchés (les lois / les contraintes / les environnements évoluent).

Oui des fois ça prenait un mois pour isoler et trouver la solution d'un bug. MAIS c'est opérationnel depuis 30 ans...

Et le fond de tout, c'est que les profs et élèves trouvent qu'il est correct, car nos vies dépend d'eux...

PS : Ah!! J'ai oublié de mentionner que la dernière "bonne" doc remontait à.. il y a 7 ans...

[chaplin]

800 X 4 000 000 = 2 800 000 €, elle est où la crise ?

J'oubliais, la sécurité n'a pas de prix.

Au fond, il faut avoir l'esprit ouvert, il y a plusieurs façon de considerer "la réussite d'un projet". A en devenir philosophe.

4 000 000 de lignes en C, au secours !!

[souviron34]

4 000 000 de lignes en C, au secours !!

Bah c'est courant dans l'industrie...


Depuis 15 ans je ne travaille que sur des projets > 2 millions de lignes. Et encore, dans la finance, ou dans l'aéronautique, on est plus proches des 10 à 15 millions de lignes...

C'est bien pour ça que je disais que il fallait prendre en compte la pratique...

Et que du coup ce que disait Garulfo est la pierre de base de tout...


C'est sûr qu'on ne parle pas du développement de petits sites Webs;..

(quoique le problème se pose de la même manière : sur les sites que vous survolez, combien y en-a-t-il desquels vous êtes 100% satisfaits ?? moi très peu... Et pourtant les développeurs ont soi-disant toutes les technologies, outils, IDE, RAD, méthodes et méthodologies, etc etc..)

Mais même dans des gros projets (plusieurs dizaines, voire centaines, de personnes, pendant une dizaine ou une quinzaine d'années, durée de vie et de maintenance de 15 à 20 ans, budget de dizaines à 100 aines de millions, ...) je ré-tère ce que j'ai dit plus haut en réponse à ZeRevo, et appuie 100% ce qu'a dit Garulfo.

Votre vision est jeune et pure et théorique (pas mal Noir et Blanc), mais la pratique est faite de gris, et la pratique c'est qu'un projet est réussi quand on s'en sert et que les utilisateurs sont contents...

Et l'écriture ou l'architecture ou la méthode ou les outils utilisés n'ont qu'un très lointain rapport avec cette réussite...

[souviron34]

800 X 4 000 000 = 2 800 000 €, elle est où la crise ?

Bon le prix est plutôt de 1 000 000 l'unité (corrigé ci-dessus), mais de toutes façons :

• faut revoir les maths : 4 * 8 ça fait 32 chez moi... et pas 28..
  
  
• donc le vrai total est : 800 * 1 000 000 = 800 000 000
  
  
• mais c'est réparti sur 30 ans... soit 24 millions / an.. pas gigantesque.... Bon chiffre d'affaire, mais des boîtes comme Renault, Dassault, Bouygues, TF1, etc.. etc en font 10 à 100 fois plus...

[souviron34]

J'étais aussi confronté aux programmes de 20 ans d'âge, un boulet qui après sert d'outil de chantage pour celui qui s'en fait maître.

C'est encore une fois que tu te trompes...

Ce n'est que très très rarement le cas où c'est un moyen de chantage.

Comme dit plus haut, c'est dans l'écrasante majorité des cas parce que le produit est bon, et que pourquoi vouloir refaire quelque chose qui marche bien ??

Ce n'est pas parce que le Pont du Gard a 2000 ans qu'on voudrait le refaire.. surtout avec des matériaux et de la construction moderne, dont tout le monde constate que ça tient beaucoup moins longtemps..

Ce n'est pas parce qu'une technique ou technologie est vieille qu'elle est mauvaise...

Si un programme a 20 ans c'est qu'on l'utilise depuis 20 ans. Un nombre incalculable de tests et de debugs ont été faits. Qui vraisemblablement seraient à recommencer et re-résoudre si on ré-écrivait le soft...

Qui voudrait a) repayer et b) accepter de retourner 20 ans en arrière dans les erreurs et bugs simplement pour satisfaire "une technologie nouvelle" ????

Si la POO prend tellement d'ampleur aujourd'hui, c'est qu'elle présente un esthétisme qui se pérénerisera dans le temps. Ca n'a rien à voir avec tous ces programmes d'un autre temps fais avec des outils d'un autre temps, toujours utilisés aujourd'hui dont je ne critique pas l'efficacité, mais la nouvelle génération arrivant séduite par ces technologies favorisera les langages objets.

Je ne veux pas faire de polémique, mais si Java ou C# attirent tellement les jeunes c'est que ce sont des langages esthétiques malgré le tappage médiatique fait par les éditeurs, mais la tendance est bien là.

Juste pour dire que l'esthétisme est un facteur pour la réussite d'un projet car il va draîner des développeurs talentueux. Sans oublier la maintenance de codes volumineux concernant des programmes hyper critiques irremplaçables donc utilisées.

Voir le fil mentionné ci-après (procédural vs objet)

Mais fondamentalement je ne suis absolument pas persuadé de ton point.

Comme dit dans le débat cité, de mon point de vue l'esthétisme est plutôt du côté fonctionnel.

C'est orienté Utilisateur, Marketing, bref tout sauf technique informatique. Et par conséquent ça s'explique facilement SANS concepts informatiques, qui dans 10 ou 20 ans auront certainement changés.

Quant au volume du code, et à son esthétisme, personnellement je le trouve beaucoup plus volumineux et laid en Objet (des factorys, des classes, des sous-classes, etc etc... des duplications ou overrides de méthodes qui fait que la même fonctionalité devient vite illisible pour peu qu'on ait de nombreuses classes).

Faire une fonctionalité du style Affiche_Image par exemple pourra, suivant les modélisations, avoir 20 méthodes différentes suivant que la conception a éte faite avec 20 types d'images (bmp, jpg, gif, etc..), et être répartie dans 60 fichiers différents (les .h , les factories, les classes), au lieu de 2 à 22...

D'après mon expérience, le nombre de fichiers est de 3 à 5 fois plus important en Objet qu'en non-objet, et cela me semble donc, pour de très gros projets, beaucoup plus in-maintenable et difficilement compréhensible qu'un découpage fonctionnel....




Bon toute cette discussion est un peu HS par rapport au titre du thead et aurait peut-être plutôt à voir avec d'autres débats sur ce forum (par exemple Une conception ou un code sale est-il un danger pour l'entreprise), en particulier cette dernière partie vers Les avantages du procédural par rapport à l'objet..

Mais on peut quand même dire que cela rentre dans le cadre, en mettant en évidence les écueuils rencontrés dans la mise en place des bonnes pratiques...

[chaplin]

J'ai complètement buggé . En programmation, c'est le compilateur qui me corrige, et mon étourderie m'oblige à être vigilant sur la qualité du code.
Mais en programmation, j'en ai fait d'une faiblesse une force en mettant l'accent sur les tests, car ils sont un point important dans la réussite d'un projet, nouveaux ou anciens.

EDIT: Zut, j'étais devancé, j'ai supprimé le message parce qu'effectivement je le trouvais hors sujet, bonnes remarques .

Sans redébattre, le langage ADA est un bel exemple de l'utilisation de la POO dans le milieu industriel.

[souviron34]

d'ailleurs, juste pour terminer ce sujet , et le fait que le seul bon jugement de la réussite est l'usage et la satisfaction des utilisateurs, le soft dont je parle ci-dessus, même si techniquement derrière c'est un gros sac de spaghettis , est classé premier du monde par les utilisateurs

CQFD...

[B.AF]

Ok, il y a aussi des softs biens faits dont les clients sont contents et pour autant les développeurs ne s'épanouissent pas dans la boite.
Et si cette situation perdure, le projet peut échouer dans la durée.

[ZeRevo]

Le client ne serait il pas plus content d'avoir un logiciel modulable, adaptable et faible en cout de maintenance ?

Parler de logiciels préhistoriques datant de plus de 10 ans alors que depuis les langages, les méthodes et l'informatique en général ont beaucoup évolué, j'en vois pas trop l'utilité.

Le gros problème dans tous les projets c'est qu'à la base on fait des choses trop spécifique, et voir les choses trop abstraites revient à créer une complexité par toujours nécessaire. Ce qui m'importe c'est comment réussir à créer un logiciel utilisable et maintenable avec les outils, langages et méthodes actuelles.