Se connecter
Se connecter
Mot de passe oublié ?
ou
Créer un compte
ou
Se connecter avec Facebook
Notifications
< Retour vers Le Pub
Agrandir
Le Pub
Forums thématiques
Le Pub
Actu 84 84
Articles 54 54
Médias 69 850 69,9k
Tutoriels
Forums 12 126 12,1k

Benchmarking, Lean et tutti quanti : le topic de la qualité (120+ BPM inside)

  • 30 réponses
  • 8 participants
  • 1 054 vues
  • 10 followers
Sujet de la discussion Benchmarking, Lean et tutti quanti : le topic de la qualité (120+ BPM inside)
Pour commencer sur une note légère :
Citation :
Un berger faisait paître son troupeau au fin fond d’une campagne quand, d’un nuage de poussière, surgit une rutilante Range Rover venant dans sa direction. Le chauffeur, un jeune homme dans un complet Armani, chaussures Gucci, verres fumés Ray Ban et cravate Hermes, se penche par la fenêtre et demande au berger :
"Si je peux vous dire exactement combien de moutons il y a dans votre troupeau, m’en donnerez-vous un ?"
Le berger regarde le jeune homme, puis son troupeau broutant paisiblement et répond simplement :
"Certainement"
L’homme gare sa voiture, ouvre son ordinateur portable, le branche à son téléphone cellulaire, navigue sur Internet vers la page de la NASA, communique avec un système de navigation par satellite, balaie la région ouvre une base de données et quelque trente fichiers Excel aux formules complexes. Finalement, il sort un rapport détaillé d’une dizaine de pages de son imprimante miniaturisée et s’adresse au berger en disant :
"Vous avez exactement 1.586 moutons dans votre troupeau."
"C’est exact" dit le berger. "Et comme nous l’avions convenu, prenez-en un".
Il regarde le jeune homme faire son choix et expédier sa prise à l’arrière de son véhicule, puis il ajoute :
"Si je devine avec précision ce que vous faites comme métier, me rendrez-vous mon mouton ?"
"Pourquoi pas ?" répondit l’autre.
"Vous êtes consultant" dit le berger.
"Vous avez parfaitement raison, comment avez-vous deviné ?"
"C’est facile. Vous débarquez ici alors que personne ne vous l’a demandé, vous voulez être payé pour avoir répondu à une question dont je connais la réponse et, manifestement, vous ne connaissez absolument rien à mon métier. Maintenant, rendez-moi mon chien."

Source


Tout est parti de là :
https://fr.audiofanzine.com/le-pub-des-gentlemen/forums/t.461876,qu-est-ce-qui-vous-agace-automatiquement-au-taf,post.7772320.html
https://fr.audiofanzine.com/le-pub-des-gentlemen/forums/t.461876,qu-est-ce-qui-vous-agace-automatiquement-au-taf,post.7777687.html

Go ! 1895264.gif

« What is full of redundancy or formula is predictably boring. What is free of all structure or discipline is randomly boring. In between lies art. » (Wendy Carlos)

[ Dernière édition du message le 27/02/2014 à 22:40:24 ]

Afficher le sujet de la discussion
11

Djardin> Voilà de longues années qu'on ne m'invite plus aux réunions que pour les 10 min où j'ai quelque chose à dire. Si c'est pour poireauter 1h50 à trainer sur AF en n'écoutant pas ce qui se dit, je préfère être sur AF depuis mon bureau. bave

Il y a deux moyens d’oublier les tracas de la vie : la musique et les chats.
Albert Schweitzer

12
Citation de Djardin :
Sinon : http://agilemanifesto.org/iso/fr/

Citation :
Des logiciels opérationnels plus qu’une documentation exhaustive


Donc en gros, tant que ça fonctionne personne ne veut en entendre parler, mais le jour où le référent s'en va, plus personne ne sait faire et il faut tout rétro-documenter voire tout ré-écrire ou supprimer l'appli.

Des années qu'on fait de l'agile sans le savoir. 1895227.gif 1913966.gif

« What is full of redundancy or formula is predictably boring. What is free of all structure or discipline is randomly boring. In between lies art. » (Wendy Carlos)

13

Citation :

Des logiciels opérationnels plus qu’une documentation exhaustive

 Je suis en plein là dedans...

Il y a deux moyens d’oublier les tracas de la vie : la musique et les chats.
Albert Schweitzer

14
Citation de .: :
Citation de Djardin :
Sinon : http://agilemanifesto.org/iso/fr/

Citation :
Des logiciels opérationnels plus qu’une documentation exhaustive


Donc en gros, tant que ça fonctionne personne ne veut en entendre parler, mais le jour où le référent s'en va, plus personne ne sait faire et il faut tout rétro-documenter voire tout ré-écrire ou supprimer l'appli.

Des années qu'on fait de l'agile sans le savoir. 1895227.gif 1913966.gif


C'est pas ça. c'est qu'on part du principe que de toutes façons la documentation (dans le code) ne sera pas à jour. donc plutôt que de faire une fonction fct_get_rp(par1 par2) et de mettre un commentaire, tu fais une fonction retourne_le_prix(quantite, prix_unitaire). C'est plus facile à lire,et du code bien écrit n'a pas besoin d'être documenté (cf le bouquin "Clean Code: A Handbook of Agile Software Craftsmanship"). En gros, pourquoi mettre un commentaire au desssus du nom de la variable pour l'exliquer, plutot que de faire une variable avec un nom explicite ?

ça, c'est pour la doc dans le code. l'autre gros gros truc, c'est la doc de qualité.

En gros, on perd des jours de boulot à faire des documents de conceptions normalisé, inutiles (genre dernière réunion qualité, on a fait un document tellement normalisé que ça aurait pu passer pour n'importe quel projet. aucune info sur ce qui était spécifique à notre projet) que personne ne lira. et à côté de ça on fait un document "officieux" qui comporte les infos utiles, mais pas la mise en page et les 25 visas de chefrs de services.
L'idée c'est de ne faire que la documentation à jour si elle a une utilité. Par exemple, un wiki qui explique comment le logiciel fonctione, c'est simple à lire et à écrire, et surtout à maintenir. une douzaine de documents normés qui ne font que reprendre le document précédent, c'est lourd, laborieux et jamais à jour.


Pour le Lean, dans ce que j'en ai compris c'est d'un côté extrémement puissant et cool (genre pour la doc, c'est justement dire : pourquoi recopier 5 fois la même info dans 5 documents ? c'est une perte de temps et source d'errer, hop, on n'en garde qu'un) mais à la fois un truc qui peut aussi réduire à fond la vision des gens (genre tu es dévellopeur, tu dois dévelloper. pourquoi t'expliquer à quoi va servir ton logiciel ? pourquoi te donner des infos sur la vie de l'entreprise ? c'est une perte de temps)


Après, Lean ou Agile, le problème c'est que souvent c'est amener par des gars qui sont passioné par le truc, mis en place par des vieux de la vieille de manager et qualiticien qui change le nom mais gardent leur vieilles méthoes, et appliqué par des gens qui ne comprennent pas l'intérêt d'améliorer son cadre de travail et son travail.

C'est pour ça que ça marche surtout en informatique : c'est des équipes jeunes, passionnés et souvent qui s'auto organisent (start up) et ne dépendent pas trop d'un vieil ingé qualité.

Référence en matière de bon gout capillaire et vestimentaire.
homme à tête de zizi.

http://soundcloud.com/djardin

15

moi en ISO, je dis toujours que si on n'a pas besoin de documentation, alors on fait pas de documentation. Les gens connaissent leur boulot, pas besoin que la procédure soit écrite. La qualité doit etre au service du taf, pas le contraire. Du coup, on a plein de copains mrgreen

"Les paroles s'envolent, les écrits se perdent"

Putain, 22 ans que je traine sur AF : tout ce temps où j'aurais pu faire de la musique !  :-( :-)

16

Pour le code, il y a longtemps qu'on a choisi de faire comme dit Djardin : variables bien nommées, fonctions idem, code "scolaire" c'est à dire pas astucieux pour rester simple. Après, je fais une doc, oui, une doc qui n'explique pas comment c'est écrit (y'a qu'à regarder mon code) mais comment ça marche, ce qui rentre, ce qui sort, pourquoi on fait ci ou ça, ça donne les clé de la compréhension du bouzin avec les tenants et aboutissants (SAP me donne ça, alors on prend le fichier là et on le pose là avec l'application planifiée "A", comme ça l'application "B" pourra s'en servir, etc...). En plus on fait une doc un peu sexy, avec une belle mise en page, des synoptiques, des dessins, toussa...

 

Il y a deux moyens d’oublier les tracas de la vie : la musique et les chats.
Albert Schweitzer

[ Dernière édition du message le 02/03/2014 à 21:15:11 ]

17
Pour la doc, un bel exemple aujourd'hui : je vois un collègue qui fait des copiers collé. en fait, il recopiait des noms de serveurs depuis un tableau excel dans un document Word normalisé. et le word sera lui même recopié dans un autre word normalisé. Le problème, c'est que quand on va rajouter ou enlever un serveur, le technicien fera la modification dans le tableau excel sur le reseau. et c'est tout. personne ne pensera à changer les word (et d'ici que le 1er soit changé, le 2eme, le 3eme, le tableur exel aura lui aussi rechangé)


Pour la doc dans le code, un truc cool c'est les TDD : Test Driven Devellopment. en gros, on écrit d'abord le test et ensuite on code. l'intéret c'est que comme le test est déjà fait, on sait tout de suite si ça marche ou pas. et que le test, c'est un cas d'utilisation. donc pas besoin d'écrire un manuel utilisateur avec les exemples : les exemples sont les cas de tests. Et surtout, on ne code pas un truc à l'aveugle : si le client est pas capable d'écrire un test, de dire ce que doit faire ou non son truc, ben c'est pas la peine d'essayer de le coder.

Référence en matière de bon gout capillaire et vestimentaire.
homme à tête de zizi.

http://soundcloud.com/djardin

18

recopier des tableaux, pffff

les liens hypertexte c'est pour les chiens ?

Putain, 22 ans que je traine sur AF : tout ce temps où j'aurais pu faire de la musique !  :-( :-)

19
c'est ce qu'il voulait faire d'ailleurs !

mais c'est pas trop la procédure. et on arrive surtout au point principal du problème : c'est des process de merde, t'as une hierarchie de merde. donc arrivé là, tu laisses faire, tu ne fais rien pour améliorer, tu laisses pourrir et tu haies ton boulot.

Référence en matière de bon gout capillaire et vestimentaire.
homme à tête de zizi.

http://soundcloud.com/djardin

20
Citation :
tu laisses pourrir et tu haies ton boulot.

Arrête tout et deviens jardinier. :oops2:

"L'Homme est la nature prenant conscience d'elle même." - Elisée Reclus