Discussion :

[zaventem]

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.

[minuipile]

Le respect du planning n'est pas une qualité logicielle... Elle est limite une qualité management et je pèse mes mots.

Lorsque vous rendez un projet dans les temps :

On peut dire que soit le commercial est avec vous, pour la négociation du temps de projets ; soit vous avez imposé vous même la planification en espérant que vous soyez un bon chef de projet. Si c'est le cas dans 75% des projets... tant mieux... J'ai quand même un doute.

Après, c'est très facile de rendre un travail bâclé dans les temps. Mais si c'est pour renégocier la maintenance autant dire que c'est de l'arnaque. Ou typiquement c'est un marché truqué.

[souviron34]

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).

C'est ça..

C'est à dire que tous les projets faits dans les années 70-80-90 étaient simplistes et moins complexes, utilisaient moins de données, de calculs, et étaient moins fiables qu'aujourd'hui...

Je ne sais pas où tu vis, mais pas dans le monde industriel que je connais...



Non, je parle par expérience de projets que j'ai vu pendant 27 ans...

Alors d'accord c'est dans la recherche industrielle et la recherche.. et pas dans la gestion et le ouaibe..




Je dis juste que les constatations d'échecs ou de retard ne diffèrent guère de ce qu'elles étaient l y a 20 ans...

Et que donc les soi-disant solutions-miracles prônées au gré des modes ne sont pour beaucoup (à part quelques idées novatrices, comme l'a souligné el_slapper) simplement qu'un argument marketing et qu'un truc pour se donner bonne conscience (on s'en fout, les gens payent, c'est la société de consommation), alors que le fond du problème (identifié justement dans le Manifeste Agile) est l'humain, ce que refuse de voir et les formations et les entreprises, qu'elles soient SSII ou en interne.

Le fond est qu'on a essayé et qu'on essaye encore de faire coller la production informatique avec une chaîne de production... en utilisant des gens "remplaçables" et des méthodes et une organisation du travail qui en tiennent compte.


Comme ce modèle ne correspond pas à la réalité, on se plante régulièrement et sur les estimations de difficulté, de budget, et de temps..

C'est tout...



C'est dans l'air du temps depuis 68 : l'informatique, comme la menuiserie, la chanson, le cinéma, ou n'importe quoi, peut être faite par tout le monde, puisque "tout le monde a le potentiel"...

Or, pour faire des choses extraordinaires (quel que soit le domaine) il faut des gens extraordinaires..

Sinon, on a la Star Ac'...

Et l'informatique d'hier et d'aujourd'hui est basée sur ce postulat que tout le monde est remplaçable, et que le travail est découpé et découpable pour être fait par n'importe qui...

C'est donc une Star Ac'...


Avec le même problème : la durée et la validité...


Même un bon menuisier ne fera pas un bon ébéniste.. Même un tailleur de pierre ne sera pas un sculpteur...

[el_slapper]

(.../...)
Et que donc les soi-disant solutions-miracles prônées au gré des modes ne sont pour beaucoup (à part quelques idées novatrices, comme l'a souligné el_slapper) simplement qu'un argument marketing et qu'un truc pour se donner bonne conscience (on s'en fout, les gens payent, c'est la société de consommation), alors que le fond du problème (identifié justement dans le Manifeste Agile) est l'humain, ce que refuse de voir et les formations et les entreprises, qu'elles soient SSII ou en interne. (.../...)

C'est marrant, c'est pas ce que j'ai l'impression d'avoir dit - mais comme je suis d'accord avec ça aussi, je vais pas chipoter.

Cette croyance n'est d'ailleurs pas limitée aux décideurs. Les éxecutants(nous) aussi; il suffit de lire la rubrique "emploi" de ce forum : "tu as 2 ans d'XP sur Fortran et un bac+3 LISP, sur Charleville-Mézières tu vaux donc 24 k€".

Ma toute première mission en développement était, en 2001, un forfait "régissé". Faute de ressources expérimentées, ma boite avait proposé un quarteron de débutants, mais avait refusé de s'engager sur un résultat. Normal. Le Chef de projet - le seul expérimenté du lot - avait eu à chiffrer les tâches du projet. Normal. Je lui demande si il a prévu que nous serions plus lents au début, et plus rapides à la fin - effet d'expérience oblige. Réponse : "non, j'ai juste prévu large parceque vous êtes débutants". J'ai été choqué, et j'ai pensé qu'il était mauvais. En fait, il avait déjà pondéré en fonction de nôtre expérience, et c'était beaucoup plus que ce que font la plupart des chiffreurs, pour qui "une fonction de base, c'est 3 jours, gnou ou génie".

L'autre facteur humain, c'est l'aspect aléatoire. Non seulement le gnou et le génie n'iront pas à la même vitesse pour coder la fonction de base(et la fiabilité varie aussi), mais aussi la "fonction de base" cachera plus ou moins de piège, pas forcément tous identifiés à la spécification. Parceque le spécificateur, autant que le codeur, est un être humain. Et qu'il est limité, autant que le codeur. Donc, il y aura des surprises. Inchiffrables, par définition.

[souviron34]

C'est marrant, c'est pas ce que j'ai l'impression d'avoir dit - mais comme je suis d'accord avec ça aussi, je vais pas chipoter.

Je parlais de ça :

à mon sens les méthodologies modernes entre de bonnes mains font gagner du temps, juste elles sont rarement entre de bonnes mains

Où effectivement on peut éventuellement diverger de point de vue, mais pas tant que ça, car de toutes façons, comme le fond est de trouver "les bonnes mains", que ce soit avec la méthode-ologie A ou B, si il y a "de bonnes mains", ça marchera ..

Je pense profondément que peu importe la méthodologie et le ou les outil(s), l'important c'est vraiment d'"être entre de bonnes mains", que ce soit au niveau marketing, Chef, DG, ou en dessous..

Et que en informatique encore plus qu'ailleurs , car le boulot n'est pas répétitif et a des conséquences directes, les formations, les "normes", la rationalisation souhaitée, et le Principe de Peter font des ravages.....



Sinon entièrement d'accord avec toi...


ou plutôt

[hegros]

Le respect du planning n'est pas une qualité logicielle... Elle est limite une qualité management et je pèse mes mots.

N'importe quoi. La qualité c'est parti intégrante de la qualité logicielle non pas sur la partie produit mais la partie process. Il suffit de regarder la roue de deming (la fameuse roue de la qualité) Elle commence par quoi cette roue ? Par la planification donc pas de qualité logicielle sans planification


Ce que l'article ne dit pas que c'est que 100-25 = 75 soit 75% de projets en échec ou abandonné :-)

[souviron34]

N'importe quoi. La qualité c'est parti intégrante de la qualité logicielle non pas sur la partie produit mais la partie process. Il suffit de regarder la roue de deming (la fameuse roue de la qualité) Elle commence par quoi cette roue ? Par la planification donc pas de qualité logicielle sans planification

Non, il a raison..

Oui le planning est partie du cycle de développement.

Mais : oui, le respect du planning est une qualité du management... Dans management on inclut le Chef de Projet... Plus de la Direction au dessus..

J'ai vu des cas où la Direction ne prenait aucune mesure (et était même plus qu'indulgente) pour des retards gigantesques (du style doublement de la durée prévue))... Et ça c'est une mauvaise direction, et donc une mauvaise qualité de management...

Et le planning a dû être établi par le Chef de Projet..

Donc on en revient à "être entre de bonnes mains", que ce soit en bas ou en haut...

Ce que l'article ne dit pas que c'est que 100-25 = 75 soit 75% de projets en échec ou abandonné :-)

ce qui n'a guère évolué depuis.... 1994

[hegros]

Non, il a raison..

Oui le planning est partie du cycle de développement.

La qualité logicielle c'est un terme suffisamment générique pour y inclure aussi bien les activités de développement que les activités de conduite de projet parce que la qualité en elle même c'est une activité de conduite de projet et la planification aussi.

En se réduisant uniquement à l'aspect produit alors oui la planification ne fais pas parti de la qualité puisqu'elle n'intervient pas dans la qualité interne (comment c'est codé) et la qualité externe (le rendu) d'un logiciel.

Mais de manière générale moi je parle de qualité logicielle pour l'aspect développement et l'aspect conduite de projet (donc planification) parce que je ne suis pas de la old school :-)

[souviron34]

Je ne vois ni ce que "old chool" a à voir, ni ce que "produit" vient faire là..


Du point de vue de la gestion (et la planification fait partie de la gestion, ou réciproquement) du projet (et je ne vois pas où intervient la notion de "produit"), c'est le management (et en particulier le Chef de Projet) qui est responsable d'une part au départ d'avoir rassemblé et évalué les évaluations de ses différents membres (et/ou sous-équipes), et d'autre part en suite de faire en sorte que soit tout le monde s'y tienne, soit de faire évoluer ...

La notion de "dépassement de délai" n'est forcément qu'en terme de gestion...




Et que ce soit méthodes agiles ou "old school", que ce soit qualité logicielle, processus de qualité (cmmi etc), ce n'est pas le développeur de base qui est responsable de la garantie du délai... Il y a par exemple dans les mthodes agiles les réunions d'ajustement régulières, etc etc..

[hegros]

Parce qu'un logiciel est en 2 parties : 1/une production/fabrication (le développement du produit) 2/une orchestration de cette fabrication(la planification et la gestion des coûts)

Et dans le développement moderne ce n'est pas 1 personne qui s'engage pour les délais puisque c'est toute l'équipe et l'équipe influence directement la planification.

C'est pour cela que je parle de qualité produit et de qualité processus qui est une séparation old school de la qualité car la qualité pour moi c'est les 2 car il n'y a pas de qualité de produit sans qualité de processus

C'est ma vision et cela m'est complètement égal que tu ne la partages pas donc n'insiste pas si tu ne la comprends pas. Pour preuve tu ne fais que répéter ce qui est en échec depuis 1940 en séparant la partie développement de la partie gestion de développement. Le management ce n'est pas de la gestion de projet c'est de la gestion d'individu c'est complètement différent.

[souviron34]

je te trouve bien belliqueux alors qu'on est d'accord sur le fond...

[hegros]

je te trouve bien belliqueux alors qu'on est d'accord sur le fond...

Beh non tu confonds gestion de projet(incluant la planification et la qualité) et gestion des individus(management qui n'inclut ni la planification ni la qualité)

Sur le fond nous ne sommes pas d'accord car je dis qu'il n'y a pas de qualité logicielle sans planification et tu dis le contraire en disant que le management intègre la planification

Chacun son point de vue nous ne sommes pas obligé d'être d'accord.

[souviron34]

Beh non tu confonds gestion de projet(incluant la planification et la qualité) et gestion des individus(management qui n'inclut ni la planification ni la qualité)

Je ne confonds pas.. mais la gestion des individus et la gestion du projet sont liés, surtout d'ailleurs en utilisant des méthodologies agiles..

Justement, je ne comprend pas ta séparation...

Sur le fond nous ne sommes pas d'accord car je dis qu'il n'y a pas de qualité logicielle sans planification et tu dis le contraire en disant que le management intègre la planification

Non je ne dis pas ça..

Tu associes séparément qualité logicielle et planification.. Mais que soit XP, RUP, Scrum, ou cmmi et autres, la qualité et la planification font (les 2) partie des métholdogies/processus...

Je ne sépare pas, c'est tout, contrairement à toi..

Quand tu dis :

Parce qu'un logiciel est en 2 parties : 1/une production/fabrication (le développement du produit) 2/une orchestration de cette fabrication(la planification et la gestion des coûts)

Et dans le développement moderne ce n'est pas 1 personne qui s'engage pour les délais puisque c'est toute l'équipe et l'équipe influence directement la planification.

C'est pour cela que je parle de qualité produit et de qualité processus qui est une séparation old school de la qualité car la qualité pour moi c'est les 2 car il n'y a pas de qualité de produit sans qualité de processus

"l'équipe" contient différents niveaux, et , même si on admet que "tout le monde est au même niveau", il n'empêche que tu le dis toi-même "influence la planfication". Ce terme est relatif...

Il n'y a donc pas de séparation absolue et franche..

Que l'équipe s'engage sur un délai ne change rien au fond du problème qui est que si ce délai n'est pas correctement estimé, il y a dépassement...

Et comment gère-t-on ce dépassement ...


Alors qu'il me semble que, bien que tu sois (comme moi) assez porté sur le "développement agile", tu sembles tenir à vouloir faire une séparation entre l'humain et le technique, ou entre "le management" et "le développement"... ce qui est profondément contraire justement aux méthodes modernes et agiles

L'orchestration et la réalisation sont liées..

C'est pour ça que la qualité logicielle n'est ni un outil de la partie "management" ni un outil de la partie "technique", mais est partagée par les 2...

C'est en ça que j'ai beaucoup de mal à voir pourquoi tu réfutes l'assertion de minuipile...

Quand il utilise le terme "management", cela fait aussi bien référence à quelqu'un du marketing ou de la Direction Générale que à quelqu'un de l'équipe.. ou à l'équipe entière....

Quand tu lui réponds "La qualité c'est parti intégrante de la qualité logicielle non pas sur la partie produit mais la partie process." oui et alors ? C'est toi, là, qui fait une distinction en 2 parties... Mais dans la partie process l'équipe n'est-elle partie prenante, au même titre que des vrais niveaux de management ??????

Je crois que tu t'es focalisé sur l'usage du mot "qualité", et qu'à mon avis (mais il faudrait qu'il précise) il l'utilisait plus au sens de "qualité/défaut".


Et que tu as un a-priori (ou une certaine définition non commune) sur le terme "management"...

Chacun son point de vue nous ne sommes pas obligé d'être d'accord.

Absolument, mais on peut discuter sans se faire traiter de c.n, non ???

[hegros]

Non je ne dis pas ça..

Tu dis

oui, le respect du planning est une qualité du management.

Donc non je ne suis pas d'accord car le management ne s'occupe pas de la planification laquelle est une responsabilité de gestion de projet pas de gestion des individus.

Tu associes séparément qualité logicielle et planification

Je dis qu'il n'y a pas de qualité logicielle sans planification et qu'il y a une différence entre la qualité d'un produit (conception interne : comment est écrit le code, qualité externe : comment est rendu à un utilisateur une fonctionnalité) et la qualité des processus (planification, suivi/contrôle, documentation, gestion des équipes,...) Oui il y a une séparation des activités cependant cela ne veut pas dire que l'une ou l'autre est suffisante indépendamment de l'autre.

Il n'y a donc pas de séparation absolue et franche..

Dans les activités si il y a une différence absolue et franche. Ecrire du code ou concevoir un module n'a rien à avoir avec faire une planification ou des estimations ou un suivi.

La force des méthodes agiles c'est qu'elles rendent moins abstraites les activités de conduite de projet en impliquant fortement les développeurs dedans (estimation planification suivi et contrôle...) ce qui n'est pas le cas avec des cycles en V

Et que tu as un a-priori (ou une certaine définition non commune) sur le terme "management"...

Ma définition est celle qui est commune à savoir que c'est l'art de diriger des individus donc rien à avoir avec la technique et la conduite de projet. Il y a plus de séparation entre la technique et le management que la technique et la conduite de projet.

Absolument, mais on peut discuter sans se faire traiter de c.n, non ???

Personne n'a traité de c.n qui que se soit.

[oxyaxion]

Hum 25 % seulement ?

Dans mon entreprise (qui n'a rien d'une PME ...) disons que ça serait plutôt de l'ordre des trois quarts.
Enfin non, je suis mauvaise langue les projets arrivent bien à l'heure car la MOA colle la pression et impose une date buttoir obligatoire. De ce fait les projets sont déployés en prod alors qu'ils ne sont pas finis du tout, et le plus souvent qualifiés façon grand n'importe quoi avec une pré-prod à peine capable de qualifier correctement en amont, pour diverses raisons.

Le soucis étant que personne en prod ou à l'exploit' n'a d'assez grosses corones pour mettre un "no-go" et faire barrage au décisionnel de la MOA. (tous le monde a peur pour son poste).
De ce fait des projets complétement bancals, qui ne seront finalisés qu'après 3/4 voir 5 livraisons sur plusieurs mois... Bref du grand n'importe quoi, et ce sont les p'tits gus comme moi qui ensuite font des heures sup de cinglés avec les responsables sur le dos qui te disent "faut faire ci" et l'autre à côté qui te donne un avis contraire "non faut faire ça" pour faire du débugage en production Je ne pensais pas que c'était aussi stressant comme métier informaticien Enfin j'ai sûrement pas du atterrir dans le bon service je suis tout en bas de l'échelle des projets, côté run.

(Et je ne parle même pas que de "logiciel" mais de projets à grandes échelles infras, refonte de SI etc etc ..)

[Faiche]

haha, dans le sujet : les ravages du retroplanning http://slicesofit.com/amelioration-c...-trompent-pas/

Le projet a pas commencé, il est déjà en retard !