Je suis plutôt d'accord avec l'ensemble des techniques proposées. A noter que les techniques 1, 2, 3, 5 et 6 font partie de la méthodologie SCRUM ou plus généralement de la philosophie agile.
Je note la préoccupation de passer du temps avec les développeurs pour les dissuader de ne pas en faire trop: ne pas utiliser le dernier framework à la mode, ne pas expérimenter de nouvelles techniques, ne pas faire d'interface générique quand il n'y a qu'un seul cas particulier identifié à présent, etc. C'est à mon sens une part importante de la réduction des coûts de dev et j'ai souvent embêté mes développeurs là-dessus:
Exemple
[le développeur naïf]: on nous a demandé un outil au plus vite pour gérer YYY, j'ai commencé à coder qqch en Qt [le cost killer]: outil, ce n'est pas un outil graphique. Vu l'urgence du besoin, tu fais de la ligne de commande et on verra si on on réclame vraiment un GUI.
Dans le monde unix, la ligne de commande est bien connue et valorisée, mais pour des gens qui viennent du monde Windows, il est difficile de concevoir un outil sans interface graphique.
Autre exemple:
[le développeur naïf]: j'ai besoin de gérer la notion de configuration, j'ai vu une lib en python qui gère très bien les .ini , on part sur ça ? [le cost killer]: la syntaxe python fait un très bon fichier de config, tu fais juste un safe_eval() et c'est parti, tu as gagné en flexibilité, familiarité et maintenance (les .ini, c'est chiant à faire évoluer).
Ce serait intéressant de partager d'autres exemples comme ça tirée de votre vie réelle.
Je note en tout cas que c'est vraiment un état d'esprit de faire court et simple (KISS comme on dit de l'autre côté de l'Atlantique), et qu'il est pas si répandu que ça. Le but du projet n'est pas de faire plaisir au développeur mais au client.
L'approche agile par itération pour ce point est vraiment un must!
# Pas mal
Posté par Philippe F (site web personnel) . En réponse au journal Réduire les temps de développement sans sacrifier la qualité. Évalué à 7.
Je suis plutôt d'accord avec l'ensemble des techniques proposées. A noter que les techniques 1, 2, 3, 5 et 6 font partie de la méthodologie SCRUM ou plus généralement de la philosophie agile.
Je note la préoccupation de passer du temps avec les développeurs pour les dissuader de ne pas en faire trop: ne pas utiliser le dernier framework à la mode, ne pas expérimenter de nouvelles techniques, ne pas faire d'interface générique quand il n'y a qu'un seul cas particulier identifié à présent, etc. C'est à mon sens une part importante de la réduction des coûts de dev et j'ai souvent embêté mes développeurs là-dessus:
Exemple
[le développeur naïf]: on nous a demandé un outil au plus vite pour gérer YYY, j'ai commencé à coder qqch en Qt
[le cost killer]: outil, ce n'est pas un outil graphique. Vu l'urgence du besoin, tu fais de la ligne de commande et on verra si on on réclame vraiment un GUI.
Dans le monde unix, la ligne de commande est bien connue et valorisée, mais pour des gens qui viennent du monde Windows, il est difficile de concevoir un outil sans interface graphique.
Autre exemple:
[le développeur naïf]: j'ai besoin de gérer la notion de configuration, j'ai vu une lib en python qui gère très bien les .ini , on part sur ça ?
[le cost killer]: la syntaxe python fait un très bon fichier de config, tu fais juste un safe_eval() et c'est parti, tu as gagné en flexibilité, familiarité et maintenance (les .ini, c'est chiant à faire évoluer).
Ce serait intéressant de partager d'autres exemples comme ça tirée de votre vie réelle.
Je note en tout cas que c'est vraiment un état d'esprit de faire court et simple (KISS comme on dit de l'autre côté de l'Atlantique), et qu'il est pas si répandu que ça. Le but du projet n'est pas de faire plaisir au développeur mais au client.
L'approche agile par itération pour ce point est vraiment un must!