Discussion :

[Rockz]

Salut,

Le temps de réalisation d'une appli varie considérablement, selon si on l'on couvre ou non nos sources par des tests unitaires (JUnit, TestNG pour le dev Java notamment). C'est un minimum pour encourager la non-régression de l'appli par la suite.

Pourtant, pas mal de clients tentent de raboter au max. leurs coûts et se contenteraient bien d'une appli qui roulotte sans qu'elle soit renforcée par les TU.

Alors comment gérez vous ce volet ? Vous n'acceptez que des missions où la réalisation prévoit de fournir les TU, ou vous faites le choix dangereux de développer à la nique sans filet ?

[Marco46]

Pourtant, pas mal de clients tentent de raboter au max. leurs coûts et se contenteraient bien d'une appli qui roulotte sans qu'elle soit renforcée par les TU.

Ce fonctionnement coûte plus cher, beaucoup plus cher, si on prend le projet dans son ensemble, c'est à dire d'un point de vue MOE :

1. Réalisation d'une première version de prod.
2. Gestion de la maintenance corrective.
3. Gestion de la maintenance évolutive.

Le client peut avoir l'impression de gagner de l'argent sur les factures du point 1 (et encore ça dépend de ce qu'on appelle première version de prod, si le besoin n'est pas cadré sérieusement il s'agit plutôt de la première livraison tout court), mais il va perdre plusieurs fois ce montant sur les points 2 et 3, au point de les mettre en risque d'infaisabilité si la qualité se dégrade vraiment beaucoup. Ça peut arriver sur plusieurs années de vie d'un projet qu'il soit impossible de toucher à quoi que ce soit sans générer plus de bugs.

La question de la gestion contractuelle des anomalies est absolument déterminante. Si on t'interdit de développer avec des tests automatisés (les TU seuls sont insuffisants) et qu'on te fait porter la responsabilité et le coût des anomalies il y a un gros problème de cohérence au mieux, et de compétence en génie logiciel d'un point de vue plus général.

Autre point, l'absence d'automatisation des tests a mécaniquement un impact énorme sur le TTM (Time To Market c'est à dire la capacité à produire et délivrer vite une nouvelle version). Les projets qui effectuent seulement une recette manuelle sous forme de QA à l'ancienne ne livrent de nouvelles versions que 3 ou 4 fois par an au maximum, c'est physiquement impossible de faire mieux.

A titre personnel et en prenant le point de vue purement développeur/grouillot au raz des pâquerettes je me suis tellement habitué à développer en TDD dès qu'il y a un tout petit peu de complexité dans une fonction que ne plus pouvoir travailler de cette manière me ferait perdre beaucoup de temps.

Personnellement je n'accepte plus de mission où le client / employeur se mêle de ces questions ou refuse d'intégrer un minimum de qualité à ses productions.

[Carhiboux]

Salut,

dans mon entreprise actuelle (client final dans le secteur bancaire), nos DSI cherche à tout prix à raboter les prix (tant sur les TJM que sur les couts des projets). Donc on est totalement dans ce que tu décris, on a des livrables qui passent généralement les cas les plus courants, mais dès qu'il y a une petite subtilité, le comportement n'est pas celui attendu.

Donc on explose les couts de maintenance corrective. Mais les top management s'en foutent, parce qu'ils ont "sorti" le projet en seulement 1670jours au lieu de 1725j. Et ça, ça les fait grave band** mousser.

Et comme toujours dans ces cas là, le réalisateur que ce soit fait en interne ou en prestation s'aligne sur les exigences du donneur d'ordre. Faute de quoi, le donneur d'ordre va voir ailleurs. Service d'à côté, autre SS2I, etc... La qualité, c'est clairement pas encore un soucis dans le process de developpemement en France pour le moment à part dans quelques domaines critiques (défense, aéronautique, etc...)

[Marco46]

Donc on explose les couts de maintenance corrective. Mais les top management s'en foutent, parce qu'ils ont "sorti" le projet en seulement 1670jours au lieu de 1725j. Et ça, ça les fait grave band** mousser.

Oui c'est souvent du à un problème de comptabilité. Les entreprises qui délèguent leurs développements ne savent pas estimer leurs couts réel parce qu'ils sont incapables de mettre une production en face d'un prix.

La qualité, c'est clairement pas encore un soucis dans le process de developpemement en France pour le moment à part dans quelques domaines critiques (défense, aéronautique, etc...)

Pour avoir une véritable prise en compte de la qualité il faut aller dans les quelques grosses structures qui ont compris ce problème ou chez des éditeurs de logiciels / services. En lurkant un peu sur LinkedIn ça se trouve assez facilement, leurs annonces sont très différentes.

[v1cent]

Un client qui a confiance en nous, on peut lui expliquer ça et il le comprends. Sur la plupart des projets sur lesquels j'ai bossé ces dernières années j'ai pu intégrer à la fois un travail de documentation sérieux et le temps nécessaire pour faire les tests.

Il m'est arrivé pour manger de faire ce genre de job "sans filet" en sous-traitance... je ne crois pas qu'un seul de ces projets ait mené à un truc rentable pour le client au final ...

Il m'est arrivé bien plus souvent de récupérer de la maintenance sur des projets développés comme ça, et ça a fini par coûter une fortune au client en maintenance.