Pour la gestion de versions, au contraire, je connais des clients qui sont prêts à payer pour que ce soit bien fait. Par contre le coût n'est pas explicite, il est souvent implicite et compris dans celui du développement (par ex).
Ils ont bien compris (j'imagine à la dure) que la gestion de branches, versions... est extrêmement sensible dans le cas de la maintenance logicielle.
Certains même demandent à déposer les sources dans leur VCS, et bien sur à utiliser leur VCS en cas de TMA. Ca me parait tout à fait sain, dès que le client est assez gros pour avoir son propre département informatique (capable donc de mettre en place les outils et process et les équipes pour les gérer).
Pour les tests, c'est à la fois plus simple et plus compliqué.
Les tests unitaires sont pour moi indissociables du développement et font partie du coût de dev. Je ne montre jamais au client un coût séparé pour les devs et les TU.
Par contre pour les tests d'intégration, là oui j'estime que ces couts sont montrables. Tout d'abord parce qu'ils ne sont pas forcément proportionnels aux cout de devs et qu'ils peuvent être calculés à part (ex: un test d'interface); ensuite parce que c'est un moyen de montrer au client qu'on s'assure que l'appli marche bien dans son ensemble avant de la lui livrer.
Un client ne peut pas à la fois exiger la qualité et ne pas payer pour cela (enfin si ils essaient, mais il ne faut pas céder).
Il faut convaincre en montrant tous les aspects négatifs de ne pas faire de TI (tests d'intégration) : manque de qualité, rejet utilisateur, recette plus longue (et délais de mise en prod explosés), maintenabilité en baisse, etc...
Pour l'industrialisation (donc j'imagine que tu parles par ex d'une PIC ?), je rejoins ton sentiment, c'est quelque chose qui sera difficile à facturer. Perso je vois ça plus comme un investissement à faire une année A, qui va améliorer les choses à l'année A+1 (gains de productivité, détection des régressions...)
J'ai pas encore rencontré de client qui était prêt à payer pour ça, je pense que c'est un coût à intégrer aux développements si tu souhaites en mettre une en place.
(vous aurez bien compris que je me place dans le cas du dév d'une application dite de gestion, pas d'un programme de type kernel, driver, programmation de commande numérique, etc...)
[^] # Re: qu'est-ce qu'il dit ?
Posté par Pierre Tramonson . En réponse au journal Ce qu'on demande à un développeur aujourd'hui. Évalué à 2.
Pour la gestion de versions, au contraire, je connais des clients qui sont prêts à payer pour que ce soit bien fait. Par contre le coût n'est pas explicite, il est souvent implicite et compris dans celui du développement (par ex).
Ils ont bien compris (j'imagine à la dure) que la gestion de branches, versions... est extrêmement sensible dans le cas de la maintenance logicielle.
Certains même demandent à déposer les sources dans leur VCS, et bien sur à utiliser leur VCS en cas de TMA. Ca me parait tout à fait sain, dès que le client est assez gros pour avoir son propre département informatique (capable donc de mettre en place les outils et process et les équipes pour les gérer).
Pour les tests, c'est à la fois plus simple et plus compliqué.
Les tests unitaires sont pour moi indissociables du développement et font partie du coût de dev. Je ne montre jamais au client un coût séparé pour les devs et les TU.
Par contre pour les tests d'intégration, là oui j'estime que ces couts sont montrables. Tout d'abord parce qu'ils ne sont pas forcément proportionnels aux cout de devs et qu'ils peuvent être calculés à part (ex: un test d'interface); ensuite parce que c'est un moyen de montrer au client qu'on s'assure que l'appli marche bien dans son ensemble avant de la lui livrer.
Un client ne peut pas à la fois exiger la qualité et ne pas payer pour cela (enfin si ils essaient, mais il ne faut pas céder).
Il faut convaincre en montrant tous les aspects négatifs de ne pas faire de TI (tests d'intégration) : manque de qualité, rejet utilisateur, recette plus longue (et délais de mise en prod explosés), maintenabilité en baisse, etc...
Pour l'industrialisation (donc j'imagine que tu parles par ex d'une PIC ?), je rejoins ton sentiment, c'est quelque chose qui sera difficile à facturer. Perso je vois ça plus comme un investissement à faire une année A, qui va améliorer les choses à l'année A+1 (gains de productivité, détection des régressions...)
J'ai pas encore rencontré de client qui était prêt à payer pour ça, je pense que c'est un coût à intégrer aux développements si tu souhaites en mettre une en place.
(vous aurez bien compris que je me place dans le cas du dév d'une application dite de gestion, pas d'un programme de type kernel, driver, programmation de commande numérique, etc...)