Chronologique Discussions  

< Chronologique >       < Discussions >

---

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é

---

• [progliste] application trop complexe dès le départ, Yannick Daniel Youalé, 20/08/2023
  • Re: [progliste] application trop complexe dès le départ, QuentinC, 20/08/2023
    • Re: [progliste] application trop complexe dès le départ, Yannick Daniel Youalé, 20/08/2023
      • Re: [progliste] application trop complexe dès le départ, LavaChri, 21/08/2023
        • Re: [progliste] application trop complexe dès le départ, Yannick Daniel Youalé, 21/08/2023

---

Archives gérées par MHonArc 2.6.19+.