Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
Effectivement, je pense que "nous n'avons pas les mêmes valeurs"Envoyé par el_slapper
oui, et on retombe sur mes 2 premiers posts dans ce thread (#52 et .. 55??) sur une (grosse) partie de la "spécificité" française et du "retard français" sur l'aglité..
Excellente synthèse !
Ca valait mieux qu'une réponse spécifique à mes remarques !
C'est juste que il y a des intérêts divergents : l'intérêt de chaque boîte est de faire le plus de sous, pas de terminer le projet en dépensant le moins possible
- C'est vrai pour une boîte et sa direction ; mais pas pour les opérationnels qui ont un ego à satisfaire
- L'intérêt d'une boîte c'est aussi d'avoir un bon chiffre d'affaire et donc de faire des affaires et donc d'être compétente et compétitive.
- Différentes organisations/services ne signifient pas différentes boîtes ;-)
Pour information je ne travaille pas pour une grosse SSII
Dans ce cas tu pourrais aussi dire qu'un équipementier n'a pas les mêmes besoins qu'une autorité, qu'une compagnie aérienne, qu'un "leaseur d'avion" ou une société de maintenance ...
Le but (et le travail) de ces 2 clients c'est exactement de dialoguer avec tes "experts métiers". Par ailleurs sur une de mes applications, l'expert travaille pour le service produit/achat.
Ca me sent plus plausible qu'une seule personne ayant toutes ces compétences. D'ailleurs tu le dis toi même :
C'est pour ça que mon client travaille avec un petit groupe de fournisseur et préfère avoir une relation "privilégiée". En quelques sortes on a la "culture d'entreprise". Par exemple, ca fait 5 ans que je bosse pour le même client mais dans 3 sociétés différentes.
C'est l'avantage également d'avoir des équipes dédiées, elles sont beaucoup plus dispos pour un projet donné.
Le principe c'est justement de limiter ces écueuils ; ou au moins limiter leurs sources/origines.
Ce que je dis c'est que si une boîte doit embaucher des développeurs/CP/Architecte/Autres, les former à son métier, les laisser s'auto-gérer et "déranger" les autres empoyés. Le résultat risque d'être bien pire en termes de budget et de délais.
Parce que c'est le boulot de chacun. De la même manière que ton expert fait son taff, tu as quelqu'un qui doit le comprendre. Et, éventuellement, une autre personne qui va le transcrire en spécifications, un autre en conception et une autre en code.
Je suis plutôt d'accord qu'il n'a pas nécessairement les moyens de juger. Cependant quand la communication ne passe pas, on sait bien qu'il y a un soucis. Ensuite il peut se donner les moyens en faisant appel à de l'AMOA (ou consulting pour faire plus nord-américain).
Il devrait plutôt me dire : "si je mets du Ø6, vous ne pourrez pas jeter de gros paquets de papier toilette dans vos WC".
Ou encore, si je veux mettre du Ø14 ici, il faut que je casse la moitié des carreaux de votre salon pour changer le reste de l'évacuation qui est en Ø6...
Il est assez important de mesurer/expliquer les conséquences ...
Ca me fait penser à la pub qui passait à la radio pour les entreprises de travaux d'économie d'énergie. Dans celle-ci, un couple choisissait l'entreprise à la roulette, et était constemment déçu.
Toutes les musiques n'ont pas besoin d'une table de mixage et d'un piano
Il faut revoir tes prétentions à la baisseCe qui fait que je ne crois pas du tout à :
Je suis pas sûr que dans la plupart des projets cela apporte un réel plus d'avoir un expert ergonome, expert Oracle, etc. Et parmis ceux ont cela apporte un plus, je ne suis pas sûr que sans le produit soit mauvais. Il reste donc qu'une poignée de projet où ils sont nécessaires.
Je ne côtoie pas les gens qui nous dictent les priorités sur la plupart de mes projets. Mais sinon oui et autrement rien n'empêche. Le problème c'est qu'on agit comme éditeur et donc les fonctionnalités/priorité sont au moins influencés par la "communauté d'utilisateur".
Aucune idée. Au moins à chaque fois qu'ils appellent le support (ie hotline)
De quelques heures à plusieurs mois. Là le problème n'est pas le waterfall mais le mode de livraison (TMA ou version) et de déploiement (centralisé ou distribué).
Un éditeur de logiciel vend un produit et une société de service vend du service
Pour faire l'analogie avec la construction d'une maison : un promoteur/constructeur vend un produit (comme un concessionaire de voiture), cependant un maître d'oeuvre vend un service.
Le premier fait du développement "général", il fabrique (quasiment) à perte et espère vendre suffisemment son produit pour rentrer dans ses frais. C'est lui qui va vers le client. Le client doit s'adapter au produit (à quelques détails près).
Le second fait du développement "spécifique". Il fabrique un logiciel sur marge dont le prix est fixé par estimation et payé au forfait/provision/temps passé (Forfait ou Assistance Technique). C'est le client qui vient vers lui (y compris via un appel d'offres). Le produit doit s'adapter au client (à quelques détails près).
Hummmm ... Tu peux aussi livrer quelque chose qui ne compile pas mais ça ne sert pas à grand chose. Je pense qu'il est également acceptable de ne livrer que de la documentation par exemple. J'ai déjà vu ça sur des cycles itératifs.
Un "sprint" contient uniquement ce que tu veux/peux y mettre. A toi et ton client d'en définir le contenu.
voui, mais c'est pas le but de la boîte
- C'est vrai pour une boîte et sa direction ; mais pas pour les opérationnels qui ont un ego à satisfaire
et donc ça n'intervient qu'en terme de politique de RH, cela ne doit pas intervenir dans la structuration/succès du projet dans un dév en Waterfall/V
D'où l'intérêt d'une approche 'agile", qui prend en compte ça...
ça se saurait si il y avait équivalence ou bijection entre ces termes
Ce n'est pas ce que j'avais compris, désolé..
- Différentes organisations/services ne signifient pas différentes boîtes ;-)
..
Pour information je ne travaille pas pour une grosse SSII
Aboslument, oui, c'est bien ce que je dis
Ta formulation me laisse à penser que ta boîte veut faire un outil générique qu'elle peut adapter à divers types de clients pour se faciliter la tâche. Si c'est bien cela, c'est bien encore une fois de la rentabilité interne en moyennant la satisfaction des usagers et non par orienté vers la satisfaction de tous les types d'usagers spécifiques au mieux..
Je crois que tu m'as mal compris : depuis le début je ne dis pas (au contraire) qu'une seule et même personne possède toutes les compétences.. Je dis simplement que la division en entité distinctes est un facteur de "téléphone arabe", pour reprendre l'expression usuelle, mais que aucun informaticien, si il n'a pas été spécialement formé, ne sera graphiste à la place d'un graphiste..
Voir ci-dessus..
Là on a vaiment un problème de compréhension / projets ..
Dans les boîtes industrielles dans lesquelles j'ai été, l'équipe informatique est toujours présente en permanence, souvent d'une dizaine de personnes, et couvrant souvent les compétences citées. Il n'y a pas "d'embauches" à faire..
Voir plus haut. Le distinction (de taille) entre cycle en V ou Waterfall et agiles se fait justement sur la diminution drastique des échelons, et donc sur la diminution drastique de l'effet "téléphone arabe"..
Ce n'est pas "n'a pas nécessairement", c'est "n'a jamais", sauf si ton client est lui-même informaticien..
Et ce n'est pas un problème de communication. C'est un problème d'être outillé pour juger de la compétence / validité technique de la solutiion par rapport au problème.
Quant aux MOA ou AMOA, en quoi sont-ils plus capables d'évaluer ces points ? Surtout si c'est une boîte externe ?? Et compte-tenu des remarques à leur sujet faites précédemment..
Je ré-itère : ce n'est pas au client de se donner les moyens de comprendre, c'est au fournissseur de répondre adéquatement au problème.
Entièrement d'accord, mais d'après tes remarques du début sur les clients et leurs demandes/remarques, je ne crois pas que cela soit fait..
Non, mais si tu veux qu'elles durent plus que 1 mois et quelques écoutes, eh bien siToutes les musiques n'ont pas besoin d'une table de mixage et d'un piano
D'une part il y a une nuance entre avoir un "produit pas mauvais" et avoir un "produit excellent".Il faut revoir tes prétentions à la baisse
Je suis pas sûr que dans la plupart des projets cela apporte un réel plus d'avoir un expert ergonome, expert Oracle, etc. Et parmis ceux ont cela apporte un plus, je ne suis pas sûr que sans le produit soit mauvais. Il reste donc qu'une poignée de projet où ils sont nécessaires.
Je suis désolé mais moi je vise toujours l'excellence...
D'autre part, que ce soit en termes de budget ou de satisfaction, entre avoir 50-70 personnes dont aucune n'est experte mais qui produisent quelque chose de "pas mauvais" et en avoir 10 ou 12 où chacune est experte dans son domaine, qui produisent quelque chose d'excellent, c'est très nettement plus rentable
C'est bien ce que je dis :
- "influencé" ne veut pas dire que le résultat final correspond à 100% à ce que désirent les utilisateurs.
- "rien n'empêche" ou "on n'agit que comme éditeur" : ce qui veut dire que ce n'est pas le cas..
Qui, lui, traduit par écrit ce qu'il comprend par tel, puis le passe, etc etc..Aucune idée. Au moins à chaque fois qu'ils appellent le support (ie hotline)
Perte, Perte, et re-perte..
Délais explosés par rapport à une démarche agile, à cause jusement de la structure du Waterfall : analyse / conception préliminaire / conception détaillé / codage / tests unitaires / tests de système...
Vous n'avez donc pas la même définition, toi et el_slapper..Un éditeur de logiciel vend un produit et une société de service vend du service
Ceci est , comme je le mentionnais, le cas de quasiment tous les logiciels utilisés dans des machines industrielles..
Cependant, pour que il vende suffisamment pour rentrer dans ses frais, le mieux est qu'il colle le plus possible au client visé, non ???
Si on te propose une voiture avec un rétro au milieu du siège arrière, je ne suis pas sûr que le constructeur rentre dans ses frais, parce que le client n'aura pas envie de s'adapter..
C'est également le cas de toutes les équipes internes, pas juste des SSII.
Voir plus haut. Franchement je ne vois pas la distinction que vous faites par rapport à la satisfaction/input du client..
Comme son nom l'indique, "itératif" signifie simplement que ça grossit et se finalise au fur et à mesure..
Je ne parle pas d'étapes "de doc pure".
Quant à livrer quelque chose qui ne compile pas, le seul cas où cela est possible est pour justement une validation ergonomique des écrans et de leurs suites, AVANT le / PARALLèLLEMENT au / démarrage de l'analyse.
Mais par exemple une fonctionalité peut être de présenter un graphique en appuyant sur un bouton en bas du 6ième écran.
Dans une approche "agile" et/ou "itérative", on peut simuler le graphique avec de fausses données codées "en dur" et le présenter pour validation au client, sans que il y ait eu besoin ni de faire les connections aux BD ni de coder l'ensemble des sous-fonctionalités du graphique.. (ni-même d'avoir déjà détaillé quelle BD on utiliera avec quel outil)
Ce qui ne peut se faire en Waterfall : il faut attendre que cela soit terminé, avec connection de la BD, avec analyse/codage et tests de toutes les fonctionalités aussociées au graphique, pour que le client approuve / ou non, ce graphique..
Sauf que ce n'est pas la boîte qui va travailler 60h au lieu de 40 pour que le projet fonctionne mais bien un développeur (notemment).voui, mais c'est pas le but de la boîte
L'agilité empêche quelqu'un de faire se contenter du minimum ? Non, c'est bien chaque personne qui choisit jusqu'où elle est prête à aller/s'investir.
Une demandeUn coût.
Quelque soit le mode de facturation (catalogue, forfait, temps passé), si le gars décide d'y passer 5 jours au lieu de 3 ou au contraire se presser comme un citron pour le faire en 1 jour, c'est bien lui qui va décider du coût. L'avantage de l'externalisation c'est qu'en catalogue/forfait les retards (ou sous-estimation) sont pour la pomme de l'externalisé. Et donc un bon coût de revient pour le commanditaire.
Agile, modèle en V ou autre.
C'est en tout cas un modèle réaliste. Et en l'occurence celui adopté par ma boîte.ça se saurait si il y avait équivalence ou bijection entre ces termes
Ce qui notemment implique que nous prenons en charges des coûts imputables à notre client (le geste commerciale comme on dit). Et que donc il fait des économies !
C'est bien l'une des différences entre un éditeur et une société de service. On a des besoins génériques et des besoins spécifiques parfois contradictoires.Aboslument, oui, c'est bien ce que je dis
Ta formulation me laisse à penser que ta boîte veut faire un outil générique qu'elle peut adapter à divers types de clients pour se faciliter la tâche. Si c'est bien cela, c'est bien encore une fois de la rentabilité interne en moyennant la satisfaction des usagers et non par orienté vers la satisfaction de tous les types d'usagers spécifiques au mieux..
On ne peut pas proposer un logiciel différent pour chaque utilisateur.
Mon client ne souhaite pas satisfaire un profile d'utilisateur mais une gamme d'utilisateur. Ensuite il veut également satisfaire une DSI plutôt que des utilisateurs. La réalité est que celui qu'on va satisfaire, c'est celui qui signe le chèque. S'il s'en branle que son employé soit au bord de l'orgasme ou bien pas trop mécontent du logiciel qu'il va utiliser, la satisfaction du DSI n'aura pas changé donc le contrat est rempli !
Et la DSI estime qu'elle aura déjà bien assez payé le logiciel pour qu'en plus tu viennes lui piquer un des trouffions pour réaliser un logiciel. En plus la DSI va te trouver à chier si en plus c'est à elle de te refiler des ressources pour que tu arrives à pondre à logiciel correcte.
(Ce dernier paragraphe est légèrement grossier, et c'est bien voulu pour imager la façon de penser d'une DSI).
Pour parler précisemment de mon cas, le besoin est largement générique. Exemple : "le suivi de la maintenance des flottes" : cela concerne bien un besoin "commun" aux compagnies/leaseur/mainteneur/autorité.
Concernant les services "Produit" (ou "Achat") et "Support". Ils ont également le besoin "commun" de satisfaire l'utilisateur. Disons que le "Support" fait aussi un peu "hotline du cahier des charges", en venant greffer son expérience des utilisateurs qu'il cotoie au quotidien. Tu peux apprendre beaucoup sur comment travaille quelqu'un en étant "derrière son dos" plutôt que lui demander de synthétiser son travail.
Peut-être que je suis trop habitué à la sous-traitance massive de mon client pour me rendre compte à quel point "la division" peut amplifier le "téléphone arabe".
Ce que je voulais dire donc c'est qu'Agile, BDD, UC ou autre, il faut nécessairement plusieurs intervenants et que le phénomène du "téléphone arabe" existe nécessairement.
Je ne peux imaginer un projet sans chaîne de responsabilité. Je dirai même que je ne peux imaginer une production (informatique ou non) sans. Mais peut-être que la philosophie Agile est justement de la supprimer ?
Quand on fait appelle à un prestataire, c'est justement qu'on n'a pas les employés nécessaires ...
Après il y a l'AT in-situ. Je n'ai pas connu, cependant la plupart des équipes de réalisation que j'ai connu dans cette situation était bien sur site mais isolé ... C'est vraiment histoire de dire qu'ils sont sur place.
Dans mon cas, je sais que le service Support va parfois chez le client rencontré et aidé les utilisateurs. En revanche pour le service "Produit", je ne sais pas s'ils passent du temps avec des utilisateurs ou non.
4 niveau, ca me paraît correct. Surtout pour avoir été en stage où j'ai tout géré de A à Z. J'aurai bien été content qu'il y ait quelqu'un pour receuillir le besoin, écrire le cahier des charges et faire la recette utilisateur ; une autre personne qui élabore la solution, rédige la spécification et fasse la validation/intégration ; enfin, une personne technique pour concevoir les applications, réaliser le projet et tester unitairement.
Quand tu dois valider, expliquer, présenter certaines choses à des directions pour qu'elles prennent certaines décisions qui ont des impacts sur la solution. C'est assez compliqué. Après c'est sûrement une déformation, dûe au cycle en V. Mais il me semble qu'un certain nombre de point doivent être centralisés, discutés et validés : la fameuse chaîne de responsabilité que j'évoquais tout à l'heure.
Sans être informaticien, aujourd'hui, un certains nombre de non-informaticien, savent tout de même ce qu'est un ordinateur, un périphérique, un composant, un système d'exploitation, un serveur, etc. Donc "jamais", dire "jamais" !
Les DSI sont généralement bien au courant de la notion de "système informatique" qui est aujourd'hui complétement fusionné à celle de "Système d'Information".
Dans ce cas pourquoi avoir choisi ce prestataire ? Si tu n'as pas les moyens de juger, armes toi !
MOA = client, commanditaire, propriétaire, etc.
AMOA = Assistant au client/commanditaire/popriétaire/etc. Un synonyme de consultant ou contre-expert. Je pense que leur activité principale, est l'accompagnement dans la démarche (comprendre et se faire comprendre) plus que dans la "contre-expertise" de la réponse.
Sauf que c'est le client qui choisit son fournisseur ...
A quelles remarques fais-tu référence ?
Comme "Born to be alive" ?Non, mais si tu veux qu'elles durent plus que 1 mois et quelques écoutes, eh bien si
Moi je vise la satisfaction cliente. Et aussi faible soit mon expérience, un "produit pas mauvais" n'apporte pas nécessairement moins de satisfaction qu'un "produit excellent" à l'utilisateur final.
D'ailleurs c'est la définition de base de la qualité : Un produit de qualité n'est pas un produit bien fait mais celui qui répond à tous les besoins : fonctionnalité, coût et délai.
Mais en quel délai ? Si c'est pour répondre en 2020 a un besoin de 2010 (surtout s'il y a des parties législatives ...).D'autre part, que ce soit en termes de budget ou de satisfaction, entre avoir 50-70 personnes dont aucune n'est experte mais qui produisent quelque chose de "pas mauvais" et en avoir 10 ou 12 où chacune est experte dans son domaine, qui produisent quelque chose d'excellent, c'est très nettement plus rentable
Ensuite tu mets à l'écart et dénigres 38-60 personnes. Tu promeus l'élitisation des metiers de l'informatique ? Et jettes les débutants ? Belle vision d'avenir
J'ai dit "au moins"
Je ne pourrais pas te contredire dans la mesure où je n'en sais pas plus. Ce n'est pas mon métier.
Ca veut simplement dire que dans mon cas actuel, je n'ai pas la réponse. Enfin pas toujours. Pour certains produits, je connais au moins un utilisateur, sur d'autres je fais partie des utilisateurs et pour d'autres pas du tout.
Dans ma première vraie expérience professionnelle, toujours dans un modèle en V, je puis t'assurer que c'est l'utilisateur qui décidait des fonctionnalités/priorités. Cependant on travaillait en mode "patch". On pouvait appliquer dix patchs dans la même journée et le faire 7 fois par semaine. On avait pas trop de contraintes sur la multiplication des besoins à satisfaire. La seule limite était le ratio charge/nb d'intervenant. Une équipe de 3 personnes ne peut pas faire plus de 3j/h chaque jour. Donc pour 12 jours de travail, tu as au minimum 4j de délai.
A un moment où un autre, il va bien falloir "rédiger" le besoin. Agile ou pas. Ou alors tu as des devs qui font tout. Mais il va t'en falloir une palanquée pour suivre le rythme. Si en plus tu en veux des premiums je te souhaite bonne chance.
Au fait, c'est pas toi qui ne croyait pas à la polyvalence ?
En agile tu n'analyses pas, ne conçois pas, ne codes pas et ne testes pas ? Je comprends mieux pourquoi il n'y a pas de problème
Tu me dirais on peut voir tout problème comme un noeud gordien.
Dans ce cas je te renvoie vers Wikipedia :Vous n'avez donc pas la même définition, toi et el_slapper..
http://fr.wikipedia.org/wiki/%C3%89diteur_de_logiciel
http://fr.wikipedia.org/wiki/Soci%C3...e_informatique
Il ne faut pas confondre manque de flexibilité et incohérence.
Quand le client n'en est pas "un" mais "des", voir uniquement des "profiles" et/ou des "niches", comment définir le besoin exact ? Tu crois qu'il suffit d'aller une poignée de futur client et de leur dire je voudrais faire le logiciel de vos rêves pour qu'ils t'ouvrent leurs portes ?
C'est toi qui va vers eux et non le contraire. Tu n'as personne pour t'écrire/définir/dicter/valider le cahier des charges. D'ailleurs il n'y en a pas vraiment.
Entièrement d'accord. Pas de doutes la dessus. L'inverse est également vrai (c'est mon cas par exemple). Je n'oppose pas l'externalisation à l'édition de logiciel, ni même l'internalisation au service. Les quatre combinaisons existes.
Un éditeur de logiciel vise un besoin "standard" et non un besoin "spécifique". L'input est quasi inexistant et la satisfaction parfois impalpable.
Cependant, un "progiciel" peut se spécialisé au fur et à mesure des développements, si l'éditeur entrevoie un nouveau marché (et/ou une nouvelle niche).
C'est bien ce que propose Scrum et ses Sprint. Pour rappelle, c'est cela que tu critiquais !
Si ca ne compile pas, t'auras pas d'écran
Désolé mais je le fais
Bon, on ne vas pas épiloguer, il y a incompréhension, sans doute parce que tu n'as été que dans un certain cadre, et qu'il est normal pour toi d'être entouré de prestataires et de SSII... ce que je disais au départ par rapport à la manière très française d'aborder l'informatique..
Arfffffffff....
C'est là où se situe l'incompréhension..
Comme son nom l'indique, une société de services rend un service.
Dans une structure normale, elle n'est en rien responsable d'un TOUT..
Un "éditeur", dans ton sens, devrait donc faire appel à une société de services pour faire une partie de ce qui a été défini..
Visiblement, tu perçois / défini / connaît des sociétés de services qui font un tout..
Tu opposes donc société de services et éditeurs.
Mais pour moi, et dans l'acceptation générale, une architecture, un tout, est défini par celui qui est en charge du logiciel, et une ou plusieurs partie(s) peut(vent) être sous-traitées..
Je le répète, c'est le cas de toutes les entreprises, spécialises en informatique ou non, pour lesquelles un logiciel est utilisé (pour faire fonctionner une machine industrielle par exemple).
Je ré-itère qu'une SSII (sauf si c'est elle qui en charge de la totalité du logiciel) n'a uniquement qu'à suivre les instructions qu'on lui donne..
Elle n'a donc pas, normalement, à avoir accès aux utilisateurs.. : elle traite une partie technique, définie en amont..
Voir plus haut, au début..
Pas la supprimer du tout , la réduire au maximum. Mais elle cependant basée sur la collégialité. Néanmoins, comme je le mentionnais plus haut dans mon long post sur les origines/défauts/solutions, il faut des gens qui prennent des décisions et assument des responsabilités. Je l'ai mentionné plusieurs fois, pour moi la vraie agilité suppose une tête bi-céphale, avec 2 CP à égalité, l'un technique et l'autre utilisateur.
D'une part on revient au point mentionné au début du post : ce n'est pas, de très loin , la situation la plus courante dans l'industrie.
D'autre part, ta dernière phrase était justement le point essentiel : c'est dans la définition et la fabrication du produit que la démarche agile est le plus vitale..
Entre savoir ce qu'est un ordinateur, un périphérique, avoir la notion (vague) de ce qu'est un SI, et être capable de juger que telle SSII fait de la daube ou complique les choses techniquement alors que d'autres solutions plus simples seraient plus adaptées, ou que ses employés ne sont pas bons dans leur domaines, ou que telle autre a les capacités de répndre à ta demande au mieux, il y a une marge que AUCUN client n'est capable de franchir, encore une fois sauf si c'est un client lui-même en informatique.
Donc je ré-itère : pour un client "standard", c'est bien JAMAIS qu'il n'est à même de juger de la compétence d'un prestataire..
Cimment juges-tu de la compétence de ton médecon ? de ton avocat ou de ton notaire ?
Il peut y avoir la réputation, mais d'une part il faut vouloir la chercher, et d'autre part la "réputation" n'est pas synonyme de réalité.
Mais réflechis un peu à comment toi, tu as chois ton médecin ...
Non, je promeut l'excellence, et je regarde la réalité en face : plus de 90% du boulot "normal" en informatique est d'être pisseur de lignes. Pour le reste, il faut des gens exceptionnels dans leur domaine, et l'exception est rare.Mais en quel délai ? Si c'est pour répondre en 2020 a un besoin de 2010 (surtout s'il y a des parties législatives ...).
Ensuite tu mets à l'écart et dénigres 38-60 personnes. Tu promeus l'élitisation des metiers de l'informatique ? Et jettes les débutants ? Belle vision d'avenir
Je dis simplement que l'illusion de penser que 50 personnes moyennes font mieux que 10 personnes excellentes, et plus vite et avec moins de risques, ce n'est qu'une illusion..
Dont la réalité du fait que c'est une illusion est démontrée tous les jours par ce qui se passe dans l'industrie : dans les plus récents, entre Linus Torvald, Zuckerberg, ou l'autre, là, de Facebook, ce sont des gens seuls, exceptionnels, qui petit à petit s'entourent de gens comme eux, qui avec une poignée de gens réussissent là où d'énormes équipes avec d'énomes moyens échouent..
Et dans des délais sans commune mesure avec les délais avancés par les grosses équipes..
Oui, mais le besoin peut se rédiger "à la volée", après l'acceptation des écrans par l'utilisateur, ces écrans ayant été affinés en discutant..
Et, en ce qui concerne la polyvalence, je n'y crois pas dans les domaines techniques : un excellent programmeur ne sera pas (sauf formation spéciale) un excellent designer, qui ne sera pas un excellent commercial...
Et en particulier par rapport au métier de l'utilisateur.. : un exxcellent programmeur, ou spécialiste en architecture, ou spécialiste en BDD, ne peut pas être un gourou du métier de l'utilisateur : il n'a pas été formé pour, et n'a pas l'expérience.. sinon il serait utilisateur...
Très souvent les utilisateurs sont spécialisés, y compris pour les gros projets de gestion : gestion des portefeuilles, des assurances, des outils financiers, comptabilité.. sans parler des métiers techniques que j'ai cité plus haut : pilotes, chiirurgien, radilogue, ...
A part avoir eu la formation de médeciin ou de pilote ou de estionnaire ou de trader, je ne vois pas comment un informaticien ou n'importe qui qui n'a pas eu cette formation et cette expérience peut juger des demandes de ces utilisateurs, les prioriser et hiérarchiser, à leur place... ;koi;
Encore une fois, situation totalement normale dans l'industrie autre que informatique..
Alors le CP, avec le marketing, doit établir un "faux" Cahier des Charges, en allant "traîner" là où il y a des utlisateurs, des concurrents, des salons internationaux, en fouillant les documentations de logiciels relativement similaires existants, voire en les achetant, éventuellment effectivement en rassemblant un groupe d'utilisateurs (quitte à les payer) (ce que font par exemple les groupes alimentaires, ou l'INRA, ou les boîtes de marketing pour juger de la qualité des aliments, des emballages, des apparences, du fond, ..).. Enfin lbref, ils fontt une étude de marché.
Si, mais d'une part tu ne le documentes pas de manière aussi formelle qu'en V, où un document différent est demandé pour chaque étape, et d'autre part tu fais ces activités en parallèle et non pas les unes à la suite des autres..En agile tu n'analyses pas, ne conçois pas, ne codes pas et ne testes pas ? Je comprends mieux pourquoi il n'y a pas de problème
Je critiquais, mais je précisais que "c'était très nettement accéléré par rapport au cycle traditionnel"C'est bien ce que propose Scrum et ses Sprint. Pour rappelle, c'est cela que tu critiquais !
Si ca ne compile pas, t'auras pas d'écran
Enfin bien sûr que si que tu peux avoir des écrans sans compiler : des mockups papiers, faits avec divers softs, spécialisés ou non (même Word) , ou à la main, ou dessinés sur une tablette, ou autre.. sans rien derrière..
Ou, comme mentionné, avec des données hardcodées, dans aucune foncton derrière..
D'accord avec presque tout, comme d'habitude(et j'ai répondu à ton MP).
100% d'accord jusque là. Steve Yegge les appelle les "Done, & get things smart".. Les gens qui, quand on leur donne un boulot, répondent "c'est déjà fait, et j'en ai profité pour améliorer le process". (attention, lien hyper-long à lire).
Il propose d'ailleurs de les utiliser comme "ingénieurs graine", histoire de mettre en place des process efficace et d'encadrer les gens moins performants(mais quand même très supérieurs à la moyenne).
Amen.
C'est le mouton à 6 ou 7 pattes. Ca arrive rarement. Le duo Steve Jobs et Steve Wozniak est interessant, à ce sujet : Steve Woznaik est un monstre de la technique(hard et soft), Steve Jobs était un monstre sur tout le reste(design, relation client, marketing, gestion, leadership, mauvais humeur, pulls pourris.....). Mais essayer de faire comme Steve jobs, c'est, hum, prétentieux et suicidaire. Pour rester poli.
Par contre, il peut être à l'écoute, et s'améliorer au cours du projet(ou de la maintenance). Ma collègue qui se farcit le domaine métier depuis 10 ans commence à sacrément bien le connaitre, et c'est fort utile. Mais on ne lui demande pas de décisions métier.
Et tout le monde passe par une MOA, qui est supposée faire écran, pour éviter que les programmeurs ne soient insultés toutes les 10 minutes. Résultat, les programmeurs sont insultés toutes les heures par la MOA. Il parait que c'est un progrès.
Ca, c'est de l'édition de logiciel. Tu vas chercher le métier, ça n'est pas le métier qui vient à toi(comme pour un forfait ou la banque machin te demande de faire un gestion de tiers exactement ciblée pour les clients de la banque machin et que la banque truc ne pourra pas réutiliser). Dans tous les cas, il te faut des experts métiers, effectivement, qui sont rarement les programmeurs(mais ça arrive : Zuckerberg ou Spolsky utilisent leur propre camelote en interne; Spolsky développe un suivi de bugs, et un gestionnaire de projets, choses qui aident beaucoup dans son propre travail).
Ce qui permet d'être toujours à jour.
Ce qui fait fuir le client. Les données harcodées, si elles sont fausses, il ne va voir que ça. A la rigueur, on met les données "pas encore validées" en gris italique, histoire de dire "ça, c'est pas encore codé" de façon visible.Je critiquais, mais je précisais que "c'était très nettement accéléré par rapport au cycle traditionnel"
Enfin bien sûr que si que tu peux avoir des écrans sans compiler : des mockups papiers, faits avec divers softs, spécialisés ou non (même Word) , ou à la main, ou dessinés sur une tablette, ou autre.. sans rien derrière..
Ou, comme mentionné, avec des données hardcodées, dans aucune foncton derrière..
C'est bien ce que je supposais...
??? je ne comprend pas..
Si c'est l'UTILISATEUR qui fournit les données..
Les cas de tests, les "use-cases" des méthodologies, c'est pas l'utilisateur qui fournit les données ??
En tous cas moi c'est ce que je fais..
Par exemple dans le soft médical dont j'avais parlé, on n'était pas, de loin, relié aux labos d'analyse. Par contre, plusieurs patients et plusieurs cas avaient été hardcodés, avec leurs suivis, leurs prescritpions, etc etc.. et ça ça se suivait.. Il y avait donc des demandes d'analyses.. Les résultatss, fournis par le médecin responsable, avaient été hardcodés. Du coup, nous avions pu produire une démo pour le salon international où le logiciel a eu un prix, et du coup tester en temps réel avec les clients potentiels..
C'est aussi à ça que sert le Groupe d'utilisateurs ou l'Utilisateur-Expert à mi- ou plein temps..
Des vraies données ayant du sens pour le métier...
En fait, il y a deux choses. Tant qu'on a pas accès à un vrai référentiel, on met en place des données en dur, des bouchons. Il est évidemment plus confortable/efficace/professionel d'avoir des données réalistes. Si on peut, c'est parfait. Parfois, on ne peut pas. Et là, il ne faut pas jouer au kakou.
(.../...)
De plus, certains clients peuvent croire, en voyant un prototype semblant fonctionnel, que tout est déjà prêt.(mais cette remarque est surtout pertinente pour du client unique. Pour du multi-clients comme tu fais, c'est sans doute moins important/vrai/pertinent). Donc il ne va pas comprendre pourquoi il te faut encore trois mois de développement, alors que c'est déjà fini : la preuve : tout marche devant ses yeux. Si tu as une charte graphique qui fait sauter aux yeux les éléments pas encore terminés, alors le client-qui-paye verra tout de suite ou il en est.
ça ne s'applique pas partout, hein, mais face aux gens que je pratique, ça peut être fort utile.
Es-tu en train de me dire que vous faites un logiciel manipulant des données sans avoir de vraies données de test, avec de vraies valeurs réelles ayant du sens, mais que vous utilsez des valeurs "que vous imaginez" ???????
C'est normalement fait directement au niveau du recueil des besoins... donc au départ..
Et cela quelle que soit la méthodologie utilsée... bien que justement avec une approche agile, cela puisse être fait "au coup par coup", puisque normalement un utilisateur est là..
L'agilité, dans les domaines bancaires, c'est souvent du voeu pieux.
ça arrive. Oui c'est moche. Exemple immédiat; je travaille pour une petite banque, filiale d'une grande banque. On a mis en place un outil marketing(je passe les détails, c'est probablement confidentiel). Pour tester, j'ai directement pointé sur le référentiel de production(parceque je n'en ai pas d'image réaliste ailleurs). Ainsi, la MOA a pu présenter au métier des choses réalistes dès les premiers essais.
La banque-mère veut faire la même chose. Je suis amené à les conseiller pour éviter les, hum, "écueils" que nous avons pu rencontrer. Dans le chiffrage que je dois évaluer, il y a marqué, explicitement, "bouchonnage : 2 jours". Je connais un peu la banque-mère, et je sais qu'ils vont tester sur des environnements vides à pleurer, avec 3 clients non représentatifs qui se courent après. Donc les programmeurs vont inventer des données bidon pour pouvoir tester l'enchainement des programmes de création de l'outil marketing.
Et la MOA va donc échanger avec les utilisateurs finaux sur des données bouchonnées(autant dire bidonnées). C'est atroce, hein..... mais ce sont les vraies conditions de travail de mes collègues de la banque-mère. Pires que les miennes, qui sont déjà suboptimales, pour rester poli.
A mon sens, d'ailleurs, des données "inventées" peuvent être utiles au niveau du test unitaire : on créée de toutes pièces de quoi tester chaque cas possible, et on vérifie tout. Dès l'intégration, par contre, il faut, à mon sens, disposer de données complètes, avec une volumétrie réaliste, histoire de trouver tout ce qui nous avait échappé au départ. Quand c'est interdit, eh bien il faut s'adapter - et adapter sa communication.
Atroce, tu le dis..
C'est vraiment bizarre.. Dans mes expériences industrielles, personne ne pourrait imaginer faire ce genre de choses.. Les impacts sont trop grands..
Je sais pour avoir été - brièvement - dans une banque, que en général le budget info n'est pas "séparé" en tant que tel, mais pris directement sur le budget de onctionnement général (bien que ça ait pû changer depuis le temps, avec les différentes lois passées)
Ceci explique peut-être cela (à l'époque, il y avait 90% de prestataires à temps plein sur une équipe interne...et la manière dont le budget était compté était déjà la cause)..
Tout à fait d'accord, à la volumétrie près...
La première des choses est de faire un logiciel correspondant au besoin. Ensuite, et ensuite seulement, suivant le type d'usage et la contrainte d'implantation / de temps, diverses optimisations peuvent voir le jour : logicielles, matérielles, ...
Mais on ne peut penser à optimiser qu'une fois que le reste marche correctement... Au cas où... Et que de plus cela peut prendre du temps d'optimiser de manière absolue (budget pour acheter des machines plus puissantes connu à la fin de l'année budgétaire, décsion d'augmenter le débit du réseau dans 2 ans, plusieurs algos en concurrence mais du domaine de la recherche...)
Alors utiliser une volumétrie "correcte" est nécessaire, tester en cours de développement "ordinaire" avec une volumétrie maximale est contre-productif.. à mon avis..
Mon expérience est que le problème est inverse : tout est budgetisé dans différentes cases. Il y a un budget pour le projet, et un autre pour les environnements de tests. Et chacun est indépendant. Comme les environnements de tests n'ont de budget que de fonctionnement, mais pas pour être plus réalistes, eh bien ils restent tels qu'ils sont. Quitte à faire des projets bien plus couteux. Mais il y a toujours du pognon pour les projets, parceque ça, c'est vendable, ça fait progresser la banque, alors que des environnements de qualification dignes de ce nom, c'est juste vu comme une dépense.....
En plus, à fin de "sécurité", la tendance est que les données d'homologation doivent être anonymisées pour ressembler le moins possible aux données de production(merci Kerviel). Donc, la MOA peut présenter au métier un outil marketing ou monsieur Gadzojp Gfuuqf se voit proposer un produit d'épargne de gamme supérieure. Le "métier" a parfois du mal à prendre son rôle de validation au sérieux, dans ces conditions.....
réponse d'ingénieur : ça dépend. Si le traitement prend, en prod, 36 heures(c'est le cas pour mon voisin d'en face), passer toute la prod pour un test unitaire, c'est évidemment du suicide. Si par contre il prend 10 minutes, ça peut valoir le coup de passer les 300 000 enregistrements du mois précédent, et de comparer. il m'est arrivé de tomber sur des bugs rarissimes, comme ça. J'attendais 1 seul enregistrement de différence, j'en ai eu 9. Sur 300 000. Sur volumétrie réduite, ça se loupe. Et comme je n'ai pas d'homologateurs ici, j'aurais eu une anomalie de production.
Pour ce qui est de "premature optimization is the root of evil", on peut aussi éviter d'être idiot. Des trucs "simples" d'optimisation, genre "si l'appel précédent à ce module très couteux d'accès aux données avait les mêmes paramètres d'appel, on renvoie la même réponse", spécialement dans un batch, ça peut sauver beaucoup, en coutant presque rien. Evidemment, choisir une écriture obscure parcequ'elle fait gagner 10% de temps de calcul avant même de s'être assuré que ça marche bien, c'est casse-croute.
95% de mon boulot actuel(ça a été fort différent), c'est des batches de 1 à 10 minutes qui traitent des centaines de milliers d'enregs. Ca vaut vraiment le coup de passer un coup toute la volumétrie de production, histoire de vérifier tout. Avec un outillage de comparaison avant/après. Dans d'autres circonstances, ça peut être suicidaire(mon voisin d'en face qui ne fait que du relationnel, et dont les temps de traitement se compte en heures, a fortement interêt à tourner sur des volumétries réduites, précisément pour les raisons que tu cites). Si je tourne souvent sur la volumétrie de prod, ça n'est généralement pas pour optimiser les perfs, mais pour être sur d'avoir bien raclé les fonds de tiroir des cas exotiques.
Et encore, j'ai connu une boite ou certains contrats ne passaient qu'en Juillet, d'autres en Avril..... Il me fallait passer toute l'année(soit 12 traitements) pour être sur de ne rien oublier.
Je partage cette idée, il me semble d'ailleurs que les tests unitaire permettent de s'assurer que tout fonctionne comme il faut donc l'application devrait être capable de gérer des données complètes sans trop de risques.Dès l'intégration, par contre, il faut, à mon sens, disposer de données complètes, avec une volumétrie réaliste, histoire de trouver tout ce qui nous avait échappé au départ.
ou alors nous n'avons pas la même définition de ce qu'est un TU, mais non, un TU ne permet pas ça : un TU teste si la fonction fait ce qu'elle est censée faire, pas si les données qu'elle ressort ont un sens.
Tout à fait, c'est une bonne guideline, à respecter le plus souvent, avec une forte valeur pédagogique, mais elle n'est pas à prendre au pied de la lettre. Un développeur expérimenté peut en principe distinguer les efforts légitimes d'optimisation prématurée de ceux qui vont nuire au code et au développement.
Je comprends que ce ne soit pas nécessaire, mais ce n'est pas inutile.
Du moins autant que louer plutôt qu'acheter ses locaux.
Je te confirme qu'on ne se comprend pas.Arfffffffff....
C'est là où se situe l'incompréhension..
On est entièrement d'accord.
Là je comprends pas
Si un TOUT représente la réalisation d'un produit (du recueil au support), il n'y a rien de systématique. On peut ou on ne peut pas. On veut ou on ne veut pas.
Comme je le disais en première réponse, on peut louer ses locaux ou bien les acheter. C'est un choix stratégique.
Non pas nécessairement, et bien au contraire, Un "éditeur" vit sur la vente de son produit. Ca ne semble pas stratégiquement viable de "perdre" de l'argent en sous-traitance.
C'est comme si un pâtissier avait une idée de gâteau (au mieux une recette), et payait (avec une marge) une liste de commis pour élaborer la recette et produire N unité(s) avant de les vendre.
Sur le fait que le premier a une spécification, et que l'autre généralement non.
Quel nom et fonction donnes-tu à "celui qui est en charge du logiciel" ?
Une SSII ne fait pas que de l'écriture de code ... Elle fait de la TRA, l'AMOA, de l'écriture de spécification, du support technique et/ou fonctionnel, etc.
J'irai même plus loin à dire que tout projet devrait fonctionner de cette manière.
Tu m'oteras pas l'idée qu'un client qui signe les yeux fermés n'a pas une part de responsabilité ...
Ensuite, pour le problème du c'est possible de faire mieux : on peut soit s'en remettre au prestataire et esperé qu'il fasse tout bon. Cependant tu l'auras constaté toi même dans la vie, on ne peut pas faire confiance aux gens ; tu vas voir un médecin, un garagiste, un plombier, un dentiste, un développeur, tout ce que tu veux, on finit toujours par se planter.
Ou sinon tu fais appel à plusieurs prestataires pour des parties différentes (découpage verticale : serveur, client, etc.) ou des activités différentes (découpage horitonzale : recueil du besoin, spécification, conception, etc.).
Ou encore, tu utilises du consulting/AMOA/etc qui sauront juger et te synthétiser les impacts des solutions proposées.
Le feeling, s'il marche bien dans la même direction que moi, la réputation, je teste, je mets deux confrères en confrontation (avocat, notaire).
Si tu as besoins de gens d'exception pour faire un logiciel, et qu'ils sont rares alors faire du logiciel devient rare ; et la production s'étale infiniment dans le temps au fur et à mesure que les besoins s'entassent.
D'autant plus que, je le répète, ils ne sont pas nécessaires pour la viabilité de la plupart des logiciels.
10 personnes ne pourront jamais produire plus de 10j/h par jours ... Donc en temps linéaire ils ne peuvent pas faire mieux. En termes de consommation en revanche, je te concède qu'ils iront surement beaucoup plus vite et faire mieux.
Tu confrontes deux mondes qui ne partagent pas les mêmes contraintes, les mêmes plans, etc. Par exemple, dans l'industrie tu as standards. Tu peux également ne pas pouvoir profiter de travaux que d'autres ont réalisé. Les équipes ne travaillent "que" 8h par jour. Tu as des deadlines, des marges, des décisionnaires, des actionnaires, etc.
Ensuite je t'invite à lire les quelques statistiques sur le coût des projets qu'on voit apparaître sur les "forges" récentes. Tu verras que la petite bande de clampins qui bossent de temps à autre (presque histoire de s'amuser), bah mine de rien ils consomment énormément.
Enfin je pense que personne n'imagine Torvald, Zuckerberg, Stallman et Jobs travaillant ensemble
Je suis d'accord sur le principe de procéder par itération. Mais toujours pas besoin d'être agile.
Et cela n'enlève pas le problème qu'il faut rédiger le besoin, le spécifier, le concevoir et le développer. Autant d'étapes de traductions obligatoires.
Peut-être pas excellent dans tous les domaines mais capable de produire quelque chose de convenable c'est possible.
Pas besoin d'avoir un traitement journalier qui prenne 1s au lieu de 10s ... De plus ce que produit un non-expert n'est pas nécessairement optimisable. La caractéristique d'un débutant n'est pas de faire quelque chose de tout le temps pourris, tout comme la caractérisque d'un expert n'est pas de faire quelque chose de systématiquement bien fait. La réelle différence est dans la proportion de chose bien faite.
Des contraintes juridiques, d'organisation, de financement sont de bons critères
Et si chaque utilisateur place un item différent dans son TOP10 des demandes, tu fais quoi ? Idem si leurs listes sont vides ?
Concrètement, un utilisateur est rarement impliqué dans l'élaboration et l'évolution de son logiciel. Ce dernier est souvent perçu comme une contrainte. Nous les informaticiens en sommes de bons exemples. Je prends les dix développeurs de mon bureau, on a 10 façons différentes d'utiliser notre IDE et 10 visions différentes de l'IDE parfait.
Tu compares des consommateurs qui ont le choix de ce qu'ils achètent et font ça sur leurs temps libres et à des utilisateurs qui vont subir le logiciel et qui vont manquer à une société qui les emploie ...
Ceci dit je retiens tout de même l'idée du groupe d'utilisateur. Si jamais je dois gérer un projet avec une certaine liberté, je pense que ca apporte un réel plus. Le soucis c'est de "récolter" ce groupe. Et il faut également juger de la pertinence de ce groupe en matière de taille, d'impartialité, de réprésentativité, etc.
Si tu fais les tests d'intégration, en même temps que le recueil des besoins, ca doit être de l "eXtreme Programming" :p
Quand je disais "ça ne compile pas", je parlais pas d'abscence de code mais d'absence d'erreur de compilation ...
C'est toujours bien mais pas toujours possible : confidentialité, sécurité, ou même politique (exemple : pour nos exemples on prenait souvent des données Air France, sauf que ça n'a pas plus à Air France qui trouvait qu'on les mettait trop en avant, ni à Emirates qui trouvait qu'on était trop chauvin).
D'ailleurs dans ton cas, sauf consentement des patients, c'est interdit.
Dans un (mini-)cycle en V, ca dépend de où tu te situes dans la chaîne. L'intégration et la recette ne sont pas affaire des développeurs.
Désolé souviron34, si je te quote beaucoup
Concernant l'optimisation précoce, on le fait tout le temps inconciemment. Mes sources de données se présentent de telles manières, je dois faire ça avec et réaliser ces sorties alors je le ferais comme ça. Tout dépend ensuite du degré d'abstraction, d'intégration, de distance, de confiance et de conaissance/compétence.
lol je ne répondrais pas aujourd'hui, mais juste sur ça :
Pas du tout, il suffit que les données soient "anonymisées" (par exemple pour les radios ou examens IRM ou scanner, une fonctionalité est "d'anonymuser", c'et à dire simplement mettre du "blanc" sur le nom de famille. : age, sexe, prénom peuvent rester..
En attendant la réponse de Souviron.... quelques éléments sur quelques points.
+1. C'est le point sur lequel je suis d'accord avec toi contre Souviron. Un éditeur de logiciel, c'est Fog Creek Software qui vend son gestionnaire de bugs 20$ par mois et par poste a des zillions de clients. Un prestataire, c'est Cap Gémini qui répond à un appel d'offres de SFR pour refondre son référentiel clients(et le prix est confidentiel). Le prestataire répond à un beosin exprimé officiellement par un et un seul client, l'éditeur répond à un besoin pas forcément exprimé d'un nombre intéressant de clients.
euh, trop de négations m'a coulé. Mais moi, même les yeux ouverts, je suis incapable de savoir si mon médecin est un charlatan.
Non au premier point parceque les meilleurs vont bien plus vite - si on leur fout la paix. 50/50 sur le deuxième. Sur la plupart de mes projets, un programmeur "bof" était supposé suffire - y'a ka suivre le petit manuel et la grande spec. Dans tous les cas sauf un, il y a eu des moments ou il fallait être créatif. Très créatif. Et très vite.
sauf que 6 jours de Paul Graham, ça te fait plus que 6 mois de moi-même. ou 6 ans d'un médiocre. O 6 siècles d'un incapable.
Mais ils ont des équipes qu'ils ont monté eux-mêmes(en tous cas Zuckerberg et Jobs). Et pas composées de gnous. ça n'est pas un hasard.(.../...)Enfin je pense que personne n'imagine Torvald, Zuckerberg, Stallman et Jobs travaillant ensemble
Sauf qu'un type un peu bon peut tout simplement repenser le problème. Ca m'est arrivé. On m'avait demandé de faire, dans un délai très court, une conversion de 18 formats de fichiers, qui avaient des similarités. On m'avait dit "bon, tu commences par les 3, là, c'est ta priorité. Le reste ça peut attendre". Ben j'ai fait les 18 d'un coup, parceque c'était industrialisable. Bon, mes 1500 lignes de Cobol, Paul Graham les aurait fait en 15 lignes de LISP. Mais l'idée, c'est que le talent ne va pas seulement plus vite : il est capable de reformuler les problèmes dans un sens plus efficace.
Avec une subtilité supplémentaire : pour les gens qui font la maintenance, c'est une catastrophe. Il y a un incident de prod sur la carte numéro 4988 8888 8888 8888. On corrige. On veut tester. Comment on retrouve ce numéro de carte dans la base d'intégration si tout celà est anonymisé?
L'intégration, si : il s'agit de mettre ensemble tout ce qu'on fait les gens, et de le faire tourner jusqu'à ce que ça tourne impeccablement(du point de vue des développeurs). Les composants unitaires, eux, ont été testés unitairement auparavant, mais la confrontation avec l'ensemble du système est souvent....instructive.
L'homologation/validation/recette, elle, est une mise à disposition des non programmeurs pour qu'ils s'amusent à casser ce que l'on croit incassable. Généralement, ça casse assez vite...
Mais si on a pas fait correctement les tests unitaires, ou l'intégration, les homologateurs font alors aussi ce boulot là, et c'est couteux tant en termes de charges que de délai. C'est ce que j'ai connu chez le client qui bouchonnait tout en developpement.
l'idée, c'est que ça n'empiète pas sur le bon fonctionnement du programme. Ca doit marcher. D'abord. Si ça ne coute quasiment rien(en termes de charge, de délai, mais aussi de lisibilité) d'optimiser, alors pourquoi pas? Mais dès que c'est couteux, ça doit attendre.
Pas en France ... Je viens de vérifier le code de déontologie et tout ce qui figure dans le dossier médicale d'un patient nécessite son accord.
Je continuerai toujours de penser qu'un client qui signe les yeux fermés a une part de responsabilité.
L'avantage du médecin c'est qu'il ne peut pas pratiquer s'il est mauvais, donc le droit d'exercer représente déjà une assurance.
Cependant, tu peux comparer le choix d'un prestataire avec celui d'un artisan ; soit tu prends le premier qui vient, tu lui laisses trois mots sur que tu veux et tu signes la facture. Dans ce cas, il ne faut pas pleurer si ça ne correspond pas à ce que tu souhaites.
En revanche, tu peux prendre plusieurs rendez-vous, bien lui expliquer, shématiser le résultat attendu et échanger autour des solutions/attentes de chacun ...
Dans le monde de l'entreprise, on te fout jamais la paix, tu as des délai incompressibles (ex : les gens qui prennent des congés). Ensuite je reste sceptique sur le "bien plus vite" ; plus vite avec une certaine mesure mais ils font pas de miracles. Et en admettant qu'il fasse en 10 jours ce que d'autres font en 100. Si tu as 5 000 jours à produire par an, bah il faut tout de même 500 jours / an ... Alors sauf si le gars prends pas de congés, ni week-end et qu'il bosse 12h par jour, tu as des jours qui s'accumulent et comme c'est du temps linéaire, les délai grandissent à chaque "projet".
Désolé mais je n'ai ni Torvals, ni Stallman sous la main et pourtant ca m'empêche pas d'avoir un taux de satisfaction client excellent. On a même eu le droit a un audit car on avait pas assez d'anomalie par livraison, et pas assez de livraison par version ... Google et la débrouille sont nos meilleurs amis
Si tu penses que le plus grand des génies peut faire en 6 jours ce que tu fais toi même en 6 mois, tu as juste un problème d'ego. T'inquietes t'es pas si mauvais que ça
Voir deux quotes plus haut sur mon raisonnement concernant la rentabilité des génies et le temps linéaire.
A la différence c'est qu'ils ont le choix de leurs équipes. Un peu comme Google. Quand tu as beaucoup de prétendant tu peux faire la fine bouche.
Sauf que le LISP ca ne fonctionne pas sur MVS/Pacbase ? Et est-ce que Paul Graham peut apprendre le COBOL (en tant que langage, pure syntaxe), assimilé ses principes/idiomes, et réaliser les 1500 lignes, les tester et assimiler l'environnement (client, OS, etc.) en quelques jours ?
"Repenser le problème" fait partie pour moi de l'optimisation. J'ai des spéc qui me décrivent le cheminement "humain" pour faire une recherche. Si j'exécute cette séquence sans exploiter les outils à ma disposition (pointeurs, index de bdd), je pars dans le mur. Si un développeur ne synthétise pas la moitié de ce qu'on lui demande, il n'est pas simplement "moyen", il est "ultra mauvais". Et là je te l'accorde, il mettra 100x plus de temps pour faire moins bien que n'importe quel développeur (génie ou pas).
Là c'est du support ou suivi de production. A ce stade tu as accès aux données de production. Le travail d'analyse commence alors par "isoler les données et le scénario" ou "réduire le problème à sa plus simple expression" (Voir le principe E-C-M dans ma signature).
Dans ce cas c'est le boulot d'un intégrateur. Dans les "petites structures", c'est souvent le développeur qui le fait mais pas toujours mais parce que l'équipe est largement étalé sur le cycle en V. D'où la nuance "où tu te situes dans la chaîne" ;-)
La recette, en général, c'est tu mets le client devant l'application et tu lui dis : "Allez vas-y, utilises la !"
Sauf que les tests unitaires ne testent pas la volumétrie ou alors ils peuvent reposer sur des pré-conditions fausses. Par exemple, on me dit dans un fichier tel couple de données est unique. On test tout va bien. Ensuite l'équipe d'intégration fait des tests avec des données réelles (mais partielles) et là c'est le drame.
Tout dépend de ce que tu appelles "Ca doit marcher. D'abord".
Je dirais "Ca doit être utilisable. D'abord".
Si durant la navigation de l'utilisateur tu dois faire des calculs et que ces dernier prennent un temps phénoménal, alors il faut repenser la solution et refondre certaines parties du système.
Mais le bon commercial va t'emberlificoter, et te faire croire qu'il a la solution à tous tes problèmes. Si tu n'as pas la culture qui va bien, tu n'as pas les moyens de résister. Voir la discussion sur SAP dans la taverne...
Sauf que l'architecture autour augmente de manière plus exponentielle que linéaire. Si j'ai 4 gars qui bossent à vitesse 10, je leur colle un chef de projet et basta. Si j'ai 40 gars qui bossent à vitesse 1, je suis obligé de monter une infrastructure énorme pour gérer les priorités, les affectations, les budgets, je passe mon temps à leur poser des questions, et ils passent leur temps à se coordonner plutôt qu'à bosser. La taille(tant du projet que de l'équipe) est le premier ennemi du développeur informatique.
"débrouille". Ah ben voilà. Le mot est laché. tu as une équipe de gens compétents, et tu attribues l'excellence de leurs résultats à la qualité de vos process.Désolé mais je n'ai ni Torvals, ni Stallman sous la main et pourtant ca m'empêche pas d'avoir un taux de satisfaction client excellent. On a même eu le droit a un audit car on avait pas assez d'anomalie par livraison, et pas assez de livraison par version ... Google et la débrouille sont nos meilleurs amis
J'ai vu mon beau-frère bosser. Il m'a rendu humble. Et pourtant, y'en a pas des masses que j'ai vu piger plus vite que moi, mais lui, il est juste dans un autre plan de dimension. De ce que j'en ai lu, Paul Graham aussi.Si tu penses que le plus grand des génies peut faire en 6 jours ce que tu fais toi même en 6 mois, tu as juste un problème d'ego. T'inquietes t'es pas si mauvais que ça
Voir deux quotes plus haut sur mon raisonnement concernant la rentabilité des génies et le temps linéaire.
Et quand tu payes les gens au lance-pierres à bosser dans des open-spaces bruyants, et que tu exiges d'eux qu'ils remplissent 50 formulaires inutiles(plus un ou deux utiles, mais on ne les voit plus tellement ils sont perdus dans le flot de paperasse), et que tu leur fournit des outils de travail de l'âge de pierre, non, tu n'auras pas beaucoup de prétendants.
C'était une boutade pour illustrer mon point principal(même si j'aimerais bien avoir du LISP sous MVS) : un type doué et créatif va pondre un truc bien plus efficace (et bien moins couteux) qu'un type normal.
Je me répète : tu as une équipe bien meilleure que ce que tu ne le crois.
ça, c'est quand on te donne les moyens de bosser. Pour pouvoir voir les fichiers de production, moi qui fait beaucoup de maintenance, je dois demander une autorisation spéciale à mon N+2, et la justifier. Et cette autorisation est limitée à quelques jours.
Plus généralement, c'est bien d'isoler le problème, mais si tu ne peux pas vérifier que tu as correctement isolé le problème, alors tu as un problème. Et c'est mille fois plus facile de faire tourner un coup "pour voir" en intégration qu'en production.
Jamais vu d'intégrateur. Mais effectivement, ça peut coller.
j'ai souvent vu une étape intermédiaire ou les homologateurs(chez les gens sérieux) ou la MOA(chez les rigolos) passaient d'abord. Mais oui, ça se termine généralement par un lacher d'utilisateurs, d'abord limité, puis massif, sur l'appli. Avec souvent des surprises, négatives(le truc fait tel que demandé qui ne convient pas du tout, joie du cycle en V) comme positives(les gens qui utilisent le bétatest comme si il était définitif tellement il est mieux que la solution précédente, malgré l'absence de fonctions clefs. Vécu récent).
"sauf"? Je crois qu'on est d'accord, en fait(avec un vocabulaire différent semble-t-il) : il faut distinguer TU et intégration, dont le périmètre et les outils sont différents. Et oui, à l'intégration, on a déjà des surprises(on en a à chaque étape, en fait).
Sauf que si c'est faux, l'optimisation, on s'en fout. D'abord, c'est juste, et ensuite, c'est utilisable. Moi aussi je peux optimiser des traitements faux, il suffit de bouchonner la réponse en dur(ne pas rire, j'ai vu des forfaits écrire en dur les réponses au cahier de tests contractuel au lieu de développer la fonction).
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager