Ceci est un article que je vient d'écrire sur mon blog et que je propose en lecture ici pour permettre la discussion, vu que j'ai désactivé les commentaires sur mon blog
Depuis 4 ans, j’écris un MAM libre en Java. Comment arriver à ne pas se laisser dépasser par l’immensité du travail à fournir ? Un article en plusieurs parties qui sont très subjectif et relèvent de l’expérience que j’ai pu tirer avec le temps (je ne suis pas développeur de métier ni de formation).
Pour écrire du code, et construire des applications, il faut un peu avoir l’instinct de bricoleur. A force de brancher des fils entre eux, on fini par faire tourner quelque chose.
Puis avec l’habitude, on voit plus grand, plus loin. On imagine ce que l’on pourrait faire si seulement on reliait de gros morceaux entre eux. Et un jour, on ouvre un IDE, et on y va, et on se plante.
Il faudra parfois du temps, mais à un moment votre code mal pensé vous dégoûtera. Il y a un travail à faire autour du code à proprement parler sans quoi la structure ne tiendra pas très longtemps.
Déjà, il faut accepter d’avoir différentes casquettes et il faut savoir en changer quand il le faut.
Pour ce projet, je doit être :
- Ingénieur R&D : bricoler des bouts de scripts, essayer des trucs, tenter des choses, bref faire du non propre mais valider si ça peut marcher ou pas. Si vous voulez construire vous même votre voiture, assurez vous que vous arrivez déjà à faire tourner un moteur sur une batterie avant même de commencer à dessiner les plans de la voiture elle même, car une voiture sans moteur restera une boite à savon…
- Architecte logiciel : ce n’est pas bien méchant, mais avant d’avancer durablement dans une direction, il faut déjà la choisir. MySQL ? Python ? jQuery ? Comment je nomme ? Comment je structure les choses ? Bref, à chaque itération du travail je doit me poser ce type de question. C’est fondamental : vous payez très cher chaque erreur que vous ferez ici. J’ai déjà dû supprimer un mois de code car j’avais mal pensé, et sous estimé un détail fondamental qui à rendu inexploitable le reste tout autour. Ce travail est chiant car il est à l’opposé de la R&D. On aimerait tous utiliser le dernier truc à la mode… Mais est-ce pertinent là maintenant pour ce que je veux faire par rapport au reste autour ?
- Chef de projet, ou se contenir pour rester dans les clous, respecter les conventions que l’on s’est donné, dans les objectifs prévu, alors que l’on a tellement envie d’intégrer un nouveau truc mais qu’il y a quelque chose de plus urgent à faire pour le moment, comme corriger des petits bugs moches ou le script d’installation. C’est le garant qui fait avancer les choses.
- Développeur : c’est simple, on écrit du code dans le cadre que l’on c’est donné et on debugge le plus possible.
- Contrôle qualité. Le moment casse pied arrive, c’est le moment où on devient super chiant sur tout le travail déjà fait. C’est à ce moment là où on repère les erreurs faites lors des étapes précédentes. Et il faut être sans pitié. Si ça ne marche pas bien, c’est que cela ne marche pas. On ne met pas un outil dans les mains des gens si il n’est pas parfaitement fonctionnel, sinon ils auront une mauvaise image de votre outil et de votre travail que vous n’arriverez pas a leur enlever de la tête.
- Administrateur système : écrire du code, c’est bien, le faire fonctionner hors d’un environnement de développement, c’est mieux. C’est à ce moment-là que vous découvrez que la fabuleuse fonctionnalité que vous avez écrite ne marche pas sous le Linux de vos serveurs ou que vos dépendances ont des problèmes de version entre votre environnement de production et de développement. C’est tellement drôle à résoudre ce genre de problème que vous en venez à haïr votre architecte : c’est à dire vous même.
- Utilisateur. Quand vous proposez votre application à des gens, ayez la décence de l’utiliser aussi ! Encore plus si c’est une application métier comme la mienne. Et là, vous pourrez savourer le moment où vous vous demanderez « Mais pourquoi ce comportement stupide ? Quel est le génie qui à pensé ça !? Mais c’est moi ! ». Après, le plus fou sera de découvrir qu’une petite fonction de rien peut changer la vie de beaucoup de monde, au point où vous serez étonné de constater que « j’ai écrit ça en trois heures il y a deux ans et on l’utilise toujours ? »
- Marketing. J’ai dû apprendre mettre en valeur mon code, car un code, ça fait des choses, point. Tout le monde se fiche de savoir comment. Alors ces choses qu’il fait doivent être mises en avant, pour donner envie à d’autres d’y mettre les doigts dessus (utilisateurs) ou dedans (développeurs et contributeurs). Il ne s’agit pas de mentir, ni non plus de sous estimer votre travail. Après tout, vous y avez passé du temps, ce n’est pas pour rien. Montrez le ! Faites un site, une vidéo, des graphiques à la mode avec des couleurs. Le faire, ça change les idées, ça force à prendre du recul. Ça sera peut-être moche, mais au moins ça sera mieux qu’un README avec du ASCII art à la racine du Git.
- Commercial. Enfin la partie ardue. Le marketing donne envie. Le commercial agit. L’économie du logiciel libre montre qu’il n’y a d’autres façons de gagner sa vie en écrivant un logiciel que de vendre du binaire fermé et restreint. Par exemple, MyDMAM est libre et gratuit, pourquoi alors parler de commercial ici puisque qu’il y a rien à vendre ? En fait si : mon temps. Être payé pour écrire le code de son propre projet, c’est un type d’idéal. Encore mieux quand cela fait vivre plusieurs personnes. Pour ma part, je n’ai pas de business autour de mon code actuellement. Mais je sais vendre son utilisation selon qui j’ai en face de moi. Apprenez à parler de votre projet, insistez sur les méthodes élégantes que vous avez utilisé pour résoudre des problèmes impossibles. Si vous êtes développeur, ne faites pas l’autiste et employez des mots simples pour parler de votre modeste création et faites naître l’envie. C’est indispensable pour ne pas être le seul sur votre projet (ce qui est actuellement mon cas).
A chaque itération de travail (comme une nouvelle fonctionnalité), je doit redevenir R&D, puis Architecte, puis Chef, puis Dev, puis QC, puis Admin, puis Utilisateur. Et je recommence. De temps en temps un peu de Marketing. Enfin, quand je « sort » je suis plus Commercial.
# oui, mais c'est quoi un MAM ?
Posté par G.bleu (site web personnel) . Évalué à 10.
En cherchant sur internet j'ai l'impression que c'est une sorte de serveur multimedia avec de la gestion de droits… mais je n'ai pas trouvé de doc clair sur le sujet, j'ai mal cherché ?
[^] # Re: oui, mais c'est quoi un MAM ?
Posté par Anonyme . Évalué à 1.
http://hd3g.tv/b/2015/10/mydmam-reflexions-autour-dun-dmam-ideal/ Hopla ?
[^] # Re: oui, mais c'est quoi un MAM ?
Posté par Media ex Machina (site web personnel, Mastodon) . Évalué à 7.
En fait, il y a autant de définitions que d'implémentations.
Pour faire court, les "professionnels de l'audiovisuel" sont un peu bordélique. Ils aiment avoir pleins d'outils et des machins avec des fils, et ils adoraient avoir de belles bandes vidéos qu'ils mettaient dans leurs beaux magnétoscopes couteux et rutilants.
Ils confiaient les bandes à des archivistes pour les trier et les ranger, mais ça c'est chiant à faire, donc on y faisait pas vraiment gaffe.
Quand nos métiers ont lâché les bandes vidéo au profits de fichiers, ça été la panique. Ça c'est fait très vite et on c'est tous trouvé cons avec nos NAS pleins à craquer. Evidement, quand on a lachés les bandes, on a aussi largué les archivistes qui allaient avec. On a fait de super économies de m2 et de salaires.
Et donc depuis plusieurs années on rame pour ranger, traiter, retrouver nos fichiers. La demande à créer l'offre, et on c'est retrouvé avec pleins de marchants de boites noires tout-en-un-qui-fait-tour pour ça.
Ça m'a toujours gonflé de voir mes employeurs/confrères signer des gros, très gros cheques à ces gens là, qui n'ont même pas de honte à vendre des technos proprio très fermés et souvent bardé de brevets.
Quand dans le monde de l'IT pense de plus en plus "ouverture, interopérabilité, normes, bigdata…", le monde de l'audiovisuel pro n'en n'est qu'a la pré-histoire de tout ça.
[^] # Re: oui, mais c'est quoi un MAM ?
Posté par Prae . Évalué à 3.
SMPTE, AFNOR/ISO.
Cela n'a pas l'historique de l'IETF, ce n'est pas non plus la pré-histoire.
[^] # Re: oui, mais c'est quoi un MAM ?
Posté par Media ex Machina (site web personnel, Mastodon) . Évalué à 2.
Oui, tout est bardé de normes et de convention, mais ça ne suffit pas pour changer les esprits et les pratiques au quotidien. Et chacun va a son rythme.
Quand toute une industrie se transforme en 10 ans, il y a de la casse. Sans compter que l'économie autour a beaucoup changé.
[^] # Re: oui, mais c'est quoi un MAM ?
Posté par Prae . Évalué à 2.
Même si je conçois ce que tu dis, j'ai du mal à conceptualiser quand tu exprimes "ça ne suffit pas pour changer les esprits et les pratiques au quotidien. Et chacun va a son rythme". J'ai connu pas mal de changement depuis 10 ans dans l'industrie, je n'ai pas l'impression d'y voir plus ni même moins de blocage que dans une autre industrie. Mais peut-être as-tu une autre vision dessus;
Tu peux (m')en dire plus ?
[^] # Re: oui, mais c'est quoi un MAM ?
Posté par Media ex Machina (site web personnel, Mastodon) . Évalué à 2.
L'industrie de la production et de diffusion des médias, si on peut dire ça comme ça, est très vaste, parcellée de différents métiers, pratiques, cultures, de différents modèles de business, etc…
On a commencé il y a bien longtemps par des silos en béton armés : le cinéma, la radio, le théâtre, la presse écrite.
Puis est arrivée la télévision qui a commencé à mélanger les genres : mettre un tournage type cinéma dans un théatre, demander aux pros de la radio de prendre le son, et hop émettre un signal aux quelques riches qui pouvaient ce payer un poste de réception. Tout ceci était très expérimental : comment imaginer de faire de la télévision avant même l'invention du transistor…
Et puis on a évolué, au rythme des lois, des idées, des normes, des technologies.
Les métiers ont commencer à évoluer, les pratiques aussi. Depuis ça ne c'est jamais arrêté.
Quand je suis né, la télévision était tout juste en couleur, produite et diffusé en analogique sur des tubes, le cinéma en pellicule, la radio tout juste en FM stéréo. Les transmissions satellites devenaient réalité pour la télé. La presse écrite était la référence pour l'information dans les radios et les télés.
Quand j'ai eu ma formation pro, la télévision était produite et tout juste diffusée en numérique, on commençait à parler de HD. La radio travaillait depuis longtemps en numérique et on commençais à parler de sa diffusion en numérique. Le cinéma post-produisait de plus en plus en numérique. La presse écrite étudiait le modèle du gratuit payé par la pub.
Aujourd'hui, on parle 4K, on grignote des fréquences TV pour de la téléphonie 4G, le cinéma est quasiment totalement en numérique, la radio installe des caméras pour faire des vidéo sur Youtube, la presse écrite à une "unité vidéo" dans chaque rédaction, on va au cinéma pour regarder de l'opéra…
Et aujourd'hui on a tous l'équivalent d'une chaine de production et de diffusion de télé/cinéma/radio/presse écrite. dans sa poche.
Alors oui, il y a de la casse. Comment imaginer que tout cela puisse ce produire, et aussi vite ? Un exemple : Sony. Ils ont fabriqué la télévision (1"C, Beta SP, Digital Betacam, et nombre de leurs moniteurs). Aujourd'hui, ils ont quasiment disparus. Merde ! J'ai été formé sur des équipements Sony, puis j'ai bossé après sur ces mêmes équipements. Et cette année j'ai du gérer deux grosses refontes dans une chaine de TV : Sony à totalement disparu. Il y a 10 ans, il aurai été omniprésent.
Autre exemple : les formations. En 10 ans on est passé d'un profil électronique à un profil informatique réseau. Dans les métiers technique de la télévision il est aujourd'hui plus utile de savoir faire un ping qu'une soudure (surtout quand on cherche du boulot).
Et d'un point de vue finances : si je dit Netflix ou Youtube, qui aurait plus penser qu'ils auraient existé sérieusement dans le paysage audiovisuel. Il y a 10 ans, l'un louait des DVD par correspondance et l'autre montrait des vidéos du singe qui se renifles les fesses. Et maintenant ? L'un produit de plus en plus de contenus "originaux" de qualité, et l'autre c'est imposé comme un acteur très sérieux et alternatif aux silos d'origine.
Bref, on pourrait donner plein d'exemples, mais en conclusion, je dirais que l'évolution que l'on vit depuis les débuts de cette industrie n'est pas prêt de ralentir, et tout ceux qui ne s'y adaptent pas vont souffrir. Les exemples ne manque pas.
[^] # Re: oui, mais c'est quoi un MAM ?
Posté par Prae . Évalué à 3.
Je rebondis après avoir lu quelques papiers sur MyDMAM: Pour l'archivage, tu tournes vers quel format ? IMF ? autres ?
[^] # Re: oui, mais c'est quoi un MAM ?
Posté par Media ex Machina (site web personnel, Mastodon) . Évalué à 1.
Rien pour l'instant.
Et je m'interdit de faire un choix fermé.
# Didactique
Posté par gUI (Mastodon) . Évalué à 5.
Très sympa ton article, il a, je pense, une énorme qualité : il montre la diversité des métiers de l'informatique. En ce moment chez nous c'est la valse des stages de 3e, et on s'attache pas mal à montrer que informaticien c'est pas uniquement développeur.
L'intérêt est d'attirer ceux (et celles) qui ne sont pas forcément attiré(e)s par la pure technique.
Et en ce qui concerne la féminisation de notre profession, c'est indispensable.
Des filles qui aiment bien l'informatique (on le voit en découverte de la programmation) ne voudront pas forcément y faire carrière, pensant que rester derrière un ordi c'est un peu bof bof (et elles ont bien raison). Mais quand on les fait assister à une réunion avec des Américains, des Chinois, des Indiens, tout en Anglais, où l'on organise le travail de plusieurs centaines de personnes, ça les branche déjà vachement plus.
Idem avec l'architecture, expliquer la foule de possibilité qu'on aurait eu, et la difficulté de choisir "à priori" la meilleure solution, c'est un challenge intellectuel qui peut être séduisant.
Sinon dans ta description, j'aurais séparé testeur et contrôleur qualité, c'est pas tout à fait la même chose. Pour moi le testeur, dans tout ce qu'il y a d'ingrat là dedans, est du niveau intellectuel d'un automate et teste ce qu'on lui a dit de tester. Ca marche, ou ça marche pas. C'est vital en matière de non-regression par exemple.
Le contrôleur qualité, lui, ne se satisfait pas forcément d'un truc qui marche, il veut également que ce soit bien fait, avec une dimension parfois non mesurable là dedans.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Didactique
Posté par Media ex Machina (site web personnel, Mastodon) . Évalué à 2.
Pour les femmes dans l'info, c'est juste culturel. Les femmes ont toujours existé dans ces métiers, c'est juste qu'elles sont très peu présentes et très peu visibles.
Avec la transformation des métiers et de leurs diversifications, la prochaine et nouvelle génération résoudra le problème de lui même car il y aura bcp plus de jobs aussi bien en quantité qu'en nature.
# Les métiers du test
Posté par Benoît Sibaud (site web personnel) . Évalué à 8.
Il n'y a pas que le pur fonctionnel qui compte en général. La doc pour l'utilisateur et/ou l'administrateur est-elle correcte ? Quelles sont les performances ou bien les performances sont-elles acceptables ? Les règles de sécurité requises sont-elles respectées ? Est-ce que ça s'intègre bien avec le reste (dépendances, empaquetage, etc.) ? Est-ce que la mise à jour se passe bien ? Peut-on faire un retour arrière ? Quid de la couverture de test ? Faut-il faire du fuzzing ? Est-ce que ça marche sur tous les systèmes prévus ? Est-ce que c'est vraiment utilisable par un utilisateur lambda ? Est-ce que ce qui n'est pas implémenté/est interdit génère des erreurs explicites et un comportement sain ? Est-ce « fonctionnel » pour l'utilisateur mais aussi pour l'administrateur système (les logs ? la supervision ? de quoi faire un service si ça doit en être un ? comment sauvegarder/restaurer les données et/ou la configuration ?). Etc.
[^] # Re: Les métiers du test
Posté par Media ex Machina (site web personnel, Mastodon) . Évalué à 1.
Mon terme de "Contrôle qualité" est peut être mal choisi ici.
Tu parle du vrai "Contrôle qualité", en tant que process industriel, et disons-le, lourd.
Je parle plutôt du compromis entre ce qui vient d'être implémenté et qui à l'air de marcher, et ce que l'utilisateur peut tolérer de dysfonctionnement. Et de fait, quand on est aussi bien dev. que user, ce compromis est très dur à obtenir.
La plupart des questions que tu soulève, j'y répondrai par du "surement… bof… j'espère…" car je n'ai pas la prétention d'arriver à ce niveau de qualité de travail, et encore moins seul.
Mais c'est bien sur un idéal que je me dirige vers.
# J'aime bien ton article
Posté par Nitchevo (site web personnel) . Évalué à 4.
Tu devrais le publier sur un blog
[^] # Re: J'aime bien ton article
Posté par Media ex Machina (site web personnel, Mastodon) . Évalué à 1.
C'est déjà fait : http://hd3g.tv/b/2016/03/lhomme-orchestre-partie-1-les-casquettes/
# Méthodes de conception
Posté par FreeFax . Évalué à 6.
Je suis entièrement d'accord avec toi sur la difficulté de remplir tous ces rôles que tu décris. Les développeurs (et les ingénieurs de manière plus générale) sont souvent passionnés par la technique et très souvent capables. Ce sont les autres aspects qui bloquent : comme tu le dis, attirer l'attention sur le projet, trouver une cible et un modèle économique viable, gérer les relations clients/utilisateurs, etc.
J'aimerais revenir sur l'aspect conception et l'exemple que tu prends de l'automobile. Je me suis assez récemment reconverti à l'informatique dans une SSII après avoir suivi des études en Ingénierie des Systèmes. Kézako ?, me direz-vous sûrement… Et bien d'après ce bon vieux Wikipédia :
Concrètement, c'est une méthodologie de conception développée initialement dans le milieu du spatial (coucou la NASA) et qui est aujourd'hui utilisée dans de nombreux secteurs (aérospatial, défense, automobile, énergie, et même pharma…).
Certes, les SSII se sont pas forcément représentative de l'ensemble des professionnels du domaine, mais les méthodes de conception que j'y vois, et surtout le fatalisme des développeurs quant à la possibilité d'avoir un process de qualité me font tomber à la renverse ! Combien de fois déjà ai-je entendu des "Non mais faut t'habituer, en info les projets c'est toujours à l'arrache.", "Ah non, te fies pas à la spéc, elle est pas à jour de toute façon.", "Le client a pas encore décidé ce qu'il veut, mais on va s'avancer". Bref, la méthode de la R.A.C.H.E dans toute sa splendeur. Mais je m'écarte un peu du sujet…
Un des principes clés de l'ingénierie système, c'est qu'un système est plus que la somme de ses interfaces avec l'extérieur (ses fonctionnalités si on veut). Les sous-systèmes/composants du système interagissent entre eux et ça a un impact sur la dynamique globale du système. On ne peut pas concevoir un système complexe en ignorant ses interactions internes. On ne peut pas concevoir en ajoutant petit bout par petit bout par petit bout puisque chaque bout amène son lot d'interactions avec les autres bouts en plus de la fonctionnalité voulue. Tu prends l'exemple de l'automobile :
Fût une époque où les constructeurs automobiles travaillaient comme ça, et une voiture mettait entre 5 et 10 ans pour arriver sur le marché. Aujourd'hui, entre la décision de sortir un nouveau modèle et son arrivée chez le concessionnaire, il peut se passer moins de 18 mois. C'est justement parce qu'on réfléchit à l'ensemble plutôt qu'à la somme d'éléments : dès le début on définit le besoin de manière exhaustive (ou on essaye en tout cas…), on conçoit une architecture qui prend l'ensemble des exigences en compte ainsi que l'impact des interactions entre les éléments de notre architecture. De là, on définit les exigences (atteignables si on a bien fait son boulot) que chaque élément/sous-système doit remplir. Puis, tout est conçu en parallèle ! Le châssis de la voiture peut être conçu en parallèle du moteur ! On n'attend pas que le moteur marche pour lancer le reste.
Fabriquer des prototypes et réaliser des tests est ce qu'il y a de plus cher, concevoir une voiture bout par bout, prototyper, tester, réitérer coûte une fortune. Pourtant, c'est ce que je vois dans le développement de systèmes informatiques : on se dit qu'on commence par un petit bout facile, puis on rajoute un petit bout, etc. Mais chaque bout/module/fonctionnalité peut potentiellement affecter le fonctionnement de l'existant, ou bien tu peux te rendre que ton architecture qui était parfaitement adaptée jusqu'alors, ne l'est plus du tout. Alors à chaque petit bout qu'on rajoute, on est obligé de revérifier l'ensemble et éventuellement corriger l'existant. Parfois, tu ne peux pas rajouter cette fonctionnalité sans réécrire une part importante de l'existant, voire tout jeter à la poubelle et repartir sur des bases saines.
C'est exactement ce à quoi je fais référence et il me semble que nous sommes d'accord là-dessus. Mais ce n'est pas une fatalité. On peut lutter contre ça, ça demande de se forcer à prendre tout le temps nécessaire pour réfléchir avant de se lancer dans du code. Si on n'a pas les compétences de le faire (ce qui n'a rien de honteux, tout le monde n'est pas un architecte logiciel expérimenté, pas moi en tout cas), il peut être bon d'en discuter avec quelqu'un qui lui a ce genre de compétences.
Pour conclure ce petit commentaire qui a tourné au roman (désolé), je ne dis pas qu'il faut travailler de manière monolithique. Je pense simplement qu'il est nécessaire d'avoir une vision d'ensemble : dès le début d'un projet, réfléchir à l'ensemble de fonctionnalités/contraintes que l'on voudra y ajouter et réfléchir dès le début à une architecture qui permettent cela. Ça ne veut pas dire concevoir une usine à gaz qui permet d'intégrer tout et n'importe quoi, juste ce qui est un besoin réel et réaliste. Puis, durant le développement à proprement parlé, même si on développe et livre module par module, avoir conscience pour chaque module qu'il fait partie d'un tout cohérent.
[^] # Re: Méthodes de conception
Posté par Media ex Machina (site web personnel, Mastodon) . Évalué à 1.
C'est bien mon approche. MyDMAM est une plateforme qui est composée de pleins de petites API (et de leurs implémentations) pensées pour travailler ensemble mais aussi en certaine autonomie.
Mon but final, en fait, c'est ça : penser une structure fiable et bien pensée qui arrivera à supporter toutes les petites idées qui vont venir au fur et à mesure. Et ça, c'est fait, ça fonctionne. Il ne reste "plus" qu'a ajouter les petites idées.
Je doit en effet mélanger l'approche pas à pas / bidouille et l'approche papier/crayon/plan. "Tenter quelque chose" versus "voir loin et grand".
Et n'oublie pas que je suis pour le moment seul sur mon ouvrage et n'ayant aucune formation ni expérience dans les exemples industriels que tu a cité. Fort heureusement, ce n'est qu'un outil pour manipuler des médias, pas déplacer des humains !
[^] # Re: Méthodes de conception
Posté par FreeFax . Évalué à 3.
C'est vrai qu'en étant seul, c'est tout aussi important de se faire plaisir pour avoir envie de continuer. Et pour ça, rien de tel que de voir les choses prendre vie, ça met du baume au cœur. :)
En tout cas, bravo pour la motivation et le travail accompli. J'espère que tu trouveras des bons conseils et l'envie de continuer !
[^] # Re: Méthodes de conception
Posté par Media ex Machina (site web personnel, Mastodon) . Évalué à 0.
Des nouveautés arrivent… Je repasserai ici monter tout cela.
[^] # Re: Méthodes de conception
Posté par ckyl . Évalué à 5.
On peut parfaitement appliquer un processus d'ingénierie classique en informatique, d'ailleurs certains domaines le font.
Mais en dehors de l'inculture crasse du secteur IT que tu décris à raison, la réalité reste qu'effectivement la majorité des produits ne sont jamais défini et ne le seront jamais. Pour de bonnes, ex: "throw again the wall, see if it stick", et beaucoup de mauvaises raisons.
Si un jour ça a été défini et que tu as fait le truc "correctement" au début, de toute façon la vision figée d'un produit ne tiendra pas longtemps. Pour tout ce qui est non life-critical, tout change constamment de manière organique. Les specs & fonctionnalités changent plus vite qu'il ne faut de temps pour simplement les écrire. Le TTM et les fonctionnalités sont un plus grand levier que la correction.
Bref, oui la majorité de l'IT est du grand n'importe quoi. Maintenant croire que ton modèle marche partout c'est aussi n'importe quoi. Il existe une grande variété d'approches pour limiter le désastre inhérent à un monde qui change constamment, on est juste assez mauvais dans toutes.
[^] # Re: Méthodes de conception
Posté par FreeFax . Évalué à 1.
Ta remarque sur les changements rapides des besoins est juste lorsqu'on développe un produit sur un marché ouvert. Les besoins des cibles commerciales peuvent changer du jour au lendemain pour diverses raisons (secteur du client très changeant, un compétiteur qui renverse le marché avec une nouvelle offre, que sais-je encore). Le besoin peut être d'autant plus changeant lorsqu'on travaille sur quelque chose de novateur. Dans ces cas, ça peut être bon et même nécessaire de se laisser de la flexibilité pour ne pas s'enfermer dans une solution qui sera déjà obsolète une fois arrivé à la fin du développement.
Dans le cas des SSII (mais je m'écarte du sujet du journal), on est dans un schéma plus classique. On a un client qui passe un appel d'offre. Le client est censé avoir un besoin concret et identifié (en partie au moins). Si on est choisi pour le projet, on est alors lié par un contrat qui devrait définir un cahier des charges précis. Toute modification du cahier des charges devrait faire l'objet d'un avenant au contrat. Si la modification demandée remet en cause l'architecture qui a été décidée et validée avec le client, c'est à lui de payer les pots cassés, d'où l'intérêt de définir correctement son besoin dès le début. Dans ces cas, il me semble qu'un processus de développement plus classiques et rigides devrait s'appliquer.
[^] # Re: Méthodes de conception
Posté par ckyl . Évalué à 2.
Je te rejoins sur le fait que les prérequis de ton approche et ceux de déléguer à une SSII sont assez proches.
Mais mon modeste avis est que sous traité à une SSII est globalement un non sens. Inadaptées au gros des besoins et incapables sur le reste.
[^] # Re: Méthodes de conception
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 2.
Est-ce que vous pourriez élaborer sur ce que signifie « Throw against the wall, see if it stick ». Pour moi, cet exemple est loin d'être évident ?
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: Méthodes de conception
Posté par Guillaume Rossignol . Évalué à 2.
Je pense que ça fait référence à une certaine démarche "On code un truc vite fait, on balance sur le marché, et on voit si la clientele colle". Si ce n'est pas le cas, on recode un petit bout à l'arrache, on rejette sur le marché, et on voit si cette fois ca colle etc.
Du coup, on ne part pas d'un cahier des charges figé et monolithe, on développe au fil de l'eau en fonction des retours.
[^] # Re: Méthodes de conception
Posté par ckyl . Évalué à 4.
https://en.wikipedia.org/wiki/Run_it_up_the_flagpole
La réalité immuable du business c'est qu'il est très difficile de savoir quels produits marcheront et la plupart des produits sont des échecs commerciaux.
Lancer une idée à moindre coût, quitte a faire des sacrifices sur une vision purement technique / ingénierie n'est donc pas forcément complétement stupide. On balance tout si jamais ça ne prend pas, et on itère / améliore / paie la dette sinon.
C'est risqué si on ne maitrise rien du tout et tout est un gros tas boue. Mais vu que l'immense majorité des produits sont des échecs ça peut aussi de minimiser le cout de tout ce qui foire.
Architecturalement, on a donc tout intérêt a mettre des jolies barrières entre ce qui fait actuellement parti de son "core domain" et tout ce qui gravite autour. Les processus et niveau de qualité attendu n'étant très certainement pas du tout les mêmes.
Comprendre la réalité de son business est donc primordiale pour chercher des solutions en adéquation avec les besoins.
# Pourquoi et comment
Posté par Kerro . Évalué à 5.
Tout le monde n'est pas de cet avis :-)
La première chose que je regarde lorsque j'aborde un logiciel : (exemple : PIWIK)
1. ça sert à quoi globalement ? (exemple : ça permet d'analyser les visites d'un site web pour améliorer le SEO, les ventes d'un site marchand, etc)
2. quelles sont les caractéristiques principales ? (modèle commercial ? Je vais obtenir quelles informations ? Ou en est-on sur la roadmap ? Ça s'interface avec d'autre chose en entrée et/ou en sortie ?)
Déjà pour avoir ces informations basiques, c'est souvent bien galère. Il est très fréquent de tomber sur un site prétendant héberger un super logiciel… sans même expliquer à quoi il sert. À la place on a un blog qui indique que la dernière version est la 5.0.4.10a et qu'on abandonne la bibliothèque truc.
Pour savoir si c'est prêt pour la production c'est généralement impossible sans tester, car le site n'indique que des choses merveilleuses (et Google n'indique rien car le logiciel est relativement inconnu. C'est un bon indice mais il y a des exceptions dans les deux sens). Et bien entendu la grande majorité des logiciels inconnus se vautrent lamentablement dès que tu touches à un bouton.
La seconde chose que je regarde :
1. ça fonctionne sur quels principes ? (Ça récupère les logs comment ? Ça les stocke quelque part ou ça les relit à chaque fois ? Ça utilise d'autres sources d'informations ?)
2. quelle est l'architecture générale ? (client lourd/léger ? Client/serveur ? CLI/GUI ?)
3. quels sont les pré-requis ? (logiciel autonome ? Il faut une base de données ? C'est tellement compliqué qu'il vaut mieux trouver une machine virtuelle toute faite pour tester ? Java ?)
Alors là c'est juste la cata : on ne trouve quasi jamais l'information.
Un peu comme si tu te pointes dans une concession automobile et que tu n'as droit qu'aux publicités télévisées. Aucun moyen de savoir quel est le carburant (diesel/essence/électrique ?), aucun moyen de connaître l'équipement. Tu ne peux même pas voir le véhicule en vrai pour « ressentir » les dimensions et le reste, tu n'as accès qu'à ce que tu vois sur la pub.
[^] # Re: Pourquoi et comment
Posté par Media ex Machina (site web personnel, Mastodon) . Évalué à 2.
Point important à ne pas oublier : mon projet est en alpha, je ne prétends pas qu'il soit utilisable actuellement out-of-the-box et j'ai pas mal de doc à faire (c'est très long à écrire). Je ne souhaite pas pour le moment écrire des choses qui vont s'avérer obsolète assez vite.
Quand je dit que tout le monde se fiche de savoir comment c'est histoire de dire qu'en prenant la totalité des utilisateurs d'un logiciel libre, combien iront voire dans le code ? Et combien même comprennent quoi que se doit au code ?
Les questions que tu poses sont légitimes, j'en réponds à certaines, d'autres pas encore, et d'autres volontairement non pour éviter que l'on se méprenne sur ce projet et sur ce que l'on peut en faire actuellement.
# Hacker news driven development
Posté par ckyl . Évalué à 4. Dernière modification le 06 mars 2016 à 21:23.
Heu non.
Vouloir "utiliser le dernier truc à la mode" rappelle beaucoup trop l'incapacité de notre industrie à apprendre quoi que ce soit.
Chercher à résoudre des problèmes de manière simple et fiable devrait finir par mener à chercher à écrire du code ennuyeux (lire sans surprise) avec des technologies ennuyeuses (lire maitrisées).
[^] # Re: Hacker news driven development
Posté par Media ex Machina (site web personnel, Mastodon) . Évalué à 1.
Dans "tous", je parle coté projet perso, ou de fait, tout ce qui n'est pas industriel, cadré, prévu.
Et mon but n'est pas de fournir du code qui servira de référence aux génération futures, mais juste un outil que j'espère pas trop mal pensé et qui peut rendre service.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.