Chronologique Discussions  

< Chronologique >       < Discussions >

---

Salut à tous,

Je reprend ce fil de discussion concernant un projet que je jugeais
trop complexe qui nous avait été soumis en entreprise.

Pour rappel, nous devions créer une application de gestion
d'évènements qui devait:

* 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 pourriont les faire en soit: laravel,
jango, ou même nextJS.

* La base de données devrait être gérée en PostGreSQL, et serait hébergée
sur microsoft Azure.

* nous devrions employer docker pour gérer les déploiements et redéploiements.

Hé bien, figurez-vous comme je le craignait, que nous n'y arrivons pas!

Suivant vos conseils, je n'avais fait part de mes rétissences d'alors
qu'à mon équipe restrainte.

Le chef d'équipe avait jugé à ce moment-là que nous nous étions trop
avancé dans les nouvelles technologies à adopter, et que nous ne
pouvions pas changer de direction après autant d'efforts fournis.
C'est pourquoi la décision a été prise de poursuivre ce qui avait été
commencé.

Mais au fil du temps, les problèmes et ralentissements n'ont fait que
s'accumuler.

A savoir:

* les requêtes queue qui n'étaient pas si facile à implémenter que ça,
et qui ont fini par nous bloquer avec un bug inextricable dans le
contenair docker.
Nous avons alors décidé de passer à de simple requêtes HTTP.

* la difficulté de communiquer entre des services/sous-projets aussi
nombreux.
Ce qui a pausé un problème de synchronisation entre ceux qui devaient
s'occuper du back end et ceux du front end.

* le fait que des fonctionnalités sur lesquelles nous étions
expérimentés comme l'authentification des utilisateurs, à cause de la
multiplicité de cessions, nous obligeait à refaire complètement from
scratch cette fonctionnalité.

* A cause de trop d'indisponibilité de l'architecte, qui est le plus
expérimenté dans cette technologie, nous avons longuement été bloqués
dans la configuration de nos comptes microsoft asure.
Et ce n'est toujours pas parfait à l'heure où je vous écris.

* etc, etc.

La réunion d'hier a donc été, je l'ai compris, un peu humiliante pour
l'architecte et le chef d'équipe, dont la responsabilité était après
cinq mois de développement, de pouvoir au moins proposer une démo
visuelle de cette application.

C'est pourquoi, après le départ de la direction des échange, j'ai
profité pour remettre sur la table mon idée de revenir à des choses
plus simples en regroupant toutes les fonctionnalités dans un projet
unique, d'abandonner docker et microsoft asure pour l'instant, de
revenir au gestionnaire de bases de données que nous maîtrisons le
plus, et de ne se concentrer que sur l'objectif de produire un projet
viable, même sit incomplet pour un début.

Nous avons une réunion tout à l'heure, et je comptais y arriver avec
une sorte de road map afin de bien définir les actions à mener pour
réorganiser ce projet logiciel ô combien complexe.

Je vous dirais ce qu'il en est!

Amicalement,

Yannick Daniel Youalé









Le 21/08/2023, Yannick Daniel Youalé<mailtoloco2011 AT gmail.com> a écrit :
> Coucou Lavachri,
>
> Merci pour ta réponse.
>
> En fait, l'architecte est en réalité un ancien employé à temps plein,
> qui travaille aujourd'hui dans une très grosse boite.
>
> Et comme tu dis, c'est peut-être ce fait qui lui joue des tours.
> Il nous voit peut-être aussi comme une grosse boite, qui doit
> appliquer des méthodes de grosses boites.
>
> Et effectivement, sa disponibilité est plus que parcimonieuse.
>
>
>
> Yannick Daniel Youalé
>
>
>
>
> Le 21/08/2023, LavaChri<progliste AT framalistes.org> a écrit :
>> salut,
>>
>> c'est exactement ce que j'allais te proposer au sujet de l'architecte,
>> il est responsable de ses choix et doit pouvoir les justifier.
>>
>> Donc il est censé connaître vos domaine de compétences et évaluer celles
>> nécessaires au projet.
>>
>> Ainsi il pourra dire si le projet est réalisable par vous, ou s'il faut
>> trouver d'autres ressources ou s'il faut tout simplement le refuser.
>>
>>
>> Bien sûr, tu dois avoir une idée de comment réaliser le projet mais
>> est-tu certain que ta méthode remplira parfaitement le cahier des charges
>> ?
>>
>> Ce n'est pas ton rôle et tu n'as probablement pas toutes les
>> informations du client.
>>
>> Donc tu ne devrais pas t'avancer à faire de propositions sur
>> l'architecture de ce projet, tu risquerais de te planter.
>>
>> D'autant que cela serait une belle opportunité pour l'architecte de dire
>> que tu traines parce que ses choix ne te plaisent pas.
>>
>> Si tu avais des réticenses sur ses choix tu aurais dû les faire dès le
>> départ pour qu'il est la possibilité de les ajuster.
>>
>> S'il te les as ordonner, comme tu semble le dire, c'est là qu'il aurait
>> fallu aller voir la direction pour exprimer tes réticences.
>>
>>
>> Maintenant, à mon sens, vous devriez aller voir l'architecte et quand
>> même lui exposer vos difficulté.
>>
>> C'est d'ailleurs choquant qu'il ne viennent pas à vous pour voir votre
>> avancement.
>>
>> Soit il a pas conscience de ce qu'il vous a demandé, soit il se croit
>> chez Google ! Tu dois bien en avoir une petite idée, non ?
>>
>> Dans tout les cas, s'il doit y avoir un changement cela devrait venir de
>> lui, puisqu'il à la maitrise globale du projet et pourrait devoir le
>> justifier.
>>
>> Donc, soit vous arrivez à vous entendre sur des changements acceptables
>> pour ne pas informer la direction, soit vous serez tous responsable du
>> retard à votre niveau de responsabilité.
>>
>>
>> Ce qui est sûr, c'est que vous devriez faire front avec ton équipe pour
>> ne pas laisser une chance à l'architecte de dire que c'est seulement
>> votre faute.
>>
>>
>> Bonne chance à toi
>>
>>
>>
>>
>> Le 20/08/2023 à 18:36, Yannick Daniel Youalé a écrit :
>>> 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é
>>>>>
>>>>
>> --
>> LavaChri
>>
>>
>

---

• Re: [progliste] application trop complexe dès le départ, Yannick Daniel Youalé, 25/10/2023

---

Archives gérées par MHonArc 2.6.19+.