tag:blogger.com,1999:blog-3376917260887862531.post6028443498364410156..comments2023-03-11T00:13:38.503-08:00Comments on Coding spree: Comment réanimer un projet de développement logiciel laissé pour mort - Retour d'expérience - Partie 1Anonymoushttp://www.blogger.com/profile/05191254362615174903noreply@blogger.comBlogger16125tag:blogger.com,1999:blog-3376917260887862531.post-68048254889575086972017-10-16T01:02:24.202-07:002017-10-16T01:02:24.202-07:00Si tu te sens motivé, je t'invite à mettre la ...Si tu te sens motivé, je t'invite à mettre la main à la pâte :)Anonymoushttps://www.blogger.com/profile/05191254362615174903noreply@blogger.comtag:blogger.com,1999:blog-3376917260887862531.post-8839106029175320872017-10-08T15:02:53.488-07:002017-10-08T15:02:53.488-07:00Bon, et cette deuxième partie, c'est pour aujo...Bon, et cette deuxième partie, c'est pour aujourd'hui, ou pour demain ?<br />Ça fait 1 an et demi que je fais F5 sur cette page sans rien voir arriver de nouveau...<br />En plus, je trouve que ce qui suit est bien plus intéressant : du sauvetage au naufrage :-/Gérald ROUSSELhttps://www.blogger.com/profile/08068366498157698109noreply@blogger.comtag:blogger.com,1999:blog-3376917260887862531.post-64819889612884170962016-05-23T15:28:13.092-07:002016-05-23T15:28:13.092-07:00Intéressant ;)Intéressant ;)Anonymoushttps://www.blogger.com/profile/05025806847815426799noreply@blogger.comtag:blogger.com,1999:blog-3376917260887862531.post-60226427313201610082016-04-11T03:38:49.830-07:002016-04-11T03:38:49.830-07:00Salut Emilien,
Oui, je comprends. Trouver le moye...Salut Emilien,<br /><br />Oui, je comprends. Trouver le moyen de transférer ce qu'il y a dans le cerveau de C (qui est A, en fait) vers le logiciel, dans une approche qui lui convienne (donc un RAD), et qui ne soit pas une torture pour nous non plus, ça a été un soucis permanent durant la première année. Avec cette question récurrente : "mais quand va t-il nous rejoindre ? C'est lui qui a tout dans la tète" - ce qui n'arriva jamais.<br /><br />Aujourd'hui je regrette de n'avoir pas appliqué une stratégie qu'on avait évoqués : faire un clone, strictement un clone de V6. Toute la doc était alors déjà là, sous la forme d'un logiciel qui marche : on se serait formés à V6, et refait un à un chaque formulaire, avec des évolutions cosmétiques grâce à WPF (ou WinForm, ou "blop-blop"), qui auraient déjà fait la différence, l'effet WOW. Je penses qu'on aurait moins souffert, bien que cela ne résolve pas nos problèmes de processus qualité, pour lequel tu as poussé, à juste titre. Cela nous aurait évité de se perdre dans la définition du produit et dans la complexité du FrameWork dont je découvrait les exigences par étape - exigences totalement dictées par les fonctionnalités du générateur d'application originel ! - et arriver plus rapidement justement à la question de nos pratiques, notamment sur les tests.<br /><br />Oui mais voila, à refaire, tu veux refaire mieux, plus grand, plus ambitieux, plus puissant, et à l'époque, des bases de données avec réplication temps réelle ou différée, avec concurrence pessimiste et orientée objet, il n'y en avait pas, ou pas beaucoup. Ok, mais était-ce notre métier ? Ou plus exactement, saurions nous faire les deux ? Difficile, quand on voit la complexité de l'application métier, qui nécessitait à elle seule une focalisation extrême...<br /><br />Il est certain qu'aujourd'hui j'adopte des approches plus horizontales, en investissant dans le découplage (évolution, tests), et de l'aspect quand je ne peux faire différament, et en produisant de la valeur métier tout de suite - ce dernier point étant essentiel.<br /><br />Il faut payer pour apprendre. Difficile de "faire le baron" après ça. C'est pour cela que je dis à Aurélien, il faut y aller doucement quand même : c'est très subjectif, et il faut vraiment avoir été au centre des décisions pour comprendre tout ce qu'il s'est passé... ;-)Anonymoushttps://www.blogger.com/profile/16864070134551140717noreply@blogger.comtag:blogger.com,1999:blog-3376917260887862531.post-52743951391965077322016-04-11T03:08:33.980-07:002016-04-11T03:08:33.980-07:00Yo Gaby,
Celui qui a dit ça c'est Aurélien su...Yo Gaby,<br /><br />Celui qui a dit ça c'est Aurélien sur son blog, et c'est le ressenti que j'avais de C. au moins à l'époque. Je pense que ça bien évoluer depuis cela dit.<br /><br />C'est cette idée de framework qui poussait dans ce sens, et je me rapelle de longues discussions sur fond de "recette des pains aux chocolats: ça peut être long de trouver la recette mais après tu peux en faire à la chaîne"<br /><br />En tout cas je ne faisais pas ce commentaire par rapport à toi ou Aurélien, mais plutôt en pensant à C. :)Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-3376917260887862531.post-57542413417145317972016-04-05T09:52:14.894-07:002016-04-05T09:52:14.894-07:00Salut !
"un stagiaire que tu payes 10k te fa...Salut !<br /><br />"un stagiaire que tu payes 10k te fait ton application" : Qui a dit ça ?<br /><br />Personne. Pas moi. Aurélien spécule totalement là dessus. Je ne sais pas quelle est l'intention d'une description aussi caricaturale, mais ça craint.<br /><br />Le fait est que le processus de recrutement pour trouver le développeur à 5 pattes, après avoir évacué les historiques qui étaient inadaptés, prouve précisément l'inverse :<br />- entretient d'une demi heure à une heure ou je faisais parler de le développeur<br />- passage par un test de culture générale, développement, programmation objets sur papier : 1 h<br />Si stisfaisant :<br />- 4 heures de test réel sur la machine, avec un micro projet à faire<br /><br />Est-ce que c'est la description "d'un stagiaire que tu payes 10k te fait ton application" ? Précisément, non. Après, ils ont décidé d'acheter Novealis et ont récupéré les devs, sans m'en parler ! C'est normal ça aussi ???<br /><br />Revenez sur terre, les gars !Anonymoushttps://www.blogger.com/profile/16864070134551140717noreply@blogger.comtag:blogger.com,1999:blog-3376917260887862531.post-89981963668080689572016-04-05T04:20:08.250-07:002016-04-05T04:20:08.250-07:00Merci pour le feedback. Je relève aussi quelques i...Merci pour le feedback. Je relève aussi quelques inexactitude mais tu as eu le courage d'essayer de résumé tout ça et c'est deja pas mal.<br />Pour moi le meilleur résumé de tout çà c'est"un stagiaire que tu payes 10k te fait ton application".<br /><br />Je pense que c'est une source profonde de tous ces déboires, car ca en dit long de la considération faite aux développeurs... Et pour un éditeur de logiciel c'est forcemment dommage :)<br />Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-3376917260887862531.post-81533148124940860752016-01-24T16:38:03.223-08:002016-01-24T16:38:03.223-08:00Hello Pierre !
"Déduire un framework d'u...Hello Pierre !<br /><br />"Déduire un framework d'une application qui est un succès aurait été une meilleure stratégie." - tout à fait d'accord. C'est ce qu'il se passe pour beaucoup de frameworks ou de technos qui émergent. Une équipe a le temps de faire un truc nouveau, appliqué d'abord brutalement à une application, puis le rend générique une fois mature (et c'est rarement un full-stack-replacement).<br /><br />Le mélange des genres fut une terrible idée : faire un environnement RAD, par mimétisme avec 4D - car le deal, c'était qu'A. puisse développer avec nous, en apprenant .NET, l'approche framework était aussi à l'origine faite dans ce but, en plus de résoudre tous les problèmes de synchro inter-site (virer Citrix), de connexion internet, de rechercher un vrai plus architecturale, et faciliter des aspects infra (choses qui ne sont pas mentionnée dans l'article d'Aurélien). Puis les choses ont changé, plusieurs fois, avec de sévères déconvenues...<br /><br />Etre seul sur un truc aussi gros, aussi critique, qui détermine totalement tout le reste, c'est quelque chose que je ne ferais plus jamais : c'est un risque considérable. On a besoin de pairs, de control, de certitudes, d'avis extérieurs, d'une équipe, pas d'encouragements ou de phrases du type "tu es le meilleurs, on croit en toi - tu vas y arriver" : ça réponds à aucun doute, à aucun critère de quoi que ce soit (qualité, maitrise, feedback, test, planification, directive... rien, nada, niet), c'est au contraire pousser à l'erreur celui auquel on dit cela, sans s'en rendre compte (il n'y avait aucune mauvaise intention là dedans) c'est un piège. Pour peu que l'égo s'en mêle, et on a tous les ingrédients du plantage : puisqu'on me disait que j'étais la bonne personne, alors j'ai cherché à remplacer tout ce qui manquait (du management, une méthode, un plan, du formel, des développeurs) par ce qui fait ma spécificité, à savoir ma capacité à concevoir des systèmes complexes.<br /><br />Vous n'imaginez pas la remise en question qui résultat de cet échec pour moi. J'ai mis du temps à trouver quelque chose à mettre à la place de tous les vides abyssaux et le désarroi que j'ai ressentis tant de fois durant ces 3 ans... Puis sortir du Burn Out, puis reprendre confiance dans mes capacités sans non plus se raconter d'histoires - faire le point sur mes lacunes, mes points forts, mes pratiques. Passer du statut de "super développeur" à "oups, on s'est trompé" (limite, "on s'est fait avoir"), c'est juste terrible !<br /><br />Donc oui, il fallait une approche fraiche, nouvelle, cassant avec toutes les mauvaises pratiques, c'est évident. Je pense (j'imagine) que GG a aussi pas contribué à faire cette transition, étant dans la boutique de longue date.<br /><br />J'ai aussi une pensé particulière pour le premier concerné : A. (...)<br /><br />Après cette expérience, il est certain qu'on en sort tous plus forts. Un développeur (et à fortiori un pseudo chef de projet) qui ne connait pas l'échec (de prêts ou de loin, qu'il en soit totalement responsable ou un simple participant), fini par être dangereux.<br /><br />Aurélien, te fais pas de bile : expliques ce que tu crois juste d'expliquer, comme tu l'as vécu. Ca m'intéresse de savoir ce que vous avez mis en place - le changement de culture à due être drastique !<br /><br />;-)Anonymoushttps://www.blogger.com/profile/16864070134551140717noreply@blogger.comtag:blogger.com,1999:blog-3376917260887862531.post-25102511938172059612016-01-15T15:40:36.262-08:002016-01-15T15:40:36.262-08:00Hey Hey,
Je suis content que tu ai entrepris la r...Hey Hey,<br /><br />Je suis content que tu ai entrepris la rédaction de cet article, cela a dû te coûter de te replonger dans cette époque un petit peu sombre.<br /><br />Faisant parti des développeurs "nouvelle recrue" issue de la fusion, je n'ai pas eu la vision d'ensemble du projet de ces débuts, jusqu'à son échec, et cet article me permet de mieux comprendre les décisions qui l'y ont amené.<br /><br />Je trouve que tu as complètement la légitimité de rédiger cet état de faits Aurélien, vu ta position passée et actuelle.<br /><br />Après réflexion, je suis très content que ce projet est été un échec. Il nous a tous permis de faire un réel bon en avant en terme de méthodologie et design de code. Aujourd'hui, je considère que cette épreuve m'a apporter beaucoup de maturité dans la conception d'un projet, même s'il reste encore beaucoup de chemin à parcourir.<br /><br />Quand tu dis : "A mon sens, le gros problème de ce projet n’est pas technique comme tout le monde le croit, mais managérial". Je ne suis pas tout à fait d'accord. Je pense que c'était les deux. Le parti pris de créer un framework maison sur lequel se reposer pour construire l'application, n'était pas une bonne stratégie d'entrée. Déduire un framework d'une application qui est un succès aurait été une meilleure stratégie. Il est vrai que l'aspect managérial n'a rien amélioré, et nous a même empêcher de prendre le recul nécessaire pour constater ce que nous faisions.<br /><br />Hâte de lire la suite ;)Pierre Gillonhttps://www.blogger.com/profile/13924528524973985481noreply@blogger.comtag:blogger.com,1999:blog-3376917260887862531.post-85666321432912182742016-01-13T10:03:00.582-08:002016-01-13T10:03:00.582-08:00Oui, je suis bien d'accord avec toi sur ces qu...Oui, je suis bien d'accord avec toi sur ces quelques points (post-it, crier plus fort, etc), ils relèvent du bon sens. Et qu'il ait fallu faire évoluer les pratiques me semble tout à fait évident, Aurélien. Et encore plus important je penses, délimiter les périmètres et clarifier les responsabilités, mettre des pare-feu, gérer les pratiques les plus élémentaire de management.<br /><br />Si cela n'avait pas été nécessaire, il n'y aurait pas eu de problème, ou moins, ou sur d'autre plans...<br /><br />Je ne cherche pas à t'enlever la moindre légitimité, et j'ai été heureux d'être libéré de ces multiples charges. :-) Je ne critique pas ce que tu ou vous avez faits ensuite, je critique le procédé, ou même la posture, consistant à articuler l'avant et l'après selon le seul critère des personnes, de l'ambiance, d'un historique assez flou et partiel, donc partial, et d'un folklore presque naif basé sur des origines obscures et presque manipulatoires du projet, de prises de décision légères basées sur la crédulité ou la camaraderie... Car à te lire, c'est ce qui s'est passé.<br /><br />Je connais ton langage fleurie. Mais attends, tu ne pensais tout de même pas que j'allais pas mettre mon grain de sable ?<br /><br />Tu me connais, merde. ;-)<br /><br />En la matière, je préfère des observations précisément méthodologiques : ce qu'il n'y avait pas, ce qui manquait, les erreurs commises vis à vis d'un référentiel, etc...<br /><br />NOTE : ce qui a motivé Alain à aller vers une sorte de RAD avec moi, c'est aussi EZ-World, une très vieille techno que j'avais codé en 1997 (un environnement d'exécution pour Mac) ou j'avais entièrement codé le moteur d'interface graphique et ses outils de design directement dans le soft (on prenait un bouton, on le déposait dans la fenêtre, on lui attribuait une fonction, un nom, une source de données, etc), pour lui c'était une sorte d'outil idéal... D'ailleurs, aujourd'hui n'importe quel IDE le fait. Il avait présenté cette techno a 4D a Paris, à l'époque... ;-)<br /><br />C'est donc c'est une très longue histoire.<br /><br />Je lirais avec plaisir la suite ! ;-)<br /><br />A bientôt.<br />Anonymoushttps://www.blogger.com/profile/16864070134551140717noreply@blogger.comtag:blogger.com,1999:blog-3376917260887862531.post-3652751016620647482016-01-13T07:59:30.981-08:002016-01-13T07:59:30.981-08:00Re-salut :-)
Contrairement à ce que tu peux laiss...Re-salut :-)<br /><br />Contrairement à ce que tu peux laisser entendre, je pense avoir toute la légitimité pour parler de cette expérience, car non seulement j’étais là avant, pendant, mais j’étais surtout là après. <br /><br />Le fardeau dont tu te plains du poids m’a bien été transféré, et il m’a été livré avec un bon gros sac à dos plein de cailloux.<br /><br />Là où tu te fourvoies, c’est que pour rebondir il a fallu complétement désapprendre et faire désapprendre ce que beaucoup pensaient être des choses acquises. <br /><br />Par exemple, une conception logiciel n’est jamais terminée, bouger des post-it sur un tableau, ce n’est pas faire du SCRUM, laisser une équipe se débrouiller seule n’est pas un concept de l’agilité, se parler avec des métaphores n’est pas de « l’ubiquitous language », passer des semaines entières à faire des estimations n’est pas une activité à forte valeur ajoutée et crier sur les gens pour qu’ils avancent plus vite n’est pas du management.<br /><br />Je ne m’attarderai pas sur le sujet, car je pense que cet espace de commentaire n’est pas l’endroit approprié pour ce genre d’échanges, aussi je t’invite à me contacter directement par email si tu désires continuer à débattre.<br /><br />En tout cas, je serais heureux de te compter parmi mes lecteurs lors de la sortie du prochain billet qui, à mon sens, sera beaucoup plus intéressant que celui-ci :)Anonymoushttps://www.blogger.com/profile/05191254362615174903noreply@blogger.comtag:blogger.com,1999:blog-3376917260887862531.post-72734194905314330322016-01-13T04:43:51.648-08:002016-01-13T04:43:51.648-08:00---> suite :
Dans l'expérience que nous av...---> suite :<br /><br />Dans l'expérience que nous avons vécus ensemble, le fait est que :<br />- a un an et demi du démarrage du projet nous n'avions plus de programmeur du tout : on était deux, et seulement deux, et déjà débordés !<br />- la technologie de base de données distribuée commençait à marcher correctement au moment ou on a décidé de l'abandonner (et c'était un choix rationnel, car entre marcher et être mature, il y a un monde)<br />- l'ensemble des concepts métier ont été transférés du dir. R&D (le héros) au chef produit, puis a l'ensemble de l'équipe durant les 3 premières années du projet - c'était le temps nécessaire à apprendre le domaine et constituer "l'ubiquitous language".<br />- la conception du logiciel était quasiment finie au moment de la décision de rompre le projet dans cette version - même si derrière la couche de donnée a été totalement refondue pour augmenter le découplage et passer en SQL.<br />- l'apprentissage de SCRUM avait été fait un an avant l'échec final, bien des concepts de l'agilité étaient intégrés...<br />- les solutions aux problèmes managériaux n'attendaient qu'un constat d'échec pour pouvoir être mise en place via une rupture de continuité du projet<br />- lors de la tentative de déploiement finale, personne n'avait foi dans le logiciel : le consensus était que nous avions 1 chance sur 10 que cela se passe bien... autant aller se pendre.<br /><br />Ne le prends pas pour toi, mais ce que je veux dire dans le fond, c'est que l'histoire est toujours écrite par les vainqueurs : même s'ils ont vaincu grâce à l'échec des autres et en bénéficiant de leurs erreurs, ils sont toujours tentés de la conter à leur gloire, et de prétendent avoir été vertueux bien avant que le conflit n'éclate. C'est humain !<br /><br />Je t'invites juste à faire l'état des lieux de la manière la plus rationnelle et factuelle possible pour raconter l'avant et l'après, et ta véritable responsabilité, sans oublier de dire "nous" ou "on". Le manager héros est un mythe. Il y a des susceptibilités à gérer, l'apaisement est nécessaire.<br /><br />Bonne rédaction pour la suite ! ;-)Anonymoushttps://www.blogger.com/profile/16864070134551140717noreply@blogger.comtag:blogger.com,1999:blog-3376917260887862531.post-89356191301232537642016-01-13T04:39:13.970-08:002016-01-13T04:39:13.970-08:00Oui, bien sur, tout retours d'expérience est u...Oui, bien sur, tout retours d'expérience est utile : les témoignages sont souvent très éclairants. Mais...<br /><br />Je dis que c'est périlleux quand on prétends avoir résolu des problèmes dont on n'a eu ni la responsabilité, ni dont on à vécu la génèse, ni fait l'expérience du processus de détérioration qui mena à l'échec, ni été sous la pression des questionnements stratégiques qu'il a fallut traiter... comme tu le dis, tu n'étais finalement pas vraiment partie prenante, et encore moins en responsabilité !<br /><br />Pour écrire ce genre d'article-témoignage, tu as deux situations :<br /><br />1) Tu es en responsabilité sur le projet qui a échoué et que tu l'as fait renaitre de ses cendre en corrigeant tes propres erreurs : le témoignage ne peut être que sous la forme d'une auto-critique, et d'un travail de recentrage qui a alors une valeur inestimable car tout chef de projet ou décideur peut se retrouver à devoir faire son auto-critique, remettre en cause ses croyances et méthodes - bref, faire ce qui est le plus difficile à faire, c'est à dire comprendre et admettre ses erreurs.<br /><br />2) Tu n'est pas en responsabilité sur le projet qui a échoué, car tu as été plus ou moins participant : tu peux alors expliquer ce que tu as voulu corriger, les faits, les processus, les techniques, etc. Mais ton témoignage ne peut aider que partiellement le chef de projet ou le décideur dans l'impasse, car les facteurs sont multiples et ton témoignage n'est pas une auto-critique.<br /><br />suite ---->Anonymoushttps://www.blogger.com/profile/16864070134551140717noreply@blogger.comtag:blogger.com,1999:blog-3376917260887862531.post-15635591217650020212016-01-12T11:08:52.091-08:002016-01-12T11:08:52.091-08:00Salut Gabriel, et merci pour tes commentaires !
E...Salut Gabriel, et merci pour tes commentaires !<br /><br />Effectivement, faire un retour d’expérience au bout de 3 ans est un exercice assez difficile. Que ce soit pour se remémorer les évènements, l’interprétation qu’on en fait, l’oubli des détails, … sans compter la contrainte de devoir faire court pour ne pas perdre les lecteurs.<br /><br />C’est sûr que j’ai dû faire l’impasse sur pas mal d’explications, mais je pense avoir formalisé l’essentiel des choses telles que je les ai vues depuis ma lucarne. Cet article n’est qu’un point de vu parmi d’autres et j’imagine que beaucoup de personnes pourraient apporter leurs pierres à l’édifice.<br /><br />Mais là n’est pas la question. Si j’ai écrit cet article, ce n’est pas pour décrier l’incompétence de telle ou telle personne, mais pour introduire le prochain article qui va traiter de team building, méthodologies, approches de développement, etc. <br /><br />Comme je n’aurais jamais pu m’intéresser à tous ces sujets si je n’avais pas vécu l’expérience que je décris dans ce billet, il est important pour moi de raconter cette histoire.<br /><br />Aujourd’hui, beaucoup de gens parlent de scrum, kanban, mvvm, tdd, solid, leadership, intégration continue, … car la communauté des développeurs s’accorde sur le fait que ce sont des principes qu’il faut suivre pour qu’un projet de développement logiciel soit sur la bonne voie. Mais combien ont réellement vécu une expérience qui légitime la mise en application de toutes ces méthodes ?<br /><br />Voilà pourquoi j’ai décidé de prendre le sujet à bras le corps. Je pense que ce retour peu éclairer des décideurs dans le doute, et j’espère que mon prochain article finira de les convaincre qu’il devient plus que nécessaire de revoir notre façon de penser lorsque l’on s’adonne à un projet de développement logiciel.<br />Anonymoushttps://www.blogger.com/profile/05191254362615174903noreply@blogger.comtag:blogger.com,1999:blog-3376917260887862531.post-69765785784953496272016-01-12T08:26:52.439-08:002016-01-12T08:26:52.439-08:00- Suite -
Hors, j'ai été un cavalier seul. Et...- Suite -<br /><br />Hors, j'ai été un cavalier seul. Et plutôt que d'employer mes visions en les mettant au service de l'équipe, j'ai cru, a tord, que mettre mes compétences au service de l'objectif stratégique, compétences les plus spécifiques (capacité de conception, approches alternatives, programmation), était plus important que de trouver avec intelligence le moyen "faire monter tout le monde dans le train", et le mieux possible (au départ, il n'y avait personne). La résilience d'un projet de développement tient au nombre des personnes qui sont capables d'en refactorer le code : or, sur le framework, j'étais seul responsable - ce qui est contraire à toute approche AGILE (l'équipe est responsable) - et sur la partie métier, il n'y avait pour ainsi dire personne !<br /><br />En cela, ceux qui raillaient mon approche trop exclusive, notamment en utilisant une techno propriétaire, avaient raison : cela créé une zone d'exclusion de tout le reste de l'équipe, alors qu'une techno commune extérieur créé au contraire une zone de ralliement.<br /><br />Comme tu l'explique bien, j'étais capable de faire vite et bien, mais seul - et le dir. R&D l'avait saisie une fois en déclarant, avec tout le tacts qu'on lui connait : "mais tu ne sais pas travailler en équipe". Quand un développeur chevronné se plante, les premières questions à se poser est de savoir s'il est adapté au contexte, à sa mission, a sa responsabilité et le contexte est-il adapté à lui : en d'autres termes, il est au service de quoi ? La management ? Le produit ?<br /><br />Il fallait investir dans une équipe et des méthodes, et non pas exclusivement dans un RAD - et l'équipe a mis longtemps à naitre. L'approche hyper novatrice est utile quand on fait un "one shot" sur un projet qui doit briller, mais s'il s'agit de créer un produit sur le long terme, c'est bien l'investissement dans l'équipe et les méthodes qui garantit la solidité du projet. Vouloir combiner les deux, intégrer un extraterrestre techniquement au service d'un produit long terme, est l’apanage d'équipes qui fonctionnent déjà, qui sont donc capables de les contrôler en les suivant dans leur vision, ce qui n'était évidement pas le cas de cette entreprise au moment ou nous y sommes arrivés !<br /><br />Voila, pour une réaction à chauds. ;-)Anonymoushttps://www.blogger.com/profile/16864070134551140717noreply@blogger.comtag:blogger.com,1999:blog-3376917260887862531.post-19151908602950307152016-01-12T08:26:06.133-08:002016-01-12T08:26:06.133-08:00Salut Aurélien,
C'est un exercice périlleux a...Salut Aurélien,<br /><br />C'est un exercice périlleux auquel tu t'adonnes là !<br /><br />Prit isolements, les faits relatés sont vrais. Et en même temps tout un tas de détails déterminants, comme les délais pris par les pieds (que peut-on faire en 2 ans ?), l'impossibilité du dir. R&D d'avoir les moyens de rejoindre réellement le projet (ses limites en management, sa fatigue et les conflits récurrents avec son associé), le profil de chacun, les problèmes d'organigramme (chef de projet, vraiment ?.. jamais vu noté nul part...), les changements de techno en cours de route, les développeurs historiques non adaptés, etc. sont autant de détails qui rendent ton point de vue hautement subjectif !<br /><br />Pour moi, si la base technique, l'étendue du produit, le mode cow-boy de tous et l'absence d'intégration continue / tests automatisés de la première version furent les causes de l'échec, le travail de conception et de transfert du cerveau du directeur de la R&D ver l'équipe s'est réellement fait durant les 3 premières années - et c'est ce qui a permis ensuite, en corrigeant les choix techniques et managériaux, de re-développer le logiciel rapidement ! Rappel toi de la pieuvre...<br /><br />Certains événements ont représentés un véritable traumatisme. Ce type de descente aux enfer, ou plus on s’enfonce, plus les solutions s'éloignent, ont été vécu par un grand nombre d'équipes - d'ou ce graphique déjà vieux et bien connu de la gestion de projet d'un cycle en V finissant par la promotion des non participants. Durant cette période de l'histoire de l'entreprise, nous avons tous payé pour apprendre. Si je conserve mes approches techniques singulières, ma vision d'un travail en équipe à totalement changé, grâce notamment au passage à SCRUM.<br /><br />Ce que je retiens de cette expérience, c'est qu'une équipe doit être homogène, et que des périmètre exclusifs d'importance ne doivent pas exister, de sorte que les erreurs (et limites) d'un homme ne remettent pas en cause l'ensemble du projet. Personne ne doit être irremplaçable, tout du moins dans la durée : une personne, une expertise particulière peut être nécessaire ponctuellement, mais la mise en oeuvre doit être accessible à toute l'équipe. Quand bien même nous avions pu mettre en oeuvre toute la stratégie que j'avais définie, le fait qu'elle repose techniquement sur un seul cerveau était de toute manière une erreur. Fallait-il le vivre pour le comprendre.<br /><br />En d'autres termes : seule on va plus vite, mais a plusieurs on va plus loin.<br /><br />Anonymoushttps://www.blogger.com/profile/16864070134551140717noreply@blogger.com