Discussion :

[souviron34]

C'est le côté 'Je suis développeur et j'ai plein d'étoiles dans les yeux'
...
Donc le côté artisanal cela fait rêver, faire du beau code c'est cool, implémenter telle ou telle technologie c'est intéressant.

Comme dit moldavi :

Je pense comprendre ce que tu dis, et je pense que l'on ne parle pas de la même chose entre artisanal et industriel.

Je ne parlais pas de projets de 4 à 6 mois avec 1 à 6 devs, mais de projets de 5 à 10 ans avec 50-150 (ou plus) devs.... des projets de plusieurs millions de lignes et de plusieurs millions ou dizaines de millions de budget....


Ce que je disais c'est que les étapes/documentations/découpages de responsabilités etc, (dont le Cahier des Charges) sont basés sur une vision taylorienne du travail copiée sur le fonctionnement d'une chaîne d'usine (le côté "indusriel") : mini-découpage de pièces "élémentaires", "répétitivité", linéarité du processus, grand nombre d'"ouvriers", mais chacun à sa place, et "remplaçables", vision du produit fini en bout de chaîne..

A l'inverse, ce que toute cette vision n'a jamais compris, c'est que la fabrication d'un logiciel n'est pas la chaîne de montage, mais le bureau d'étude.

La chaîne de montage d'une usine veut reproduire à l'identique et de manière identique le prototype établi par le bureau d'études.

En informatique, la reproduction à l'dentique est instantanée... C'est la production du prototype qui est le coeur du métier..

Et, comme pour un bureau d'études, c'est un processus complexe, absolument non linéaire, reposant sur des personnalités, et où chaque individu est "irremplaçable" (on ne va embaucher un débutant pour trouver la meilleure combustion, le meilleur aérodynamisme, les meilleurs emplacements pour les cables ou les boulons, etc etc)

C'est pour ça que le bureau d'études est une petite équipe de gens doués, et que l'analogie prise avec la chaîne de montage pour l'informatique est absurde.....

Je ne suis pas d'accord avec toi, le client est roi, il paye, par conséquent il peut exercer un chantage au prestataire. C'est aussi une des raisons pourquoi il y a tant de SSII, parce que les décideurs ... mauvais n'arrivent pas à leur fin avec leurs salariés, alors ils font appel à la sous traitance qui est obligé d'aller dans le discours du décideur, ce qui amène à une forme de prostitution pour utiliser le bon terme.

D'autre part les SSII font pour certaines des contrats en béton pour se protéger contre les changements d'avis des décideurs.

Il y a des tas de clients de mauvaise foi, mais il se peut également que le CP soit chez le client.

Je ne veux pas faire de généralité, hein, je me fais l'avocat du diable.

Je te répondrais que :

1) ta vision est là-aussi biaisée, puisque tu bases ton argumentation sur le phénomène SSII, principalement valable en France, et de toutes façons hors du sujet du débat

2) Encore une fois, que le client change d'avis en cours de route, c'est tout simplement parce que AVANT d'accepter et/ou LORS de l'établissement du Cahier des Charges l'interlocuteur (qu'il soit CP, commercial, MOA, MOE, ou ce qu'on veut) n'a pas assez posé de questions et fouillé...


Je réitère que le client a zéro faute (à part vraiment les mauvaises fois, mais elles sont très rares).


Si je prend ton argument des SSII, il est souvent - plus la SSII est grosse plus c'est vrai - plus intéressant que le client "se trompe", c'est à dire qu'on ne mettte pas les choses au clair tout de suite, car on lui fera payer les modifs ultérieures...

La raison d'un mauvais Cahier des Charges oscille donc entre incompétence ou volonté délibérée des intervenants côté fournisseur ...

[chaplin]

Comme dit moldavi :
Je te répondrais que :

1) ta vision est là-aussi biaisée, puisque tu bases ton argumentation sur le phénomène SSII, principalement valable en France, et de toutes façons hors du sujet du débat

- Tu as mis la faute au CP, mais pas au client. Si le CP est chez le client, qui est responsable, le client ou le CP. Je vais prendre un exemple non informatique. Il y a eu un déraillement en France, qui est fautif, la SNCF ou le service qui n'a pas pris en compte le signalement d'un aiguillage défecteux par manque de budget. Idem pour Fushima et TEPCO, etc.

2) Encore une fois, que le client change d'avis en cours de route, c'est tout simplement parce que AVANT d'accepter et/ou LORS de l'établissement du Cahier des Charges l'interlocuteur (qu'il soit CP, commercial, MOA, MOE, ou ce qu'on veut) n'a pas assez posé de questions et fouillé...

-, après un CDC n'est pas une prédiction, c'est une estimation par rapport aux connaissances des auditeurs (CP, développeurs, utilisateurs).

Je réitère que le client a zéro faute (à part vraiment les mauvaises fois, mais elles sont très rares).

- J'ai connu deux responsables informatiques de mauvaises fois, et les CP que j'ai rencontrés étaient bon, je ne leur jettent pas la pière, leur métier les oblige à se protéger et de mentir parce qu'ils sont entre le marteau et l'enclume.

Si je prend ton argument des SSII, il est souvent - plus la SSII est grosse plus c'est vrai - plus intéressant que le client "se trompe", c'est à dire qu'on ne mettte pas les choses au clair tout de suite, car on lui fera payer les modifs ultérieures...

- J'aurais pu prendre l'argument des experts, encore une fois je ne fais pas de généralité, il y a des bons et des mauvais comme en politique.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

La raison d'un mauvais Cahier des Charges oscille donc entre incompétence ou volonté délibérée des intervenants côté fournisseur ... :D

- C'est le manque de temps, même un bon CP peut se tromper par manque de temps voir il a fait confiance à son équipe (... qui ne l'aime pas)

J'ai cherché un contre exemple à ton argumentation

[el_slapper]

(.../...)

C'est pour ça que le bureau d'études est une petite équipe de gens doués, et que l'analogie prise avec la chaîne de montage pour l'informatique est absurde.....

Il y a même de la littérature qui explique pourquoi. Plus exactement, si on ne sait pas(hélas) démontrer formellement que l'analogie bureau d'études - développement de projet - est exacte, on peut en revanche démontrer que se servir de cette analogie améliore la probabilité de succès du projet.

(.../...)

2) Encore une fois, que le client change d'avis en cours de route, c'est tout simplement parce que AVANT d'accepter et/ou LORS de l'établissement du Cahier des Charges l'interlocuteur (qu'il soit CP, commercial, MOA, MOE, ou ce qu'on veut) n'a pas assez posé de questions et fouillé...

Je réitère que le client a zéro faute (à part vraiment les mauvaises fois, mais elles sont très rares).

Pas dans le monde ou je vis. Mais il est vrai que tu fuis les "grands comptes" comme la peste... En banque, assurance, et télécom, des gens qui s’arque-boutent sur leur exigences fausses parce-que le concept même de questionnement de leur œuvre sacrée est inconcevable, c'est fréquent.

Par contre, quand ils changent d'avis, c'est de notre faute....

(.../...)Si je prend ton argument des SSII, il est souvent - plus la SSII est grosse plus c'est vrai - plus intéressant que le client "se trompe", c'est à dire qu'on ne mette pas les choses au clair tout de suite, car on lui fera payer les modifs ultérieures...

La raison d'un mauvais Cahier des Charges oscille donc entre incompétence ou volonté délibérée des intervenants côté fournisseur ...

Pour les projets au forfait, c'est bien possible. Je n'ai que rarement trempé dans ce genre de folies. J'insiste sur le terme "folie" : il est impossible de faire un contrat correct qui couvre tout, et ça finit toujours en guerre de tranchées, de ce que j'en ai vu.

Quand on est en régie(mon pain quotidien), et qu'on sait qu'on va se farcir la maintenance de la chaine qu'on est en train de mettre en place, tout de suite, la manière de penser change. En fait, c'est même le contraire : on rajoute des trucs maintenant pour être tranquille plus tard, quitte à les passer en loucedé sur le budget(heureusement, ils ne lisent jamais les lignes "détail" du budget, sinon ils feraient sauter la moitié des trucs - et rien ne marcherait).

Avant ma mission actuelle, j'ai passé 3 ans à me battre contre les gens du marketing dans leur propre intérêt. Leur intérêt? Que la chaine marketing mensuelle passe avant la fin du mois, sinon leur carrière en pâtirait. Leur manière de fonctionner? Des specs minimalistes, pas de détails, et si le détail ne convient pas, c'est de la faute au programmeur qui n'a pas su lire dans leur esprit. Et surtout : dépenses minimales, surtout pas de dépenses sur la reprise en cas de plantage. C'est de la technique, ça n'a donc aucun interêt. J'ai quand même fait(dans leur dos, une ligne en petits caractères soigneusement planquée dans l'estimation) une procédure de reprise, qui a du leur sauver 5 ou 6 mois sur 2012.....(parce qu’évidemment, tous les mois, on recevait des données pourries grâce à leur excellent travail. Donc il fallait faire une reprise)

En plus, je leur en avait parlé, et ils m'avaient envoyé chier : ça ne faisait pas partie de leurs sacro-saintes specs, il n'était donc même pas concevable d'évoquer le sujet. Tu parle de "poser des questions" et de "fouiller", mais quand 100% de tes remarques ou suggestions n'amènent aucune réponse(même pas "lâche-nous la grappe"), tu cherches alors à contourner le demandeur. Dans son propre intérêt.

Et c'est pour ça qu'il faut des gens avec un minimum de qualité dans les équipes : pour prendre les choses en main quand c'est nécessaire. Surtout face à des cons. Dans leur propre intérêt.

[souviron34]

Il y a même de la littérature qui explique pourquoi. Plus exactement, si on ne sait pas(hélas) démontrer formellement que l'analogie bureau d'études - développement de projet - est exacte, on peut en revanche démontrer que se servir de cette analogie améliore la probabilité de succès du projet.

Effectivement..

Faut-il aussi que je fasse un blog ou publie un bouquin ???

ça fait 20 ans que je m'égosille à proclamer ceci...

Pas dans le monde ou je vis. Mais il est vrai que tu fuis les "grands comptes" comme la peste... En banque, assurance, et télécom, des gens qui s’arque-boutent sur leur exigences fausses parce-que le concept même de questionnement de leur œuvre sacrée est inconcevable, c'est fréquent.

Je suppose que justement cela doit venir d'un fonctionnement totalement sclérosé " grands comptes => grosse SSII ou équipe interne "en mode larbin"..

Pour les projets au forfait, c'est bien possible. Je n'ai que rarement trempé dans ce genre de folies. J'insiste sur le terme "folie" : il est impossible de faire un contrat correct qui couvre tout, et ça finit toujours en guerre de tranchées, de ce que j'en ai vu.

Oh mais c'est extrêmement courant...

Et on en revient au CdC.... Quand j'ai vu passer des documents où on demandait à un guichetier de contresigner pour approbation des descriptions de tables relationnelles, ça ne peut que aller dans le mur..

Et c'est - consciemment ou non - fait exprès...

Dès la fin du contrat "officiel", bien entendu les utilisateurs sont insatisfaits.. Mais on montre alors les documents signés, et on ler dit "ben, vous aviez signé.. Maintenant, si vous voulez modifer, ce sera XX $ / jour"..

Et c'est d'autant plus vrai qu'on utilise des cycles en V (et donc de grosses équipes ou de grosses SSII)...


(PS: c'est comme ça que j'ai eu 8 ans de contra avec le gvt fédéral canadien : après une expérience malheureuse de ce type, le responsable s'est battu avec le Service des Appros en disant "je le veuxx, lui, parce que je sais que ce sera un prix "tout compris")

Des specs minimalistes, pas de détails, et si le détail ne convient pas,

C'est bien ce que je dis: incompétence du "dialogueur"...

Car son rôle est justement de faire cracher de vraies specs utiles... Quitte à "torturer" un peu ou à poser des ultimatums...

[el_slapper]

(.../...)C'est bien ce que je dis: incompétence du "dialogueur"...

Car son rôle est justement de faire cracher de vraies specs utiles... Quitte à "torturer" un peu ou à poser des ultimatums...

Ce qui sous-entend avoir un certain poids.

Le programmeur, en France, il pose un ultimatum, on le remplace. Et c'est le client qui est dans cette logique. C'est le client qui considère le programmeur comme un élément non-stratégique, remplaçable comme une huile usagée. C'est le client qui met le programmeur à la place d'un rouage parmi d'autres dans une grande chaine de production de code.

Mon père a bossé en PME, en tant que DSI(titre ronflant pour dire qu'il y avait deux programmeurs et qu'il avait 6 mois de plus que sa collègue), et il avait un peu plus de poids. Parfois, ça ne suffisait pas. Mais il était assez peu "remplaçable", en tous cas sans casse. Donc il pouvait torturer.

Un prestataire comme moi, dont le nom n'apparait même pas sur le contrat de prestation, et qui peut être remplaçé du jour au lendemain(ça m'est arrivé une fois) par un collègue de la même boite, qui se permet de torturer les gens pour obtenir des informations, il est TRES vite remplaçé. C'est pour ça que, quand je fais face à des cons(pas tout le temps, heureusement), je pose quelques questions, mais face à un mur, je n'insiste pas et je passe en mode clandestin.

C'est mal? Certes. Mais c'est la seule manière d'être professionel quand même.

[souviron34]

Le programmeur, en France,

Qui parle de programmeur ?

On parle de Cahier des Charges..

Ce n'est pas dans le rôle du programmeur de le rédiger.... C'est pour ça que je parle de "interlocuteur" au niveau CP....

(j'entend bien ce que tu dis, hein ? je ne fais que pointer une évidence qui , je le sais, est souvent tournée)

[arkhamon]

Allez hop je vous donne mon point de vue, ça va faire grincer les dents...

J'aime beaucoup l'exemple de la route de SF, pour le côté "planfication". Merveilleux. On part du principe que on fait X km par jour et tout et tout. D'abord une remarque : le mec découvre que la route est pas droite. Ah bon et sur sa carte y avait quoi ?
Deuxio, il découvre qu'il fatigue et qu'au bout de quelques jours il va 2 fosi moins vite. Etonnant ça...
Et pis pire que tout y a une tempête... Pff pôvre planificateur...

Ca me fait bien rire...

Pour moi y a deux sortes de projets informatiques :

• ceux qui ont été "finement" planfiés, chiffrés et conduits, et qui finissent en retard pour plus cher que prévu
• ceux qui sont faits sans planification, ni budget précis et qui finissent en retard et avec dépassement du prix.

Planifier un projet informatique, ça consiste enter autres à :

• suivre toutes les étapes officielles pour obtenir un cahier des charges et tout et tout
• prévoir tout ce qu'il va falloir pour réaliser
• réaliser dans les temps et au coût prévu.

Sauf que :

• si l'accident était prévisible ça s'appellerait pas un accident
• t'as beau être aussi bon que possible, une bête fonction plante pendant 2 jours sur un bug tout bête, alors que tu avais prévu 2 heures
• faut quand même que les gens prennent des vacances (ah bah si quand même) et j'ai jamais vu dans une ligne budgétaire d'un projet le truc "impact congés"
• la loi de Murphy est quand même très sous estimée
• l'inflation ça existe. Sur un projet court je dis pas mais si ça dure 3 ans, c'est pareil, j'ai jamais vu la ligne "impact inflation et hausses des charges"
• le client est un accident en soi : imprévisible, de mauvaise foi, prétentieux et pingre
• le fournisseur est un accident en soi : imprévisible, de mauvaise foi, prétentieux et pingre
• le développeur est un accident en soi : imprévisible, de mauvaise foi, prétentieux et pingre

Je le sais, j'ai été les trois...

Après on peut deviser gentiement sur la nécessité de savoir où on en est et tout le reste. Il est sur qu'un gros projet doit avoir une phase de planification
A tous ceux qui finissent un projet digne de ce nom à l'heure et au coût prévu, soit c'est du bidonnage, soit Dieu existe vraiment et il s'appelle "Chef de projet Machin"...
Et là c'est pas spécifique à l'informatique : j'ai un grand constructeur immobilier à qui je demandais des explications sur 1 mois de retard pour me livrer ma maison qui me répond droit dans le bottes : "ben y a eu des intempéries au mois de février : du gel et de la pluie ! 24 jours au total !"
Ah bah oui je suis con ça arrive jamais la pluie ni le gel à Melun (77) au mois de février...

[phili_b]

Pour moi y a deux sortes de projets informatiques :

• ceux qui ont été "finement" planfiés, chiffrés et conduits, et qui finissent en retard pour plus cher que prévu
• ceux qui sont faits sans planification, ni budget précis et qui finissent en retard et avec dépassement du prix.

[..]
Et là c'est pas spécifique à l'informatique : j'ai un grand constructeur immobilier à qui je demandais des explications sur 1 mois de retard pour me livrer ma maison qui me répond droit dans le bottes : "ben y a eu des intempéries au mois de février : du gel et de la pluie ! 24 jours au total !"
Ah bah oui je suis con ça arrive jamais la pluie ni le gel à Melun (77) au mois de février...

Oui mais on pourrait presque en déduire de ton message que comme tout le monde dépasse le budget et est en retard pas besoin de faire de gestion de projet. Mais si on enlève les extrêmes, gestion à l'arrache ou bureaucratique, un projet a peu près normal il n'aura "que" 10% de dépassement en budget et/ou délai. Et c'est effectivement pas simplement au vendeur mais aussi au client de se garder de côté une marge en délai et en sous.

[arkhamon]

Oui mais on pourrait presque en déduire de ton message que comme tout le monde dépasse le budget et est en retard pas besoin de faire de gestion de projet. Mais si on enlève les extrêmes, gestion à l'arrache ou bureaucratique, un projet a peu près normal il n'aura "que" 10% de dépassement en budget et/ou délai. Et c'est effectivement pas simplement au vendeur mais aussi au client de se garder de côté une marge en délai et en sous.

Ah bah forcément si on enlève les extrèmes, y a plus rien de glorieux à finir un projet à l'heure...
Plus sérieusement (par rapport à mes posts et pas à ta réponse), je pense que la question posée est sa réponse sont évidents pour les maitrises d'oeuvre des projets, et malheureusement, personne ne veut l'admettre, en particulier les chefs de projets qui considèrent que tel truc est fait en 2 jours point barre, le client qui veut pas payer et le mécano qui veut bien faire ce qu'il peut, mais un boulon serré et grippé dans un carter, ça veut dire carter à changer il est pas magicien (phrase favorite des informaticiens qui sont face à un cas insoluble, par contre quand c'est fait, paser pour un magicien est assez valorisant...) , moi le premier d'ailleurs...

Après, pour avoir un diplôme de chef de projet, la planification est bien entendu nécessaire, mais la question étant "Les développeurs sont ils condamnés à ne jamais respecter leurs cahiers des charges ? " on en peut la décoreller de la planification qui est en termes politiquement corrects hasardeuse.

[Matthieu Vergne]

• le client est un accident en soi : imprévisible, de mauvaise foi, prétentieux et pingre
• le fournisseur est un accident en soi : imprévisible, de mauvaise foi, prétentieux et pingre
• le développeur est un accident en soi : imprévisible, de mauvaise foi, prétentieux et pingre

Je le sais, j'ai été les trois...

J'en déduis que tu es imprévisible, de mauvaise foi, prétentieux et pingre, mais ça veut pas dire que tout le monde l'est.

[arkhamon]

J'en déduis que tu es imprévisible, de mauvaise foi, prétentieux et pingre, mais ça veut pas dire que tout le monde l'est.

Ah non pas du tout.
Je suis imprévisible, de mauvaise foi, prétentieux et pingre... 3 fois !

J'exagère beaucoup mais c'est un peu cet esprit là. Faut bien reconnaitre qu'en tant que client, on veut toujours plus pour moins, le fournisseur veut toujours plus pour moins et le programmeur veut toujours plus pour moins. Je suis pas très clair mais je pense que tout le monde saura remettre dans le contexte.

Après on arrive en général à se mettre d'accord ça s'appelle la négociation, parce qu'en face d'un besoin il faut bien souvent mettre une solution, et que souvent le besoin est difficilement occultable.

[Matthieu Vergne]

Mais comme tu es de mauvaise fois (3x en plus)... {^_^}

[webmine67]

Tous est question de compétences :

avant même de commencer le shema doit déjà être dans votre tête, avec un personnel compétant tous les délais sont toujours respecter. après avoir mener 4 gros projet à termes avec parfois 20% d'avance sur le créneau , j'ai toujours réussi à garder une marge de travail correct c'est sur si mes web designers étaient des nuls qui passe 15 ans sur chaque images à modifier ou si mes programmeurs laissaient des fautes partout c'est sur que l'on aurais jamais fini à temps mais grâce à une super équipe comme la mienne , nous arrivons à battre des records... donc tous est question de compétences.

[Matthieu Vergne]

Si tout le monde avait une super équipe, on ne serait pas là à discuter. Rassembler une équipe ça demande pas juste "de le faire". On résout un problème là où ça arrive, si tu n'as pas le problème tant mieux pour toi, ça ne le rend pas pour autant inexistant chez les autres.

[moons17]

le problème est vaste .
le problème du respect du cahier des charges est surtout un problème d'organisation de base . j' m'explique ;

- il faut que la maitrise d'ouvrage applicatif est :
- fini d'analyser les besoin du métier avant de transmettre la demande aux développeurs
- cadre la demande du métier
- définisse des lots de dev clair
- résiste à la pression du directeur projet

coté développeur :
- ne pas renoncer à ces exigences qui permettent de bien géré le dev
- avoir un ingénieur logicielle qui prend la mesure de problèmatique lié au contrainte des environnents et exigence des équipe de production : c'est à dire

ne pas gérer de fichier de log , de donnée dans le répertoire d'installation de l'application ( exemple d'application virtualisé app-v dont les utilisateur n(ont pas de droit sur la bulle virtuelle et toute demande de contourner la securité reste impossible ) ou d’éviter d'avoir un division par o à la lecture d'un fichier de conf car un chemin spécifier dans celui ci sur le poste de l'utilisateur n'existe pas ( 0 contrôle des entrant et aucune prise en compte des changement d'environnement suite à une modification de plateforme (, aucune utilisation des variable d'environnement du poste et refus de le faire :réponse ' moi le systeme ca me faire chie...')

ne pas tester les dev sur leur poste ( non référent des poste utilisateur )
intervenir directement sur une 1 machine , dev rapidement une dll et la poussé à l'arrache
prendre 1 machine en reference sur un parc hétérogéne dont le mco à été fait à l'arrache en dehors de tout circuit de mise en production corrective

documenter le code
constituer les document d'architecture technique de l'application
identifier ce qu'est une version de l'application , de livraison . etc etc

par faciliter les exigences en la matière passe à la trappe au prétexte qu'il n'y à pas la CAF ( Capacité à faire ) et omette dans le chiffrage des cout le temps nécessaire à toutes ses opérations , ce qui conduit à se tirer une balle dans le pied ( monté en compétence de nouveau dev sur un code non documenter , reprise d'un appli faite par tierce non documenté ... )

réduire la productivité d'une équipe de dev au temps passé à coder est complément méconnaitre les problématique des métier lié au dev et pourtant certain observatoire le préconise ... , cela conduit à créer un cercle vicieux de création d'anomalie et erreur technique qui s'auto alimente au lieu d'un cercle vertueux de correction et évolution fonctionnel dans la mise en production .

pour finir un petit mot que j'ai laché à un dev en tant qu'ingénieur de production : le logiciel ... ont l'a mais le genie est surement resté dans la bouteille ( nous vivions ce que j'ai écris au dessus )

[moons17]

un petit ad-don : le problème que rencontre chaque individu c'est qu'il pense et réagi en fonction de son cadre de référence ( société ....) pour le développeur c'est pareil

prenons un exemple frappant : demander à un developpeur de faire programme de gestion de date et suivant son cadre de référence vous aurez plusieurs programme dissemblable , en effet le calendrier de référence dépend de la société dans laquelle vie l'individu . ( problèmatique de dev offshore)
les calendriers existant :

si vous developpez une application pour vos clients/société ayant des etablissement au 4 coins de la planète il se peut que vos code générè des anomalie technique . un exemple concret

extrait d'un code vbs

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
Public Function LogMyAction(DescAction)
	' Generation du fichier de collecte en  mode Ajout.
	Set oLF = oGFLog.OpenAsTextStream(ForAppending, TristateUseDefault)
	
	oLF.Write "[ " & Date & " " & Time & " - "& STR_ComputerName & " ] : " & DescAction  &  VbCrlf
	oLF.Close
	Set oLF= nothing

End Function

si la machine qui execute cette fonction est parametré avec un calendrier gregorien cela fonction , si par contre elle est reglé avec le calendrier japonnais vous aurais le message de retour suivant :


( erreur sur la ligne qui appelle la fonction natif vbs date ) ....et oui je viens de trouver un bug MS... (pc en paramètre régionaux japonnais)

alors qu'en python quelques soit le paramétrage du poste client le code sortira toujours une date au format grégorien ( un eventuel bug fonctionnel suivant le cahier des charges)
à noter que python est plus robuste sur la gestion des dates mais ne gère pas autres chose que du grégorien (format iso)

le problème des développeurs c'est de s'affranchir de leur cadre de référence pour bien comprendre le besoin et les non dis des cahiers des charges qui sont inhérent à la demande sans quoi même dans le meilleur des mondes il faudra inévitablement remettre la main à la patte pour corrigé des anomalies évitables .

[Matthieu Vergne]

Je pense plutôt que ce problème viens du cahier des charges (CdC), qui est censé lister les exigences à considérer (donc le cadre de référence à appliquer). Si ce n'est pas dedans, c'est qu'on n'en a pas besoin. Et le développeur n'a pas la responsabilité d'identifier les exigences manquantes. Ce sont bien entendu des stéréotypes, un CdC n'est jamais exhaustif. Mais s'il manque quelque chose on ne peut pas le reprocher au développeur. Si le dév a conscience d'un manque et ne le dit pas, il est fautif de ne pas avoir signaler un problème, mais c'est surtout l'auteur du cahier des charges qui est fautif de ne pas avoir mis en oeuvre les ressources suffisantes (i.e. demander l'avis du dév) pour rédiger un CdC correct.

L'erreur est humaine, mais si on devait reprocher ce genre de choses, ce serait plutôt à l'analyste qui a rédigé le CdC, et non au développeur, qui doit se soucier de problèmes d'architecture et d'optimisation entre autres. Chacun son job. Ce qui est central c'est la communication, pas le développeur. Faut pas tout lui mettre sur le dos. Evidemment, si c'est lui qui l'a rédigé, c'est sa faute, mais ce n;est pas une faute de développeur, c'est une faute d'analyste. On peut être bon dans un et mauvais dans l'autre.

[moons17]

d'un autre coté il est courant de voir des développeur considérer leur cadre de référence (poste de travail entre autre )
comme étant une référence pour le développement bien que le cahier des charges ne le stipule pas le et de voir des crash applicatif car l'application s'appuie sur un contenue d'application de développement absent sur le poste des utilisateurs.

il est évident que tout les acteurs du changement applicatif doivent s'extraire de leur bulle (se poser des questions sur ce qu'il font et comment il le font ) pour avoir une vision plus globale que se soit de la moa /moe /qualif /test / production .... qui plus est avec des équipes internationales.
Pour ma part je pense qu'un programmeur qui se lance dans du code sans se poser des questions (confronter sa vision et celle de l'analyste si c'est des personnes différentes ) se tire une balle dans le pied . l'organisation et le dialogue sont nécessaire surtout si le code est répartie sur plusieurs Usine de production.
quand je commande une ferrari , je m'attend pas à recevoir un chassis d'une clio , la carrosserie de 911 , le moteur d'une 2cv et les roue de 4x4 avec sans plan de montage avec comme réponse , c'est à vous à savoir comment assembler

en d'autre terme avoir des usine de production de code qui bossent sur des branche de code divergente , pas foutu d'assembler leur code , et sans faire de régression.. de livré un produit 'fini' ( assemblé ). et quand on leur demande le référentiel pour assembleur leur livraison ils n'en n'ont pas et insulte à la demande . ( du vécu) . ce qui conduit à comportement chronophage de correction d'anomalie

souvent le manque d'organisation est le principal facteur des dérives des cahiers des charges
[Edit]
Faire Bien la première fois ne coute pas plus chère , ne vaut il pas mieux perdre une journée en analyse , communication préalable au dev que de devoir dépenser 10 fois plus (au moins ) entre les test en qualif , assurance produit , mise en prod et correction d'anomalie (pour chaque code non robuste , ne répondant pas au Cdh ....) ?
un exemple frappant : une sonde européenne se crash sur mars pacque le calculateur du lancer de conception US et l’équipe au sol fonctionnait en dehors du système metric ISo contrairement à la sonde ... une erreur à quelques millions ou milliard ...

[Matthieu Vergne]

Ben si, c'est clair que ça coute moins cher de faire une bonne analyse que d'attendre d'avoir des problèmes à la fin pour corriger. Mais ça n'est jamais évident, et cela pour une simple raison : quand est-ce qu'on arrête l'analyse pour passer à l'implémentation ?

On a généralement des deadlines à tenir, et le seul moyen d'avoir une phase d'analyse bien dosée, c'est de savoir combien de temps nous prendront les phases suivantes pour bien choisir le temps de la phase d'analyse. En bref, être devin. Donc soit tu as une expérience déjà énorme et ton projet est des plus simples, soit tu es condamné à faire des paris. Et les méthodes agiles ne sont pas applicables partout : va faire un Airbus de manière itérative. Ça aura beau être de super qualité, 3/4 d'avion ça ne vole pas (tu peux te limiter à la partie informatique pour rester dans notre domaine).

[moons17]

il est clair qu'il à y un moment ou il faut sauter le pas vers la mise en production mais il faut se rappeller que :
l'informatique ne reste pas dans une monde virtuel mais à bien des impacts sur le monde réel ( informatique embarqué dans les voiture avions , assistance médicale et autres ).
laisser partir du code non viable en production dans certains domaines équivaut à faire prendre des risques non paiement de pension dans les caisse de retraite , panne sèche de carburant en plein vol car les gallons et les litres ont été confondu ( cas deja produit ) voir le décès de patient car bug dans l’équipement d'assistance en bloc de rea) ..
êtes-vous prêt à prend ces risques sous prétexte qu'il fallait livrr un truc pour hier et qu'il est vendredi 17H30 qu'il faut absolument mettre en prod alors que le livrable , n'est pas fini et que les éléments pour le produire (cahiers des charges ne sont pas clair ) ?

Si la réponse est oui alors .. à quelle prix .. ou cout humain Les développeurs sont ils condamnés à ne jamais respecter leurs cahiers des charges ?


[Edit]
Ref de l'exemple cité plus haut
http://fr.wikipedia.org/wiki/Mars_Climate_Orbiter
http://en.wikipedia.org/wiki/Gimli_Glider
autre cas recent http://www.marianne.net/blogsecretdefense/Rafale-l-accident-est-le-resultat-d-un-probleme-de-jauge-l-avion-s-est-retrouve-en-panne-seche_a48.html
jauge , informatique embarque ?

extrait de "Maîtrise D'ouvrage des projets informatiques" 3em edition Dunod

principal difficultés ressenties par la maîtrise d'ouvrage :
..
-mauvaise compréhension et appréciation des évaluation de charges et délai fournie par la MOE considérées trop souvent très élevées.

principales difficultés perçue par la maitrise d’œuvre :
...
difficulté à évaluer la charges et les délai et à les expliquer à la MOA

Priorité données à la collaboration avec le client plutôt qu'a la négociation de contrat
Il n'est pas possible dans la démarche Agile , de rédiger en début de projet un cahier des charges détaillé figeant complètement l'expression du besoin. il est important de pouvoir s'adapter aux changements qui ne manquent pas de survenir tout le long d'un projet. Le client doit pouvoir collaborer de manière continue avec le réalisateur et fournir un feed_back sur ses attentes par rapport à la réalisation progressive de la solution ...

la méthode agile préfère mettre l'accent sur les personnes que sur les processus et outils, une documentation succinctes plutôt que détaillée de l’architecture des systèmes et un cahier des charge évolutif au fil du projet ,.
Tout cela ne permet pas de maitriser la qualité et les couts de développement et à mon avis contre-productif au final