Discussion :

[Marco46]

Je répondais en ce sens, pour moi il n'y a pas foncièrement de différences entre un délai et une deadline. Au final c'est une date à laquelle il faut livrer la version finale...
Qu'on dise il me faut le logiciel pour le 24 décembre ou bien il me faut le logiciel dans un mois cela revient au même.

Seulement si on te le dit le 24 novembre. Si on te le dit le 24 octobre ou le 12 décembre c'est pas la même tisane. Je sais même pourquoi je prends la peine de répondre à une telle remarque

Et même s'il n'en donne pas réellement il y en a une qui s'appelle la mise en concurrence, si vous êtes moins rapide dans la réalisation qu'une autre entreprise alors vous ne décrocherez pas l'appel d'offre.
En gros c'est une deadline/délai fixée par le marché.

Non il y a bien heureusement beaucoup d'autres critères. Cela dépend de l'appel d'offre.

[transgohan]

Seulement si on te le dit le 24 novembre. Si on te le dit le 24 octobre ou le 12 décembre c'est pas la même tisane. Je sais même pourquoi je prends la peine de répondre à une telle remarque .

C'est une... évidence...
Mais si tu aimes autant jouer avec les mots alors je te laisse imaginer/deviner/inventer ma réponse suivante...
Comme cela ça m'évitera de la poster et qu'on continue de me prendre pour un abruti alors que ce n'est pas moi ici qui manque de logique...

[martopioche]

Ok on va reformuler parce que ça part dans tous les sens et on ne comprend plus rien.

Ben tu sais, pour ne pas que ça parte dans tous les sens, il suffit de ne pas reformuler dans le seul but de partir sur un autre sujet.

C'est intéressant d'ailleurs, tu semble être tout à fait le prestataire décrit par petitours : reformuler les demandes pour proposer une réponse qui n'a aucun rapport avec le besoin exprimé… Et après tu reproche aux tiers de ne pas demander l'avis aux devs…

Notes bien que ça ne veut pas dire que le donneur d'ordre ne peut pas ajouter une contrainte de délai dans son EDB pour des raisons business. Ça ne pose aucun problème tant que ça reste de l'EDB. C'est même parfaitement logique. Mais c'est à l'équipe technique de dire si c'est faisable ou pas. C'est ce que j'appelle le droit de veto.

Sauf qu'il y a 2 pages, ce "droit de véto" concernait la livraison…

[martopioche]

Dans la grande majorité des cas c'est toujours le donneur d'ordre qui fixe les délais, et bien souvent de façon qui handicape les équipes techniques.
Il a généralement trois façons de faire :
1 - la pire : il la fixe unilatéralement
2 - au milieu : il fait des moyennes et des projections du projet courant par rapport à des projets déjà livrés
3 - la mieux : il récupère les devis des différentes équipes techniques pour calculer le délai

Heu…*Le 3, je ne vois pas en quoi c'est le "donneur d'ordre" qui a fixé le délais si il prend celui donné par les équipes techniques…
Pour le 2, je ne comprends pas le reproche… Si se baser sur les projets similaires pour évaluer un délais, comment l'équipe technique évaluera-t-elle elle même le délais nécessaire ?

Et de manière générale, en quoi est-ce étonnant que le "donneur d'ordre" fixe un délais ? C'est bien lui qui qui connait les contraintes business, non ?

Voilà, si on veut survivre, il faut livrer.

Mais…*C'est le principe de toute entreprise commerciale…*Si ce n'est pas avec des clients institutionnels, le marché déterminera lui-même la survie de l'entreprise. Essayez de vous lancer dans le marché du sapin et puis, acceptez que finalement, pour des contraintes techniques, vous ne les mettrez en rayon qu'en janvier…

euh, si je puis me permettre en ma qualité de client, le délai est forcément fixé par le fournisseur sur la base d'une éventuelle EDB de ma part (le client)
Moi client, ça me va (et je vais être super furax si après ce n'est pas tenu !) ou alors je vais soit
1) voir ce qui dans mon EDB peut expliquer le délai qui ne me va pas et si le fournisseur et bon il saura me proposer une adaptation ou une action en 2 étapes qui me permettra de tenir mon délai sur le point qui est important pour moi. Ce sera pareil pour le budget et cette capacité à construire le compromis qui va bien en fonction du contexte technico économique sera pour moi un important critère de bon ou mauvais fournisseur.
2) voir autre part si un autre n'a pas plus de capacité ou plus de "déjà fait" dans le domaine pour répondre plus rapidement. option que je n'aime pas parce que je suis fidèle et parce que ça a très peu de chance d'être possible au regard du temps perdu en consultation.

Oui enfin, la fidélité vis à vis d'un fournisseur qui ne respecte pas les clauses contractuelles…

Quand au fait "si le fournisseur est bon", ce genre de fournisseur sait accepter les risques et dans ce cas par exemple accepter des clauses de pénalité de retard… Tout bon fournisseur dans l'industrie sait prendre ces engagements. Tout bon fournisseur sauf dans l'IT…

de toute manière comme personne n'est tenu à l'impossible il aura une bouse à temps ou un truc bien pas dans les temps (en fonction du budget), un échec dans tous les cas.
Après coté fournisseur la situation est binaire ; soit il a accepté les conditions de l'acheteur et comme tout contrat c'est le dernier qui cause qui a raison et il se fera taper dessus par le client détestable bien qu'il avait raison. Soit il dit au client "ben j'ai fait de mon mieux mais je vous avez prévenu..."

Heu… Non, enfin, normalement, non…*Les relations qui unissent un client et un fournisseur ne sont pas des dictons mais des relations contractuelles. Si une date est convenue, le fournisseur s'engage à la respecter ou sur les conséquences du non respect, il n'y a pas de "j'ai fait de mon mieux"… Parce qu'autant il y a des clients détestables comme tu les décrit, autant il y a des fournisseurs tout aussi détestables qui s'engagent sur des demandes irréalistes en jouant sur la relation de dépendance. Les développeurs ont plaisir à cracher sur ceux qui leurs donnent du boulot, mais ils oublient que pendant qu'on leur demande une réalisation, à coté, il y a une équipe juridique qui analyse le contrat pour voir tout ce qu'il est possible de ne pas faire si possible en rendant le produit inutilisable (mais correspondant à la demande) et vendre de l'avenant…

Le bon fournisseur sera celui qui sait proposer le meilleur compromis pour atteindre l’objectif (si compromis est nécessaire et qui sera ensuite capable de tenir ses engagements sans faille

Tout à fait, en théorie. Mais la description de la situation de tes clients n'est pas très prometteuse sur l'existence de tels clients…*

Mais j'ose espérer qu'en informatique c'est pareil, que tous les projets ne sont pas dans cette logique d'acheteur minable (ou pire encore de consultations publiques ?)

Dans le public, si, beaucoup…*Mais avec le défaut que les demandeurs sont complètement déconnectés du réel besoin et n'ont aucune idée de l'usage. Le pire étant quand les demandeurs ne sont pas les utilisateurs finaux qui eux n'ont rien demandé (m'est arrivé, projet piloté par un ministère et en région, personne qui veut uniformiser…).

[martopioche]

Je répondais en ce sens, pour moi il n'y a pas foncièrement de différences entre un délai et une deadline. Au final c'est une date à laquelle il faut livrer la version finale...
Qu'on dise il me faut le logiciel pour le 24 décembre ou bien il me faut le logiciel dans un mois cela revient au même.

Délai et deadline sont pourtant très différents. Un délai, c'est une durée, une deadline, c'est un instant. Ça devient la même chose uniquement lorsque on accompagne le délai d'une date de début. "il me faut le logiciel dans un mois" ne fixe pas un délai mais une deadline (dans un mois à partir de maintenant). Lorsqu'en tant que presta dans une proposition je précise un délai, aucune deadline n'est définie tant que le contrat n'a pas commencé.
De toutes manières, une deadline provient du demandeur et le délai provient du fournisseur.

Et même s'il n'en donne pas réellement il y en a une qui s'appelle la mise en concurrence, si vous êtes moins rapide dans la réalisation qu'une autre entreprise alors vous ne décrocherez pas l'appel d'offre.

Je ne suis pas certain qu'un délai plus long soit réellement discriminant. Il l'est si il entraine un cout plus long, dans ce cas, ce n'est pas vraiment le délai mais le cout.

[Marco46]

Sauf qu'il y a 2 pages, ce "droit de véto" concernait la livraison…

Le périmètre de la livraison. Tu dois être en mesure de livrer n'importe quand, la question c'est quoi.

Si tu ne comprends pas ça tu ne comprends rien à ces problématiques.

[Marco46]

Mais…*C'est le principe de toute entreprise commerciale…*Si ce n'est pas avec des clients institutionnels, le marché déterminera lui-même la survie de l'entreprise. Essayez de vous lancer dans le marché du sapin et puis, acceptez que finalement, pour des contraintes techniques, vous ne les mettrez en rayon qu'en janvier…

A ce stade c'est que ton business n'est tout simplement pas viable, il est donc normal que l'entreprise meure. Aucune pression sur les techniciens ne changera ça.

[martopioche]

Le périmètre de la livraison.

Ben non… :

Et je maintiens que oui les techs devraient pouvoir poser un veto sur une livraison.

[martopioche]

Aucune pression sur les techniciens ne changera ça.

Quand les techniciens sont payés à la présence, en effet, jamais.

[transgohan]

Heu…*Le 3, je ne vois pas en quoi c'est le "donneur d'ordre" qui a fixé le délais si il prend celui donné par les équipes techniques…
Pour le 2, je ne comprends pas le reproche… Si se baser sur les projets similaires pour évaluer un délais, comment l'équipe technique évaluera-t-elle elle même le délais nécessaire ?

Et de manière générale, en quoi est-ce étonnant que le "donneur d'ordre" fixe un délais ? C'est bien lui qui qui connait les contraintes business, non ?

Bah on dit la même chose, c'est justement ce que je tente d'expliquer à Marco.

Pour le 3 c'est dans le cas où tu as x équipes qui font leur truc qui est à intégrer dans le système final.
Tu vas avoir plusieurs devis et c'est au donneur d'ordre d'assembler tout cela pour définir le délai global de livraison du système.

Sinon ce ne sont en aucun cas des reproches, ce sont des façons de faire.

[Marco46]

Tu sors la phrase du contexte gros malin. La notion de périmètre est implicite dans ma phrase.

[martopioche]

Pour le 3 c'est dans le cas où tu as x équipes qui font leur truc qui est à intégrer dans le système final.
Tu vas avoir plusieurs devis et c'est au donneur d'ordre d'assembler tout cela pour définir le délai global de livraison du système.

Je n'avais pas compris ça. J'avais compris le retour de plusieurs réponses au même appel d'offre à partir desquels le "donneur d'ordre" aurai déterminé une "moyenne".

Dans ton cas, c'est évident, le "donneur d'ordre" est le seul à pouvoir coordonner l'intégration et donc déterminer le délais global. Mais dans ce cas, le respect des délais est plus qu'important si des équipes dépendent d'un livrable.

Sinon ce ne sont en aucun cas des reproches, ce sont des façons de faire.

Ok, le sens n'est pas toujours évident sur un forum

[martopioche]

Tu sors la phrase du contexte gros malin. La notion de périmètre est implicite dans ma phrase.

Le contexte global, c'est ça :

Et je maintiens que oui les techs devraient pouvoir poser un veto sur une livraison.

"Et" car juste avant, le sujet était autre chose.

Après, bon, tu a bien raison, quand on fait référence à de "l'implicite" pour se dédouaner des affirmations et que l'on évite de citer ce qui dit avant, c'est bien la base de la justification du charlatan de base. Là je dois te donner raison : le métier est plein de gens comme ça.

[Marco46]

Quand tu as une pipeline CI/CD, c'est à dire quand tu travailles correctement, tu peux déployer n'importe quand. Le veto porte donc forcément sur le périmètre. C'est implicite parce que ça ne peut être que ça. Tu le saurais si tu ne travaillais pas comme dans les années 80.

[martopioche]

Quand tu as une pipeline CI/CD, c'est à dire quand tu travailles correctement

Voilà la parfaite illustration de pourquoi les développeurs passeront toujours pour des charlots. Par "C'est à dire" je présume que tu souhaitais rappeler un caractère…*implicite ? Sauf il n'y a aucun rapport entre "avoir un pipeline CI/CD" et "travailler correctement"… "Avoir un pipeline CI/CD" n'implique pas de "travailler correctement" et "travailler correctement" n'implique pas "avoir un pipeline CI/CD". Parler de "pipeline" et se sentir la nécessiter d'avoir une "IC" ou un "DC" que l'on appelle "CI" et "CD" est par contre indispensable dans la bullshitologie du Consultant de base.

Et merci pour le pic :

Tu le saurais si tu ne travaillais pas comme dans les années 80.

Là non plus, en soi je ne vois pas non plus le rapport…*Ah si, tu a dû lire quelque part le taux d'échec des projets des années 80, la révolution des méthodes "modernes": agilité, sprints, IC/AC/DC et tu est persuadé qu'en appliquant des rituels relatifs à ces concepts, tu "bosse correctement"… C'est bien, tant qu'on n'a aucune métrique qualité, on peut s'en satisfaire.

Quand tu as une pipeline CI/CD, tu peux déployer n'importe quand. Le veto porte donc forcément sur le périmètre. C'est implicite parce que ça ne peut être que ça. Tu le saurais si tu ne travaillais pas comme dans les années 80.

On ne peux savoir ça que lorsqu'on est un développeur autiste. Aucun développeur qui a le minimum de considération produit et de ses utilisateurs ne "saurait" avoir cette vision. Ça n'intéresse personne que tu soit capable de ne rien livrer en déployant n'importe quand. Tu le saurais si tu travaillais correctement…

Merci par contre, j'ai bien ma réponse pourquoi on n'implique jamais un développeur dans le process produit…

[Matthieu Vergne]

J'ai pris du retard sur ma lecture de posts, donc je réveille des vieux sujets. {^_^}

Mon avis : un test vise à s'assurer qu'un besoin est satisfait. Qu'il soit un besoin fonctionnel, de sécurité, ou que sais-je, un test sert à dire si oui ou non "ça, c'est fait". En ce sens, un bon testeur est quelqu'un qui comprend au mieux ledit besoin et est capable d'établir une procédure de test pour le vérifier. Automatique ou non.

Aujourd'hui, ça passe généralement par de la programmation, car on souhaite automatiser au maximum ces tests, mais ce n'est pas forcément le cas. Ajoutons à cela le fait que des besoins techniques, comme des besoins de sécurité, impliquent d'avoir de bonnes connaissances sur le code. C'est pourquoi il est généralement préférable d'être bon programmeur pour être bon testeur, d'où l'amalgame, mais ce n'est que ça : un amalgame. On pourra toujours savoir coder, si on ne comprends pas bien le besoin, on ne testera pas ce qu'il faut. Si on comprends bien le besoin mais ne sait pas coder, on pourra souvent le tester autrement, même si moins efficacement. Un bon testeur reste quelqu'un capable d'établir une procédure de test pertinente et efficiente, et c'est ensuite sa conscience professionnelle qui le pousse à acquérir des compétences en programmation si cela lui permet d'être plus efficace dans son travail de test.

Une fois que ça c'est clair, en fonction de la situation, un programmeur sera plus à même de prendre le job de testeur : parce qu'il est compétent (voire parce qu'il teste même sans le lui demander), parce que ça suffit, parce qu'on n'a pas les fonds pour faire mieux, etc.

Pour ce qui me concerne, je teste ce que je trouve pertinent en essayant toujours de l'automatiser d'une manière ou d'une autre. Et si d'autres personnes testent mon code autrement, ce n'est pas moi qui leur lancerait la pierre. En revanche, quand on me dit "ces tests là, c'est telle autre personne qui s'en occupe, donc toi tu fais pas", et que je vois ensuite que cette tâche de test est annulée (ou retardée pour après la démo) et que je découvre à la dernière minute un bogue critique qui aurait pu être détecté par ces tests... là on m'entend.