Discussion :

[Invité]

D'ailleurs, en règle général, lorsque l'on parle "qualité" à un développeur ou autre, c'est plutot de gros yeux, genre, "qu'est ce qu'il vient m'emmerder avec ça lui", ou plutot l'air pensif, "ça peut etre intéressant" ?

Je suis tout à fait d'accord avec toi. nous l'avons subi pendant quelques temps (et même encore).
L'exemple que je donne toujours est le suivant :
"Si demain le ou les développeurs qui ont fait un application sans la documenter meurent, il sera difficile de la reprendre telle quelle par une autre personne"....
L'expérience nous a prouvé que d'amener la qualité, permet un meilleur produit, une meilleure compréhension, un meilleure évolutivité, suivi, maintenance, correction, ....
La subtilité dans tout cela est de les amener à le faire sans rejet, et leur prouver que c'est un plus SIGNIFICATIF pour tout le monde....

[tipiak]

D'ailleurs, en règle général, lorsque l'on parle "qualité" à un développeur ou autre, c'est plutot de gros yeux, genre, "qu'est ce qu'il vient m'emmerder avec ça lui", ou plutot l'air pensif, "ça peut etre intéressant" ?

enfin la qualité ne dois pas non plus être un flic à mauvais developpeur

de meme si tu mets des outils en place, le premier truc auquel il faut penser c'est le client et dans ce cas la le client des outils de qualité c'est les developpeurs (et autres personnes du projet)

d'ou le pourquoi il ne faut pas être trop rigide et adapter la qualité
(la sur-qualité est super chiante car en plus elle te coute chere et te fait passer pour un dictateur....)

et la dose de qualité à mettre en place est propre à chaque projet, chaque entreprise ....
il faut par contre toujour garder le contact avec les equipes projets faire des retours sur experience (avoir toi meme appliqué tes propositions dans le cadre de projets (pour te rendre compte si c'est pas trop contraignant si c'est assez adapté etc etc...))

[flure]

"Si demain le ou les développeurs qui ont fait un application sans la documenter meurent, il sera difficile de la reprendre telle quelle par une autre personne"

Entièrement d'accord, mais d'un autre coté, c'est un peu comme dans l'administration (non, non je ne veux froisser personne) le fait de détenir les "clés" donne le sentiment d'etre indispensable, donc pas de doc = appropriation du développeur de SON code

[flure]

enfin la qualité ne dois pas non plus être un flic à mauvais developpeur

de meme si tu mets des outils en place, le premier truc auquel il faut penser c'est le client et dans ce cas la le client des outils de qualité c'est les developpeurs (et autres personnes du projet)

d'ou le pourquoi il ne faut pas être trop rigide et adapter la qualité
(la sur-qualité est super chiante car en plus elle te coute chere et te fait passer pour un dictateur....)

Sans etre rigide ni flic (quoique... ) je vois plus cela comme de l"assistance" dans le bon sens du terme, mais il faut qu'il y ait une volonté de vouloir "bien" faire...

Après, les intérêts sont surement divers, d'un coté les développeurs qui passent plus de temps à "créer" qu'a debugger et de l'autre, les clients, qui ont, en theorie, un logiciel plus fiable et performant

[Invité]

si cela t'intéresse j'ai un exemple concret donnée en DESS par un prof qui est dans une société appelé "MAP système" (autour de la certification):
L'exercice consiste à répartir dans les phases d'un projet de développement d'un système, les activités et tâches des processus génériques (avec abstraction des paramètres et contraintes de temps, de délais, de coût, de criticité du projet) basé sur le cycle en V...
Pour chaque phase, il y a la partie Client & fournisseur...
C'est assez intéressant et c'est basé sur ISO 9000.....
Contactes moi et je te l'envoie :-)

CARPE DIEM