Accéder au contenu.
Menu Sympa

progliste - Re: [progliste] application trop complexe dès le départ

progliste AT framalistes.org

Objet : Liste sur la programmation tous languages, orienté déficients visuels

Archives de la liste

Re: [progliste] application trop complexe dès le départ


Chronologique Discussions  
  • From: Yannick Daniel Youalé <mailtoloco2011 AT gmail.com>
  • To: progliste AT framalistes.org
  • Subject: Re: [progliste] application trop complexe dès le départ
  • Date: Sun, 20 Aug 2023 17:36:51 +0100
  • Authentication-results: rod3.framasoft.org; dkim=pass header.d=gmail.com header.s=20221208 header.b=rXXV3AvJ; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (rod3.framasoft.org: domain of mailtoloco2011 AT gmail.com designates 2607:f8b0:4864:20::b32 as permitted sender) smtp.mailfrom=mailtoloco2011 AT gmail.com

Salut Quentin,

Merci, ton avis me touche beaucoup.

Je crois que je vais suivre ton conseil et plutôt que de m'adresser
directement à la direction, je vais plutôt me retourner vers mon
équipe pour en discuter, et voir ce qu'il en ressortira.
Pourquoi pas même saisir l'occasion d'une réunion avec l'architecte
attitré pour évoquer aussi pertinemment que possible le sujet.

J'ai lu un jour ce conseil d'une vieille personne: "L'homme
intelligent, c'est celui qui sait revenir au carrefour et prendre une
autre voie. L'orgueilleux et l'incrédule, lui, maintient sa
trajectoire même s'il aperçoit au loin un ravin."

Bon dimanche!

Yannick Daniel Youalé




Le 20/08/2023, QuentinC<progliste AT framalistes.org> a écrit :
> Salut Yannick,
>
>
> Je ne crois pas que ce soit la compexité de l'application en elle-même
> le problème. Docker, le queue messaging, le cloud, l'architecture
> microservice, ce sont toutes des choses qui commencent à être bien
> connues et qui fonctionnent bien quand on les maîtrise. La performance
> et la fiabilité de ces systèmes ne sont plus à prouver.
>
>
> Par contre si dans votre équipe il n'y a personne qui maîtrise bien
> telle ou telle technologie, s'il y a des "trous", effectivement, c'est
> compliqué. Il y a tellement de choses que c'est difficile pour une seule
> personne de tout savoir dans son ensemble dans les détails, et on ne
> s'improvise évidemment pas architecte d'un jour à l'autre.
>
>
> Je pense donc que le problème, c'est que votre équipe a une trop grande
> marche à franchir entre ce qu'elle connaît et maîtrise bien
> actuellement, et ce qui est demandé.
>
>
> Pour maximiser ses chances de réussir, il faut introduire les nouveautés
> progressivement et non pas les aborder toutes en même temps, et pour
> introduire les nouveautés progressivement, il n'y a pas de miracle, il
> faut se donner du temps pour les apprendre. Sinon effectivement, vouloir
> tout faire en même temps, c'est le meilleur moyen de foncer dans le mur.
>
>
> Au moment où vous avez reçu le projet et ses exigeance, il aurait très
> certainement fallu en parler à vos supérieurs, et leur dire que ça
> faisait trop d'un coup pour vous et/ou qu'il faudrait recruter tel ou
> tel spécialiste pour vous aider à vous lancer. Ils devraient savoir
> quelles sont les compétences de chacun, et donc plus ou moins savoir où
> sont les trous, mais c'est aussi à vous de leur dire où sont vos limites
> et ce que vous pouvez supporter.
>
>
> Maintenant que vous avez accepté la mission, par contre, ça me parait
> difficile de revenir en arrière sans que vous soyiez perçus comme des
> incompétents. Plus le temps passe, plus ça sera difficile de discuter,
> donc mieux vaut malgré tout quand même essayer sans trop tarder. Par
> contre, il faut absolument que vous y alliez en équipe, ou en tout cas
> une partie de l'équipe. N'y vas pas seul, sinon ça sera probablement toi
> le con; du moins c'est comme tu le sens, si tu te sens prêt à affronter
> la hiérarchie seul contre tous et qu'elle te fait assez confiance,
> vas-y, mais moi j'aurais beaucoup de mal à le faire.
>
>
> Dans le pire des cas, si tu en souffres et que tu es vraiment tout seul,
> le mieux, c'est encore d'aller voir ailleurs... c'est triste, mais c'est
> comme ça... laisse-les se casser la gueule tout seuls.
>
>
> Voilà, ce n'est évidemment que mon avis tiré de seulement 6 ans de
> boîte, d'autres auront sûrement des autres points de vue.
>
>
> Dans tous les cas, bonne chance.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Le 20.08.2023 à 03:29, Yannick Daniel Youalé a écrit :
>> Salut à tous,
>>
>> Je voudrais aujourd'hui venir vous soumettre une situation que je
>> rencontre en entreprise.
>>
>> Il se trouve que la direction nous a ordonné, à l'équipe de
>> développeur à laquelle j'appartiens, de créer une application de
>> gestion d'évènements, qui est destinée à être proposée en SAAS à des
>> clients.
>>
>> Dès lors, dans notre équipe, l'informaticien qui a reçu le rôle
>> d'architecte, nous a commandé les caractéristiques suivantes pour
>> cette nouvelle application:
>>
>> * elle devra se subdiviser en micro-services.
>> Autrement dit en plusieurs sous-projets, hébergeable sur des serveurs
>> distincts, et communiquant entre eux par des requêtes dites queue.
>>
>> * selon les sous-projets, nous pourront les faire en soit: laravel,
>> jango, ou même nextJS.
>> J'ai même entendu parlé de java, même si je crois que ce dernier a été
>> abandonné en fin de compte.
>>
>> * La base de données devra être gérée en PostGreSQL, et sera hébergée
>> sur microsoft Azure.
>>
>> * nous devrons employer docker pour gérer les déploiements et
>> redéploiements.
>>
>> Moi, n'ayant jamais travaillé sur un projet aux envergures aussi
>> ambitieuses, j'ai dans un premier temps décidé de taire mes
>> rétissances, et de suivre le mouvement afin de voir comment les choses
>> évoluent.
>>
>> Et, après un peu plus d'un mois de travail en équipe, nous en sommes
>> toujours à finaliser la première étapes de notre plan d'action, qui
>> est de faire fonctionner la communication entre les différents
>> micro-services.
>>
>> Donc, plus d'un mois et demi après, nous n'avons pas encore commencé à
>> travailler véritablement sur le coeur de l'application que nous devons
>> construire, mais nous évertuons en réalité à employer notre énergie à
>> apprivoiser les différentes nouvelles technologies que nous devons
>> mettre en oeuvre.
>>
>> Personnellement je ne trouve pas ça correct, et pense que le délai qui
>> a été donné à la direction de produire un MVP de l'appli de gestion
>> des évènements pour la fin du mois de novembre, ne sera pas atteint.
>> Tout ça est trop ambitieux pour une équipe de seulement trois
>> développeurs à temps plein.
>>
>> Moi, je pense que si on avait commencé dès le départ à faire le plus
>> simple possible, c'est-à-dire un simple projet laravel, avec le type
>> de base de données MySQL fournie par défaut, nous serions à l'heure
>> actuelle beaucoup plus avancée.
>>
>> Je ne renie pas le démembrement d'une telle application en
>> micro-services, ou l'emploi de technologies tierces comme PostGreSQL
>> ou docker, mais je pense que ce genre de sophistication doit se faire
>> à la fin du projet, lorsqu'on est sûr que le prototype ou coeur de
>> l'application fonctionne convenablement, et que l'on a de ce fait
>> donner des assurances à la direction de ce à quoi l'application
>> ressemblera et comment elle fonctionnera au final.
>>
>> Ainsi, rendu donc à près de six semaines après le commencement
>> effectif de notre phase de développement, il me démange d'aller voir
>> la direction pour leur faire part de mon avis.
>>
>> Mais j'hésite. Je me demande s'il n'est pas déjà trop tard.
>> Et ce serait probablement aussi perçu comme de la trahison par mon
>> équipe.
>>
>> Equipe avec laquelle, j'ai bien essayé une ou deux fois de faire
>> allusion à ce que je pense vraiment, mais chez qui je n'ai pas senti
>> de volonté de véritablement remettre en question la direction vers
>> laquelle nous sommes en train d'aller.
>>
>> Or, je sens bien de la part de la direction, une certaine impatience à
>> ce que ce projet avance.
>> Car, quand on entend dans une réunion des expressions de cette
>> direction comme: "est-ce que nous sommes en train d'aller quelque
>> part?", ou encore: "faites des efforts les gars", on comprend qu'il y
>> a un besoin pressant de voir plus de choses concrètes.
>>
>> Qu'est-ce que vous en pensez?
>>
>> Pensez-vous que je devrais aller voir la direction pour lui soumettre
>> mon idée de revenir à des choses plus simple et de se concentrer sur
>> le coeur de fonctionnement de l'application d'abord?
>>
>> Avez-vous déjà vécu une telle situation?
>>
>> Je vous remercie d'avance pour toute suggestion.
>>
>> Yannick Daniel Youalé
>>
>



Archives gérées par MHonArc 2.6.19+.

Haut de le page