Reprise du message précédent :

L'histoire est sympa mais qu'est-ce que le passé simple prend cher...

J'ai déjà eu le droit à un "C'est parce qu'on est en extrême agilité" le plus sérieusement du monde quand j'ai tiqué face à l'absence totale de specs et la demande urgente à faire pour le lendemain

Alors que la spéc est tellement importante.    Autant, je suis d'accord qu'il peut y avoir trop de doc et qu'une partie est inutile, autant, pour moi, y'a 3 documents indispensables :  
- la spec (ce que le client à demandé et comment on y répond, avec quelques schémas d'architecture, notamment le MCD si y'a une BD et le dictionnaire des données). Sans ce doc validé par le client, perso, je commence même pas à coder.
- le manuel d'exploitation (comment on installe et configure le produit).
- le manuel utilisateur.
 
Ca fait 18 ans que je bosse comme ça avec une méthodo qui mixte un peu de Scrum, d'XP voire parfois du test driven + du Lean management (même si cet aspect est plus "au-dessus" du dév) et surtout, le recueil du besoin auprès des utilisateurs finaux (ça évite beaucoup de biais ou d'incompréhensions/malentendus). Ben, pour l'instant, j'ai jamais eu de retour arrière ou de produit qui répondait pas au besoin. Au pire, des ajustements ou quelques améliorations à apporter suite au REX des utilisateurs. Donc toujours bonne satisfaction du client
Du coup, j'applique la même recette à chaque fois vu qu'elle m'a toujours conduit à un bon résultat.

Ca me rappelle un dialogue tiré de "La maison du bonheur" avec le chef des travaux qui dit en gros: "Pas besoin d'architecte, un plan, on en a besoin que lorsqu'on est perdu". Quand on voit la tronche de la maison à la fin (+l'équipe de bras cassés qui a fait le taf), tu te dis : bon, pour des gros travaux, je vais prendre un architecte et une bonne équipe    
Pour moi, la spéc, c'est le plan du logiciel. Ca représente environ 30 à 40% du temps passé sur le produit.
C'est ce que j'enseigne à mes stagiaires, l'importance d'avoir une bonne méthodo pour bosser et faire une bonne conception avant de se lancer dans le codage...

On bosse dans la même boite ?

J'en doute, ou alors, le monde est très petit   Par contre, j'imagine que ces pratiques sont répandues...

https://www.youtube.com/watch?v=0-rOqywzWEY&t=1080  
 
18ème minute jusqu'à 21ème environ, tout est résumé

Merci pour cette vidéo. Toutefois, je ne suis pas d'accord sur le coup de l'obsolescence de l'expérience des salariés. De l'expé, c'est de l'expé et tu pourras toujours t'appuyer dessus. Faut pas croire que les nouvelles méthodos ou langages de dév ou autres sortent du néant. Ils viennent de choses existantes. Donc, du coup, si tu connais les origines, tu peux raccrocher les wagons.
Ex : j'ai surtout appris OMT et très peu UML. or, UML vient d'OMT, donc ça va, je sais décoder un schéma UML grâce à mon expé OMT et Merise aussi

Ouais j'ai essayé de trouver une meilleure source pour pas avoir trop l'air d'un con en l'envoyant à mon chef, mais pas moyen

 
Nous c'est l'inverse, on a des bien des ingénieurs qualité, mais c'est des gens qui font des tests plan et implémentent des tests. Bien sur ta la spec etc, et des document qui décrivent les process, mais le but est que tout soit automatisé.
 
Quand on fait une livraison:
- run des tests unitaires: automatisé
- run des tests d'intégration écrit par les ingénieurs QA: automatisé
- checks divers et varité sonar/sécurité/version des libs/quelques benchmarks: automatisé
- run de la nouvelle version avec traffic de prod et comparaison de KPI (taux d'erreurs + mesures fonctionnelles): automatisé sur certains produits, en court sur d'autre.
- test de stabilité et performance: automatisé en nightly, encore à automatiser sur la release.
- canary testing automatisé: en projet.
- procédure de fallback à la version précédante si probléme (instantanné si demandé).
- alarmes en production: automatisé.
 
Le but c'est que le dev fait sa PR, il doit avoir un approval QA (généralement incluant des tests automatique écrit par la QA), + 2 approval dev (qui doivent revoir les changements). Des robots font tous les autres checks ou presque et quand c'est bon ça va en prod.

Ca a l'air pas mal du tout votre façon de bosser. C'est bien d'avoir optimisé un max de trucs
Vous avez l'air assez mature. Respect.

Ca a beaucoup changé en 10 ans, on était vraiment à la rue des fois, mais y'a une vrai évolution et volonté. Ca prend du temps d'améliorer, mais sur le long terme, c'est vraiment cool.

Tout à fait, c'est en général assez difficile de faire comprendre qu'il faut d'abord savoir investir (et donc perdre de l'argent dans un premier temps) pour en gagner par la suite et rentabiliser

Énorme projet en banque (énorme comme mondial, budget de l'ordre de la centaine de millions d'euros, équipes de plusieurs centaines de personnes).

Le PMO (au sens contrôleur de gestion/relevé des compteurs, pas responsables) du truc qui dit "génial avec l'agilité ça va coûter moins cher le jour/homme".

Oui c'est sûr, avec des équipes à paris de consultants formées à la va-vite que scrum et des devs indiens formés (ou pas) payés au lance-pierre qui se tiraient aussi vite qu'ils arrivaient (le recruteur sur place nous avait dit "on fait 3 propositions fermes par poste parce que il y en a 1 qui viendra pas au démarrage et 1 qui n'ira pas au bout du training initial de 15j". )

Ah bah ca le jour homme coûtait moins cher. En Inde. Parce que on a finit par prendre des équipes complémentaires à Paris. Au tarif normal. Qui ont réécrit le code des indiens. De A à Z.

Jai tenu 2.5 ans avant de burnouter.

isNaan()  

 
Les gens ne comprennent pas que les bon et expérimentés coutent moins cher que les nouveaux/mauvais, que plus un projet est gros, plus il est risqué.
 
Du coup, autant que possible on fait petit bout par petit bout avec des gens expérimentés qui connaissent le métier/fonctionnel sur le bout des doigts et qui maitrisent à fond la techique.
 
Faut souvent les paye 2X plus cher (dans le même pays), mais ça coute facile 5-10X moins cher.

On en est pas mal revenu, j'ai l'impression, de déléguer aux indiens (ou main d'oeuvre pas chère) le dév parce que la plupart du temps, le boulot est mal fait et faut repasser derrière. Du coup, ça coûte plus cher au final
Et je parle même pas des différences culturelles qui est un sacré obstacle, genre, un indien te dira jamais non ou jamais qu'il n'a pas compris ou qu'il sera en retard. C'est une fois que ça peut plus être caché qu'il te le dit. Et la, c'est trop tard

a la surprise de personne qui connaissait un peu le dev info, c'est les financiers qui nous ont tous mis dedans, et ca fait +40ans que ca dure

J'adore la petite blague !      

Pourquoi tu te limites au dév info ?   Ils ont fait du bon boulot dans le domaine de la santé, par ex (genre hôpital public)...

Y a toujours un tocard pour sortir : "Effectivement ce projet de gestion de la chaîne de desanussage de porcs est intéressant mais a-t-on vraiment besoin d'une application séparée ? On pourrait faire évoluer le logiciel de contrôle de la climatisation de la salle de réunion n°3 pour n'avoir qu'une seule application, et une application ça coûte moins cher que deux".

Le jour où les chefs comprendront qu'une voiture-sous-marin-helicoptere ça coûte plus cher qu'un sous-marin + une voiture + un hélicoptère, ma vie sera plus facile.

Et je confirme que les boîtes sérieuses utilisent un outil spécifique pour le désanussage

Oui mais plus c'est risqué et plus ça conforte l'égo chez les mâles, comme les centrales nucléaires (C. Duflot)
 
Seriez vous dans son camps, qui soutenez vous ? qui

Un téléphone-carnet d'adresses-console de jeux-navigateur internet-modem routeur-appareil photo, ça vaut plus cher qu'un téléphone + un carnet... etc...  ?  

éternel problème du coté consommateur de service et du coté fournisseur de service.
Pour le premier il vaut mieux la meme interface  
pour le second il vaut mieux separer clairement les services  

Et dieu inventa la supervision  

Celle de Superman qui voit à travers les murs et les objets (mais pas le plomb) ?

nope  
le programme d'interface centralisé qui sais dialoguer et piloter tant le desanuseur de poulpe que la machine a rayer les zebres ou le coupeur de cheveux en 4    
MAIS, qui laisse chaque machine tourner sur son propre systeme autonome a la base  
si c'est geré proprement ( je sais oui ) ca permet de faire tourner chaque partie tant separement qu'ensemble, de survivre a la panne de n'importe quel module en laissant tourner les autres  

Toutes ces fonctions sont des softwares séparés sur le [ordinateur] mobile.

C'est bien l'idée, plusieurs applications dans un seul contenant physique.

Ben tout, mon point est qu'un projet ne doit pas gérer trop de choses sinon tu multiplies les interlocuteurs, les clients, avec chacun leurs besoins et délais. Du coup il te faut des comités de pilotage de programme au dessus de tes comités de pilotage de projet

Pour le smartphone, le projet "appareil photo" est bien séparé du projet "Candy crush" et du projet "WhatsApp". Ils ont chacun leurs délais, budgets, besoins, technos, comités.

Bon après si le projet c'est d'aller sur Mars je veux bien admettre qu'il faudra faire travailler plein de gens différents sur de multiples contraintes dans un méga programme avec plein de sous projets mais je peux vous assurer que ce n'est pas ma cogip avec ses Jean-Kevin (école rang Z, 3 ans d'expérience de pisseur de code, cinq fautes par ligne) comme "chefs de projet" qui s'y colleront.

L'exemple du smartphone est trompeur. L'idée avancée par cocacolalight reste vraie.
Un smartphone fait téléphone-appareil photo-lecteur musical-modem-jeux vidéos pour moins cher que ces éléments séparés, mais hormis sa fonction primaire de téléphone, il fait tout moins bien.
N'importe quel smartphone se fait détruire en photographie par un appareil photo professionnel voir même grand public, aussi bien dans la qualité d'image que dans la fonctionnalité, la polyvalence, etc.
Un lecteur dédié à la musique aura une meilleure autonomie, plus de mémoire, un DAC dédié plus performant, etc, et ne vaut pas un clou face à une platine professionnelle.
Une simple Switch est meilleure en JV qu'un smartphone, et je ne parle pas des consoles de salon type PS5 ou Xbox.
 
Ce qui permet au smartphone de triompher, c'est qu'il permet de faire tout ça à un niveau acceptable pour 99,9% des usages et usagers, le tout dans un format de poche (qui évite d'avoir à se trimballer un sac de randonnée 50L avec ton matos photo, ta Switch, ta platine vinyle, ton groupe électrogène ).
 
Dès que le format n'est plus important, par exemple chez nous, la spécialisation reprend le dessus : un PC, une TV, une platine, une box Internet, etc.

Le PC n'est pas spécialisé, au contraire. Il fait tout mieux que les saloperies fermées (téléviseurs et consoles en tête).
 
Le mobile fait également mieux que des appareils qu'il peut remplacer si tu lui donnes le budget pour.
J'ai abandonné l'APN car les APN compact à 100 € ne font guère mieux qu'un mobile à 200 € pour mon usage.

Je crois qu'on dit tous la même chose, chacun avec nos mots : un smartphone, à l'instar de plusieurs appareils dédiés, fait plein de choses, pour moins cher, mais moins bien ! Et ça suffit à 99,9% des gens...  

Tu peux remplacer "dev info" par ce que tu veuxp

Bien sûr que non  

 
Bon exemple. A ton avis combien google/apple/samsung et les autre dépensent en R&D chaque année ? Ca se chiffre en disaines de milliard. Pourtant le nouveau modéle est en gros presque identique à l'ancien.  
 
Ils payent trés cher la maintenance et l'évolution de tout ça.
 
Ce qu'un nouveau sur le marché arrive à faire au mieux à bas cout, c'est une copie de l'existant avec des composant standard (genre xiaomi/honor/oneplus) et malgrés tout ça leur demande des années et des milliards pour arriver àau niveau des autres. Et il finissent d'ailleur par rentrer dans le rang (aussi cher et autant d'investissement que les autres).
 
Je crois pas que quiquonque pourra s'imposer avec une nouvelle marque de smartphone au niveau monde (genre passer devant Xiaomi ou Samsung) sans dépenser des disaines de milliard en R&D.
 
Et pourtant on parle juste d'un ordinateur assemblé avec des composant standard dont quelques capteurs photos et antenne reseau, rien de nouveau ou d'exceptionnel.
 
Mais faudra quand même aligner les milliards.
 
Et l'appareil photo va se faire laminer par un Canon/Sony Full frame, la saisie de note sera pas aussi fluide que sur une feuille de papier, la navigation web sera pas aussi productive que sur un  PC avec clavier souris et les app mobiles ont bien moins de fonctionnalités que les équivalent desktop.

tant que tu ne sais pas comment est organiser une filiére tu peux pas affirmer ca surtout qu'il y a plein de petit acteurs dans le monde du smartphone.
il y a 20 ans sony était considéré comme indétronable en particulier dans la filiére TV ors ils ont perdu le leadership dans leurs domaines sauf la console de jeu.

 
Je dis pas que les actuels vont pas se faire remplacer. Aprés tout Xiaomi vient justement de passer au top et Huawei est en dégringolade. Et des marques qui n'existent pas y'a quelques années comme RealMe/OnePlus se sont fait une belle place. Et plus personne ne parle de Nokia ou Blackberry.
 
Par contre, je maintient que ces produits avec de nombreuses fonctions coutent cher à concevoir et fabriquer. Plus un produit est complexe, plus les investissement en R&D sont élevés, et plus le risque d'echec est élevé. Y compris pour des gens déjà établis.
 
Ce n'est pas pour rien qu'on parle de Minimum Viable Product, qu'on conseille partout de réutiliser au max l'existant et de se concentrer sur l'essentiel.
 
A la base on venait d'une discussion sur comment gérer un projet. Et l'idée était de prendre des petites équipes de gens compétants et les faire travailler itérativement sur des changements de taille modérée.
 
Le risque croit de façon exponentielle avec la taille du projet et le nombre de personnes.

Bof on a vu des acteurs comme wiko réussir à se faire un nom en France.
Le hardware doit être bien standardisé et globalement ça doit pas être compliqué de faire fabriquer un smartphone sur cahier des charges tellement les process sont maîtrisés par les fabriquants (Foxconn etc...)

Ce qui fait la différence c'est le soft.
Sauf si tu veux innover sur le hardware évidemment.

 
Très instructive cette blague .