Réduire les coûts sans sacrifier la qualité est évidemment intéressant pour l'entreprise ou le client car :
- soit vous avez la même chose pour un coût inférieur,
- soit vous avez un périmètre fonctionnel plus étendu pour le même prix.
Ce n'est pas totalement vrai. Les plus gros défauts des analyses de coûts que je peux lire sont systématiquement 1. qu'elles font l'hypothèse que l'univers peut être modélisé avec des additions et dans quelques cas extrêmes des multiplications, et 2. qu'elles ne décrivent pas assez soigneusement le système qu'elles étudient. Ici c'est le 2, car lorsque tu as livré ton produit, ton entreprise n'est plus la même! Tu as des développeurs qui ont acquis des connaissances, soit purement techniques, soit plus conceptuelles (techniques de programmation, techniques de génie logiciel, gestion de projet par exemple), par exemple.
Ainsi donc, si on fait l'hypothèse que "le temps de travail utile" contribue soit directement à l'élaboration du produit final, soit à apprendre des choses on conclut qu'on peut réduire les coûts sans sacrifier la qualité sans pour autant arriver à une situation plus enviable pour l'entreprise: c'est le cas où on a rogné sur l'apprentissage.
Ceci dit, je peux passer l'âme tranquille à la suite de mes remarques, encore moins intéressantes que la première:
Technique n°2 — se limiter strictement au cahier des charges
Parfois, en tant que développeur, on se dit "ah mais si je fais ça de telle manière, ça prend juste quelques jours de plus et ça permet d'avoir un système plus évolutif". Et en général plus complexe, donc plus fragile.
Oui et non, vu que très certainement il va falloir faire la maintenance du logiciel, cela peut être une bonne chose de s'y préparer – avec discernement, mais c'est justement ce discernement que peut apporter l'expérience au travers d'une palette de techniques éprouvées et validées qui résolvent justement ce problème.
Disons que si on se limite strictement au cahier des charges de façon la plus littérale qui soit, on peut dans certains cas torcher un programme tout mal fichu "qui fait le job" mais dont les évolutions sont impossibles à partir de 4-5 itérations, et là on se retrouve dans la pire situation, avec un bug en prod et un logiciel tellement mal conçu que réécrire tout ou partie est un a priori nécessaire à la réparation! (Vécu.)
Technique n°4 — faire du « test-driven » sur les interfaces
J'ai l'impression que tu cantonnes le "test-driven" aux test unitaires automatiques. C'est un exemple important, mais je trouve l'approche "test-driven" particulièrement utile pour la conception du logiciel, et même dans le cas où on n'automatise pas les tests. Privilégier les tests oblige à concevoir des modules qui ne font pas référence au contexte global de l'application, ils sont donc plus facilement réutilisables. Je trouve aussi particulièrement utile de déléguer tous les accès au système à des classes spécialisées: le reste du code est alors essentiellement pur et peut-être testé avec des classes simulant les appels système (mockup). Cette technique réduit la complexité de mise en œuvre du test et accélère la boucle de développement.
Technique n°6 — Diviser pour mieux régner
Bien souvent les jeunes diplômés (en particulier) ne veulent pas faire de maintenance mais veulent concevoir un logiciel entier. Et lorsqu'il s'agit de reprendre du code, plutôt que le faire évoluer ils préfèrent souvent tout refaire de zéro.
Ils ont bien tort, faire de la maintenance est une des meilleures écoles pour apprendre à programmer simplement et efficacement! (Si on se donne la peine de tirer les leçons de chaque opération de maintenance.)
Technique n°7 — Écrire du code simple
« Ce qui se conçoit bien s'énonce clairement » — Nicolas Boileay-Despréaux.
... et les mots pour le dire viennent aisément!
Souvent les développeurs veulent faire des choses compliquées, et exploiter les fonctionnalités d'un langage au maximum. Mais la réalité c'est qu'un logiciel qui est écrit simplement fonctionne aussi bien qu'un logiciel exploitant toutes les particularités d'un langage.
C'est exact, mais cela néglige complètement l'aspect maintenance (et aussi l'aspect apprentissage). Si une version, en plus d'être plus courte, est plus facile à maintenir, il n'y a aucune raison de ne pas la retenir!
# Hypothèse fondamentale discutable
Posté par Michaël (site web personnel) . En réponse au journal Réduire les temps de développement sans sacrifier la qualité. Évalué à 5.
Ce n'est pas totalement vrai. Les plus gros défauts des analyses de coûts que je peux lire sont systématiquement 1. qu'elles font l'hypothèse que l'univers peut être modélisé avec des additions et dans quelques cas extrêmes des multiplications, et 2. qu'elles ne décrivent pas assez soigneusement le système qu'elles étudient. Ici c'est le 2, car lorsque tu as livré ton produit, ton entreprise n'est plus la même! Tu as des développeurs qui ont acquis des connaissances, soit purement techniques, soit plus conceptuelles (techniques de programmation, techniques de génie logiciel, gestion de projet par exemple), par exemple.
Ainsi donc, si on fait l'hypothèse que "le temps de travail utile" contribue soit directement à l'élaboration du produit final, soit à apprendre des choses on conclut qu'on peut réduire les coûts sans sacrifier la qualité sans pour autant arriver à une situation plus enviable pour l'entreprise: c'est le cas où on a rogné sur l'apprentissage.
Ceci dit, je peux passer l'âme tranquille à la suite de mes remarques, encore moins intéressantes que la première:
Oui et non, vu que très certainement il va falloir faire la maintenance du logiciel, cela peut être une bonne chose de s'y préparer – avec discernement, mais c'est justement ce discernement que peut apporter l'expérience au travers d'une palette de techniques éprouvées et validées qui résolvent justement ce problème.
Disons que si on se limite strictement au cahier des charges de façon la plus littérale qui soit, on peut dans certains cas torcher un programme tout mal fichu "qui fait le job" mais dont les évolutions sont impossibles à partir de 4-5 itérations, et là on se retrouve dans la pire situation, avec un bug en prod et un logiciel tellement mal conçu que réécrire tout ou partie est un a priori nécessaire à la réparation! (Vécu.)
J'ai l'impression que tu cantonnes le "test-driven" aux test unitaires automatiques. C'est un exemple important, mais je trouve l'approche "test-driven" particulièrement utile pour la conception du logiciel, et même dans le cas où on n'automatise pas les tests. Privilégier les tests oblige à concevoir des modules qui ne font pas référence au contexte global de l'application, ils sont donc plus facilement réutilisables. Je trouve aussi particulièrement utile de déléguer tous les accès au système à des classes spécialisées: le reste du code est alors essentiellement pur et peut-être testé avec des classes simulant les appels système (mockup). Cette technique réduit la complexité de mise en œuvre du test et accélère la boucle de développement.
Ils ont bien tort, faire de la maintenance est une des meilleures écoles pour apprendre à programmer simplement et efficacement! (Si on se donne la peine de tirer les leçons de chaque opération de maintenance.)
... et les mots pour le dire viennent aisément!
C'est exact, mais cela néglige complètement l'aspect maintenance (et aussi l'aspect apprentissage). Si une version, en plus d'être plus courte, est plus facile à maintenir, il n'y a aucune raison de ne pas la retenir!