Doit-on abandonner la responsabilité du test d’un logiciel à celui qui écrit ses lignes de code ?

Citation:

---

Envoyé par martopioche

Peut-être, et point intéressant, mon intervention part de l'opinion de Marco comme quoi les devs devraient pouvoir poser "leur veto" sur une livraison. À priori, Marco connait la vélocité de son équipe, donc est censé "tenir la date sans 'dégrader le code'"…*Sinon, à quoi sert la métrique de la vélocité…

---

Je peux livrer n'importe quand mais pas n'importe quoi ni n'importe comment. Et pour conserver le pouvoir de livrer n'importe quand je dois absolument ne jamais livrer n'importe comment. En définitive c'est forcément le scope qui est variable.

Je te la refais pour que ce soit parfaitement clair :

Je dois pouvoir livrer n'importe quand.
Pour pouvoir livrer n'importe quand je dois parfaitement maîtriser mon système.
Pour parfaitement maîtriser mon système ma qualité doit être optimale.

Si on me force à livrer un scope imposé à une date imposée, je dois dégrader la qualité, et donc je prends des risques pour les livraisons suivantes qui vont se cumuler surtout si on conserve le même paradigme.

C'est ce que Luckyluke34 a essayé de t'expliquer.

Citation:

---

Envoyé par martopioche

Alors c'est à nouveau là que ça deviens intéressant : à nouveau, ma date n'a rien d'arbitraire. Et je ne sais pas dans quel contexte vous travaillez, dans le service public ou en associations, un objectif d'impératifs techniques est certainement une finalité, mais dans un contexte d'entreprise, la finalité est commerciale.

Lorsque le "le commercial touche sa prime", il permet aussi une facturation. C'est cette facturation qui permet de financer des trucs aussi futiles comme…*les salaires des développeurs. De ce fait, si le développeur estime qu'il doit avoir son mot à dire sur la partie commerciale, il doit à mon sens prendre également la responsabilité de la conséquence (je suis indépendant, je l'applique à chaque décision…). Bref, cette considération est très intéressante, mais elle ne réponds pas à ma question :

Quel est le rapport avec une mise en production au 23 qui n'a rien d'arbitraire ? En quoi éviter une hausse des couts dans la durée (quelle durée) a plus de conséquence que de ne pas mettre en prod' le 23 ?

---

Une date de mise en prod peut être arbitraire tant que le scope de la livraison ne l'est pas. C'est la combinaison de l'arbitraire sur la date et le scope qui pose problème.

Par hausse des coûts on entend hausse des risques. Si le coût augmente et qu'on continue à m'imposer date + scope c'est forcément un risque de sortie de route. C'est exactement comme rouler trop vite, on risque de partir dans le décor.

Et c'est justement pour protéger la boite qu'il ne faut pas faire ça.

Ce que tu dis c'est qu'un cuistot doit être capable de sortir from scratch un banquet pour 100 personnes en deux heures à partir du moment où le serveur l'a vendu. C'est parfaitement idiot.

Citation:

---

Envoyé par Marco46

Je peux livrer n'importe quand mais pas n'importe quoi ni n'importe comment. Et pour conserver le pouvoir de livrer n'importe quand je dois absolument ne jamais livrer n'importe comment. En définitive c'est forcément le scope qui est variable.

---

Tout à fait d'accord.
C'est en livrant n'importe quoi qu'on devient n'importe qui.

Bonjour

46% de réponse avec

Citation:

---

Elle s’appuie uniquement sur les retours des utilisateurs

---

ça fait froid dans le dos. Cela veut-il dire que 46% des développeurs ne comptent que sur leur client pour débugger leur création ? 8O ?? Normalement il y a 10% de tout dans le monde ; ça devrait donc faire 10% de branleurs, pas 46 ! :aie:

Pour moi la responsabilité dépend beaucoup de l'application, typiquement tester une IHM ne peut se faire en profondeur que par une multitude de testeurs qui vont pour beaucoup mal l'utiliser. Alors qu'une application de calcul a des entrants clairement identifiés qu'il est possible de tester bien avant que le client y touche.

Il y a aussi des niveaux de test. La semaine dernière je reçois une appli Android qui a été modifiée, la moitié des fonctions de base déjà en production depuis des mois ne marchent plus, comme des trucs aussi idiots que le son pas actif ! => là il y a de la fumisterie dans l'air ! à l'inverse il y a 2 fonctions métier qui sont inversées ; le développeur s'est planté mais même en testant 5000000x son truc il ne verra jamais son erreur puisque ce problème métier n'a pas de sens pour lui alors que pour le client c'est une évidence.

donc clairement non, on ne peut pas abandonner les tests d'un logiciel à celui qui a écrit les lignes.
Quant à la responsabilité, mon point de vue de client est que si le client ne se garde pas cette ultime responsabilité c'est qu'il ne voit pas grand intérêt dans le logiciel qu'il a acheté !

Citation:

---

Envoyé par Marco46

Je dois pouvoir livrer n'importe quand.
Pour pouvoir livrer n'importe quand je dois parfaitement maîtriser mon système.
Pour parfaitement maîtriser mon système ma qualité doit être optimale.

Si on me force à livrer un scope imposé à une date imposée, je dois dégrader la qualité, et donc je prends des risques pour les livraisons suivantes qui vont se cumuler surtout si on conserve le même paradigme.

---

Mais ce n'est pas du tout ma question…*Je ne t'ai jamais demandé si tu peux livrer n'importe quand mais le 23 novembre ! Et le scope est évidemment imposé… Mais si tu connait ta vélocité, cela est certainement négocié et avec certainement pour conséquence de dégrader ta…*Tes métriques. D'où ma question : En quoi éviter une hausse des couts dans la durée (quelle durée) a plus de conséquence que de ne pas mettre en prod' le 23 ?

Citation:

---

Une date de mise en prod peut être arbitraire tant que le scope de la livraison ne l'est pas.

---

Une date de livraison est rarement arbitraire…

Citation:

---

Par hausse des coûts on entend hausse des risques. Si le coût augmente et qu'on continue à m'imposer date + scope c'est forcément un risque de sortie de route. C'est exactement comme rouler trop vite, on risque de partir dans le décor.

---

Et ? En quoi ce risque est plus important que de ne pas livrer le 23 ?

Citation:

---

Et c'est justement pour protéger la boite qu'il ne faut pas faire ça.

---

Et pourtant, pour protéger la boite, il faut livrer le 23…

Citation:

---

Ce que tu dis c'est qu'un cuistot doit être capable de sortir from scratch un banquet pour 100 personnes en deux heures à partir du moment où le serveur l'a vendu. C'est parfaitement idiot.

---

C'est tout à fait idiot en effet car dans ce cadre, un cuistot connait…*sa vélocité…*Il sait quel délais, quel produits, quel matériel et quel personnel il lui faut pour assurer ce banquet et il peut donc produire pour le banquet. Ce que toi tu me dis, c'est qu'on conviendra pour un banquet, mais tu livrera peut-être autre chose…*Tout ça pour ne pas dégrader ton matériel. Un cuistot lui, livrera ce qui est attendu, lorsque c'est attendu (c'est à dire avec les plats chauds même si les convives ont décidés de retarder le service…) et si le matériel doit être remplacé après la livraison, il le replacera…

Je travaille sur des projets de systèmes embarqués et la question des tests est primordiale, si elle est négligée, le projet ne pourra jamais aboutir.

De plus, pour suivre le cycle en V des développements logiciels, il y a les tests unitaires, écrites par des développeurs qui permettent de valider les aspects bas niveaux et les tests systèmes qui valide le tout, sans pour autant re-tester ce qui a déjà été fait avec les tests unitaires.

Pour répondre à la question, le développeur NE PEUT PAS être montré du doigt en cas de bug, car son développement s'est inscrit dans un processus de développement dont seul le "responsable de lot logiciel" est responsable (d'ailleurs c'est bien son nom "responsable").

J'ai déjà eu le cas d'un chef de projet refusant de faire des tests unitaires, résultat : au bout de 2 ans, le projet a été interrompu, la société blacklisté chez le client et de très grosses indémnités à payer..... (merci au chef de projet).

De plus, le développeur est avant tout un humain et il a le droit à l'erreur, donc les tests unitaires doivent les mettre en évidence pour permettre de les corriger rapidement.

Citation:

---

Envoyé par martopioche

Mais ce n'est pas du tout ma question…*Je ne t'ai jamais demandé si tu peux livrer n'importe quand mais le 23 novembre !

---

Si je peux livrer n'importe quand je peux livrer le 23 novembre si tu veux. Je peux même livrer 8 fois dans la journée si tu veux. La question c'est de savoir quoi.

Citation:

---

Envoyé par martopioche

Et le scope est évidemment imposé…

---

C'est ça qui est absurde. L'équipe technique est le seul groupe capable de dire si c'est raisonnable de livrer un périmètre donné à une date donnée. Donc ça ne peut pas être imposé de l'extérieur.

Citation:

---

Envoyé par martopioche

Mais si tu connait ta vélocité, cela est certainement négocié et avec certainement pour conséquence de dégrader ta…*Tes métriques.

---

Négocié certainement mais qui a le pouvoir de décision ? Et qui est le seul à avoir un pouvoir de décision fondé sur des arguments rationnels ?

Citation:

---

Envoyé par martopioche

D'où ma question : En quoi éviter une hausse des couts dans la durée (quelle durée) a plus de conséquence que de ne pas mettre en prod' le 23 ?

---

Parce que si tu perds le pouvoir de livrer quand tu veux tu perds le pouvoir de livrer quand l'appli ne marche plus et qu'il faut régler un problème.

La question que tu poses c'est : Pourquoi est-ce que c'est plus grave de ne pas pouvoir livrer des correctifs plutôt que de ne pas livrer de nouvelles features ?

EDIT : Autre point, par hausse des couts j'entends baisse de la vélocité causée essentiellement par une peur chronique du refactoring. Si on a pas une bonne couverture de test, un code propre, une archi qui reste claire, cela devient de plus en plus de dur de refactorer l'appli, donc de fixer les bugs restants, donc d'ajouter des features, cela crée du risque donc du risque de bug, qui vont être de plus en plus dur à fix.

C'est un cercle vicieux. Comprendre ça nécessite de bonnes connaissances en génie logiciel, les chefs de projets et managers n'ont pas cette connaissances, seuls les (bons) techs l'ont.

La vélocité doit rester à peu près constante, et la team ne doit pas avoir peur de refactorer le code (que ce soit pour fixer des bugs ou ajouter des features), donc la qualité doit être le centre des préocupations.

Citation:

---

Envoyé par martopioche

Une date de livraison est rarement arbitraire…

---

Si on te dit tu livreras à telle date telle feature c'est quoi si c'est pas arbitraire ?

Citation:

---

Envoyé par martopioche

Et ? En quoi ce risque est plus important que de ne pas livrer le 23 ?

---

Déjà répondu. Je pensais pas qu'on arriverait à ce genre de questions sur un forum de dev mébon ... T'es manager c'est ça ?

Citation:

---

Envoyé par martopioche

Et pourtant, pour protéger la boite, il faut livrer le 23…

---

Ben tu fermes. Qu'est-ce que tu veux que je te dises, pour reprendre mon exemple précédent t'es entrain de me dire que si tu livres pas un banquet pour 100 personnes en 2h ton restau ferme, ben ferme !

Citation:

---

Envoyé par martopioche

C'est tout à fait idiot en effet car dans ce cadre, un cuistot connait…*sa vélocité…*Il sait quel délais, quel produits, quel matériel et quel personnel il lui faut pour assurer ce banquet et il peut donc produire pour le banquet.

---

Ah et des devs sont incapables de faire des estimations ? Il n'existe aucune technique ni méthodologie pour réduire le risque sur les estimations ?

Citation:

---

Envoyé par martopioche

Ce que toi tu me dis, c'est qu'on conviendra pour un banquet, mais tu livrera peut-être autre chose…*Tout ça pour ne pas dégrader ton matériel. Un cuistot lui, livrera ce qui est attendu, lorsque c'est attendu (c'est à dire avec les plats chauds même si les convives ont décidés de retarder le service…) et si le matériel doit être remplacé après la livraison, il le replacera…

---

Non si le contrat c'est de livrer le banquet dans 2h le cuistot ne livrera rien du tout.
Si le contrat c'est de livrer ce qu'on peut dans 2h le cuistot livrera ce qu'il peut.

Mais toi tu me dis que ton serveur a vendu le banquet pour dans 2h et qu'il faut s'y tenir parce que la survie du resto est en jeu. Moi ce que je te dis c'est que le vendeur n'a pas à vendre ça sans consulter le cuistot qui est le seul à pouvoir dire si c'est faisable ou non. Le droit de veto est donc bien dans les mains du cuistot et pas du vendeur.

Citation:

---

Envoyé par Marco46

Non si le contrat c'est de livrer le banquet dans 2h le cuistot ne livrera rien du tout.
Si le contrat c'est de livrer ce qu'on peut dans 2h le cuistot livrera ce qu'il peut.

Mais toi tu me dis que ton serveur a vendu le banquet pour dans 2h et qu'il faut s'y tenir parce que la survie du resto est en jeu. Moi ce que je te dis c'est que le vendeur n'a pas à vendre ça sans consulter le cuistot qui est le seul à pouvoir dire si c'est faisable ou non. Le droit de veto est donc bien dans les mains du cuistot et pas du vendeur.

---

C'est du bon sens, mais les commerciaux ou chefs de projet n'ont pas toujours ce bon sens... Et ça retombe sur le développeur dont on ne tient pas compte du véto.

@LSMetag

Ton post me fait penser que j'ai du repréciser une notion dans mon post ci-dessous. Sur le pourquoi c'est nécessaire de prioriser la qualité et sur le pourquoi ça ne peut être que le périmètre des techs.

Wouhou !!! Au bout d'une page, et 4 interventions, on a enfin la réponse, la seule partie d'intérêt de l'intervention précédente :

Citation:

---

Envoyé par Marco46

Ben tu fermes. Qu'est-ce que tu veux que je te dises

---

Tu a tout à fait expliqué pourquoi une boite ne doit absolument jamais demander son avis à un tech lead sur la pertinence d'une mise en prod', car ce dernier préférera que la boite coule et foutre tout le monde au chômage par préférence pour son caprice.

Citation:

---

T'es manager c'est ça ?

---

Nope, "indépendant". Guillemets parce que je ne suis pas presta.

Citation:

---

Envoyé par martopioche

Tu a tout à fait expliqué pourquoi une boite ne doit absolument jamais demander son avis à un tech lead sur la pertinence d'une mise en prod', car ce dernier préférera que la boite coule et foutre tout le monde au chômage par préférence pour son caprice.

---

Mais qu'est-ce que ça change de livrer un truc qui marche pas à l'heure et de fermer la boite derrière ou de fermer tout de suite ? Si t'en arrives à un stade où tu demandes des choses impossibles à tes techs sans tenir aucun compte de leur avis tu es au bord du dépôt de bilan.

Ou alors ta philosophie c'est d'escroquer les gens pour gagner ta vie c'est ça ?

C'est pas ma manière de voir les choses désolé.

Citation:

---

Envoyé par Marco46

Mais qu'est-ce que ça change de livrer un truc qui marche pas à l'heure et de fermer la boite derrière ou de fermer tout de suite ? Si t'en arrives à un stade où tu demandes des choses impossibles à tes techs sans tenir aucun compte de leur avis tu es au bord du dépôt de bilan.

Ou alors ta philosophie c'est d'escroquer les gens pour gagner ta vie c'est ça ?

C'est pas ma manière de voir les choses désolé.

---

Ça ne change rien en effet. Du coup en effet, je suis désolé je n’avais pas compris ton propos. Habituellement, lorsqu’on me parle de “maîtrise de sa vélocité et qualité de son code” et que l’on déclare être capable de “livrer n’importe quand”, j’ai tendance à comprendre une approche agile où on a en permanence quelque chose qui “marche” même si le produit n’est pas optimum. Pas l’ancienne approche de cycle en V où on s’inquiétera de savoir si ça fonctionne qu’à la fin des devs.

Et en effet, ma philosophie est très différente de la majorité des devs qu’on peut croiser. Mon objectif est la satisfaction de la demande etbesoin client, pas la satisfaction des chiffres de reporting de l’intégration continue.

Citation:

---

Ça ne change rien en effet. Du coup en effet, je suis désolé je n’avais pas compris ton propos. Habituellement, lorsqu’on me parle de “maîtrise de sa vélocité et qualité de son code” et que l’on déclare être capable de “livrer n’importe quand”, j’ai tendance à comprendre une approche agile où on a en permanence quelque chose qui “marche” même si le produit n’est pas optimum. Pas l’ancienne approche de cycle en V où on s’inquiétera de savoir si ça fonctionne qu’à la fin des devs.

---

C'est exactement de ça dont je parle. Tu ne peux pas faire de l'agile sans maitriser la qualité. Un des fondamentaux de l'agile c'est précisément d'avoir un scope variable. Du coup je ne comprends pas bien pourquoi tu mets ça sur la table puisque tu ne comprends pas les fondamentaux.

Citation:

---

Et en effet, ma philosophie est très différente de la majorité des devs qu’on peut croiser. Mon objectif est la satisfaction de la demande etbesoin client, pas la satisfaction des chiffres de reporting de l’intégration continue.

---

Satisfaire ton client c'est livrer du qui marche pas / qui marche mal à l'heure ? Tu confondrais pas un peu avec satisfaire les powerpoints de ton chef ?

Citation:

---

Envoyé par Marco46

(.../...)Satisfaire ton client c'est livrer du qui marche pas / qui marche mal à l'heure ? Tu confondrais pas un peu avec satisfaire les powerpoints de ton chef ?

---

Parfois, oui. Je sais que je ressors toujours le même exemple, mais l'hiver dernier, on a livré deux clients qui savaient qu'on était pas prêts. Particulièrement le second, qui a vu le massacre chez le premier(même si entretemps on avait corrigé 80% des problèmes). Parce-que sinon, leur subvention sautait.

C'est un cas super particulier quand même, mais ça peut se justifier pourquoi pas. On peut faire des exceptions de temps en temps, le problème c'est quand c'est la règle.

Citation:

---

Envoyé par Marco46

C'est un cas super particulier quand même, mais ça peut se justifier pourquoi pas. On peut faire des exceptions de temps en temps, le problème c'est quand c'est la règle.

---

"Super" cas particulier ? On dirait un jugement d'étudiant en plein dans l'idéalisme totalement ignorant du monde professionnel… Sérieux, j'aurai tendance à dire que c'est la norme, et que ce devrait être la norme…

Question : tu sait pourquoi tu bosse ? Je ne parle pas de pourquoi tu touche un salaire (pour livrer du code, ça on sait) mais pourquoi on te paye pour ça (si tu est effectivement professionnel du domaine, sinon considère "pourquoi un développeur est payé pour livrer du code") ? Durant tes échanges avec moi, on dirait que le seul destinataire de ton code est un "chef" qui a choisis de financer la production d'un "code" en demandant des features improbable à des dates irréalistes…*Peut-être est-tu dans un contexte où sur la base du mécénat on te demande du code à exposer tel quel avec ses graphiques de "qualité" sur les murs des bureaux des managers. Mais en ce qui me concerne, en presque 20 ans de carrière, tous mes développements ont eu ce que l'on appelle des "utilisateurs" pour qui le logiciel est un outil (lui même ou sous forme de service). Si ces "utilisateurs" attendent ma livraison, c'est pour pouvoir travailler ou rendre le service. Et régulièrement, les dates définies répondent à des contraintes. Là aussi, sérieusement (et honnêtement, sans m'étonner…), j'ai insisté à chaque exemple sur une date, le 23. Aucun "développeur" qui m'a opposé ses sacro-saints principes ne s'est posé la question de "pourquoi"…*Vous assumez tous une lubie de la hiérarchie…*Sauf que le 23, c'est la veille du 24. Vendredi 24, soit le Black Friday…*Tu a posé ton véto pour la livraison du 23 ? Ok, c'est pas en ligne le 24, les offres spéciales, les dialogues dédiés ne sont pas en ligne, les clients sont moins intéressés que nos concurrents et en conséquence…*On s'assoit sur 30 % du chiffre annuel… Tiens, 30 % en variable, ça aussi n'était pas au hasard…

Des contraintes comme ça, une entreprise en a en permanence : dates attendues, actualité, contraintes réglementaires ou simplement…*Concurrence… Il faudrait peut être commencer à finir de se la jouer princesse et comprendre que si on te demande un produit, ce n'est pas pour la beauté du code mais pour la fonctionnalité d'un produit. Et de sa durée de vie. Tes arguments sur la maintenance et les évolutions sont passionnants, mais pour un service lié à un évènement, une fois l'évènement passé, le code va à la poubelle…*Donc les possibilités d'évolution…

De ce fait…

Citation:

---

C'est exactement de ça dont je parle. Tu ne peux pas faire de l'agile sans maitriser la qualité. Un des fondamentaux de l'agile c'est précisément d'avoir un scope variable. Du coup je ne comprends pas bien pourquoi tu mets ça sur la table puisque tu ne comprends pas les fondamentaux.

---

… Oui, les fondamentaux…*Les fondamentaux sont que si tu me parle de qualité, la qualité est la finalité de ta démarche. La qualité n'est pas là pour assurer tes process. L'agilité est un des process que tu met en place pour assurer la qualité, non l'inverse…

Citation:

---

Envoyé par martopioche

j'ai insisté à chaque exemple sur une date, le 23. Aucun "développeur" qui m'a opposé ses sacro-saints principes ne s'est posé la question de "pourquoi"…*Vous assumez tous une lubie de la hiérarchie…

---

A aucun moment tu ne poses la question de savoir à quel moment l'équipe de développement rentre dans la boucle de décision. Si ta date du 23 est prévue 6 mois à l'avance il y a de grandes chances qu'il n'y ait aucun problème. Si ta date tombe 3 jours avant, ça risque de coincer.

Je vais reprendre mon analogie du restaurant (qui vaut ce qu'elle vaut), si un client commande une omelette norvégienne pour dans 5 minutes, et que rien n'a été anticipé, le chef peut avoir toute l'expérience qu'il veut, si le serveur valide la commande il y a un énorme problème de faisabilité. C'est de ça que je parle.

Toi tu ne prends aucun recul sur la démarche générale. On te dit c'est telle feature à telle date et amen. Et bien non. Non ça ne doit pas marcher comme cela parce que cela marche très mal comme cela. Un projet qui termine à la date voulue avec le scope voulu dans les faits c'est l'exception et pas la règle. Les ordres de grandeurs c'est 1/4 qui réussit à date et scope, 1/2 qui dérape mais qui finit tout de même, et le dernier quart qui est abandonné.

Alors je veux bien que tu sois absolument exceptionnel et que toi tu livres dans 100% des cas le scope à date mais sache que tu es véritablement l'élu, une sorte de messie qui s'ignore pour toutes les DSI du monde, et que tu ne devrais pas perdre ton temps à polémiquer sur dev.com.

Citation:

---

Envoyé par martopioche

… Oui, les fondamentaux…*Les fondamentaux sont que si tu me parle de qualité, la qualité est la finalité de ta démarche. La qualité n'est pas là pour assurer tes process. L'agilité est un des process que tu met en place pour assurer la qualité, non l'inverse…

---

Si si c'est l'inverse. C'est la qualité qui active la possibilité de devenir agile, enfin c'est un des critères ce n'est pas le seul mais il est nécessaire. C'est ce qu'un grand nombre de managers et d'escrocs en développement ignorent (sciemment ou la plupart du temps par ignorance). Tu ne sais manifestement pas du tout de quoi tu parles. Cette conversation est inutile tu as trop de carences sur ces notions.

Je ne peux que "plussoyer" Marco46

Citation:

---

Envoyé par martopioche

"Super" cas particulier ? On dirait un jugement d'étudiant en plein dans l'idéalisme totalement ignorant du monde professionnel… Sérieux, j'aurai tendance à dire que c'est la norme, et que ce devrait être la norme…

Question : tu sait pourquoi tu bosse ? Je ne parle pas de pourquoi tu touche un salaire (pour livrer du code, ça on sait) mais pourquoi on te paye pour ça (si tu est effectivement professionnel du domaine, sinon considère "pourquoi un développeur est payé pour livrer du code") ? Durant tes échanges avec moi, on dirait que le seul destinataire de ton code est un "chef" qui a choisis de financer la production d'un "code" en demandant des features improbable à des dates irréalistes…*Peut-être est-tu dans un contexte où sur la base du mécénat on te demande du code à exposer tel quel avec ses graphiques de "qualité" sur les murs des bureaux des managers. Mais en ce qui me concerne, en presque 20 ans de carrière, tous mes développements ont eu ce que l'on appelle des "utilisateurs" pour qui le logiciel est un outil (lui même ou sous forme de service). Si ces "utilisateurs" attendent ma livraison, c'est pour pouvoir travailler ou rendre le service. Et régulièrement, les dates définies répondent à des contraintes. Là aussi, sérieusement (et honnêtement, sans m'étonner…), j'ai insisté à chaque exemple sur une date, le 23. Aucun "développeur" qui m'a opposé ses sacro-saints principes ne s'est posé la question de "pourquoi"…*Vous assumez tous une lubie de la hiérarchie…*Sauf que le 23, c'est la veille du 24. Vendredi 24, soit le Black Friday…*Tu a posé ton véto pour la livraison du 23 ? Ok, c'est pas en ligne le 24, les offres spéciales, les dialogues dédiés ne sont pas en ligne, les clients sont moins intéressés que nos concurrents et en conséquence…*On s'assoit sur 30 % du chiffre annuel… Tiens, 30 % en variable, ça aussi n'était pas au hasard…

Des contraintes comme ça, une entreprise en a en permanence : dates attendues, actualité, contraintes réglementaires ou simplement…*Concurrence… Il faudrait peut être commencer à finir de se la jouer princesse et comprendre que si on te demande un produit, ce n'est pas pour la beauté du code mais pour la fonctionnalité d'un produit. Et de sa durée de vie. Tes arguments sur la maintenance et les évolutions sont passionnants, mais pour un service lié à un évènement, une fois l'évènement passé, le code va à la poubelle…*Donc les possibilités d'évolution…

---

Si c'est si important de livrer le 23 (30% du chiffre annuel, c'est pas rien), pourquoi ne pas s'y prendre plus tôt et se donner les marges nécessaires pour ne pas livrer un truc bancale ? Sinon ton Black Friday c'est mort en plus de la réputation de ta boîte.

Si l'équipe de dev n'est pas consultée, alors tout ne tient qu'aux merveilleuses compétences du pilotage, ces gens qui savent toujours tout mieux que tout le monde et surtout ce qu'ils veulent tel un gosse qui fait un caprice de dernière minute, plutôt que connaître les bases de comment sont faites les choses qu'ils vendent afin d'anticiper / maîtriser ?

Noël c'est dans un peu plus d'un mois et je viens d'avoir l'idée lumineuse de faire un bébé pour cette période merveilleuse afin de cumuler les fêtes en cette fin d'année. Ben tu me crois tu me crois pas, ma copine n'est pas contre mais m'a dit que ce ne sera pas possible... Elle ne me comprendra jamais de toute façon..

Citation:

---

Envoyé par Marco46

A aucun moment tu ne poses la question de savoir à quel moment l'équipe de développement rentre dans la boucle de décision.

---

Faux, ne serait-ce que post #104…

Citation:

---

Si ta date du 23 est prévue 6 mois à l'avance il y a de grandes chances qu'il n'y ait aucun problème.

---

Je ne parle pas de chance, si c'est la chance qui m'intéresse, le Tac-o-tac est plus adapté. Tu a déclaré que le dev devrait avoir droit de véto sur une livraison, moi je demandais juste si en échange de ce droit tu est prêt à participer à la conséquence financière en ayant 1/3 de ton salaire sur objectif de livraisons.

Citation:

---

Alors je veux bien que tu sois absolument exceptionnel et que toi tu livres dans 100% des cas le scope à date mais sache que tu es véritablement l'élu, une sorte de messie qui s'ignore pour toutes les DSI du monde, et que tu ne devrais pas perdre ton temps à polémiquer sur dev.com.

---

1 - peux-tu citer où j'ai déclaré ça ?
2 - en effet :

Citation:

---

Si si c'est l'inverse. C'est la qualité qui active la possibilité de devenir agile, enfin c'est un des critères ce n'est pas le seul mais il est nécessaire. C'est ce qu'un grand nombre de managers et d'escrocs en développement ignorent (sciemment ou la plupart du temps par ignorance). Tu ne sais manifestement pas du tout de quoi tu parles. Cette conversation est inutile tu as trop de carences sur ces notions.

---

Bien sûr…*Bah oui, c'est vrai, j'ignore de quoi je parle…*Ceux qui font l'ISO, ITIL et autres normes de qualité non plus, punaise, il suffit de demander sur Developpez…

Citation:

---

Envoyé par mister3957

Si c'est si important de livrer le 23 (30% du chiffre annuel, c'est pas rien), pourquoi ne pas s'y prendre plus tôt et se donner les marges nécessaires pour ne pas livrer un truc bancale ? Sinon ton Black Friday c'est mort en plus de la réputation de ta boîte.

---

1 - plus tôt que quoi ? Où a-t-il été question de délais ?
2 - en fait, les délais sont régulièrement un peu serrés ne serait-ce que parce que les devs sont toujours sur quelque choses. Mais surtout, les opérations saisonnières peuvent difficilement être planifiées très longtemps à l'avance. Je prends un exemple actuel (pas Black Friday) : cette année, il y a la sortie du Star Wars pour décembre. Si je suis un webmarchand, je ne connais la majorité des produits que pour le Force Friday (mi-septembre). Ce n'est qu'à ce moment que les équipes marketing peuvent juger quoi mettre en avant et comment si je veux une application promotionnelle. Et il n'y a pas que le saisonnier. À moins d'être dans une niche où vous êtes la seule boite du secteur, la concurrence donne aussi le ton. Certaines évolutions doivent être suivies très vite sinon, le concurrent risque de prendre une avance qui sera impossible à rattraper.
3 - Livrer un truc bancal ou non, ça dépends justement de l'équipe de dev…*Si l'équipe est compétente, elle sait mettre des priorités (livrer ! ). Elle sait aussi que toutes les features n'ont pas à être livrées le jour J. Si pour gérer les retours d'un webmarchand, tu ne peux pas livrer le 23 car tu a besoin du 24 pour finaliser, voir du 27 et que c'est finalisé pour une mise en prod' le 28 ou 29 bah… les clients ne seront pas livrés avant… Et puis "bancal"…*Définit "bancal"…*Si par bancal c'est non fonctionnel, change de métier. Si par "bancal", ça ne réponds pas métriques des devs, c'est important ? Tout ce qu'on m'a répondu par cette pseudo-qualité du code, c'est l'assurance des évolutions. Si cette assurance n'est pas là le jour de la mise en prod', une équipe de dev compétente la mettra en place par la suite. Et enfin, pour du saisonnier, en fait, vu que le code sert pour du one-shot, on s'en fiche…

Citation:

---

Si l'équipe de dev n'est pas consultée

---

Sauf que j'ai même émis l'hypothèse d'une consultation des devs…*

Citation:

---

alors tout ne tient qu'aux merveilleuses compétences du pilotage, ces gens qui savent toujours tout mieux que tout le monde et surtout ce qu'ils veulent tel un gosse qui fait un caprice de dernière minute, plutôt que connaître les bases de comment sont faites les choses qu'ils vendent afin d'anticiper / maîtriser ?

---

Sauf que ceux-là, en général, ils savent comment générer les revenus de la boite qui permet de payer les salaires… Les devs eux ont leurs caprices de Rock-Stars, mais n'ont aucune idée de cet aspect (très bien illustré sur ce fil…). D'ailleurs, l'Utopie des devs l'a bien montré aussi. Par utopie des devs, je pense aux places de marché mobile. Tu peux retrouver par exemple les talks du 3ème anniversaire du Paris-JUG. Pour un intervenant, c'était l'opportunité de laisser les devs proposer directement aux utilisateurs leurs créations géniales sans CDP, market, commerciaux qui n'y connaissent rien…

Même un an après, les devs qui ont pu vraiment vivre de leur boite en suivant ce schéma se comptent sur les doigts de la main…

Ah, et évidemment, il n'y a pas que les éditeurs… Souvent, on peut baver sur les commerciaux des SSIIs qui ne pensent qu'à leur chiffre… Oui, mais si ils consultent les devs qui vont leur répondre qu'il faudrait voir avec le client pour augmenter le délais… Ben le client aura tout vu et ira avec le concurrent.

Sérieux, si vous êtes dans ce cas, poser votre dem' et passez freelance. Vous pourrez le dire directement à vos clients… Sauf que vous ne serez rémunéré que sur votre activité…

Citation:

---

Noël c'est dans un peu plus d'un mois et je viens d'avoir l'idée lumineuse de faire un bébé pour cette période merveilleuse afin de cumuler les fêtes en cette fin d'année. Ben tu me crois tu me crois pas, ma copine n'est pas contre mais m'a dit que ce ne sera pas possible... Elle ne me comprendra jamais de toute façon..

---

Quitte la et trouve en une qui soit d'accord. Je suis persuadé que tu en trouvera en échange d'ajouter aussi un mariage. En communauté de biens…

Par contre, si un jour c'est elle qui te demande, si tu lui réponds que tu a besoin des détails techniques en lui expliquant comment sont faites les choses et ok pour dans 2/3 ans, t'étonne pas de te retrouver tout seul…