Développement Backend en 2021, 2022, 2023, quelles tendances ?

Salut !

Je crée ce topic au sujet du développement "backend" (au sens le plus large possible) pour explorer avec vous des tendances de technos et de process de travail qui, dans les grandes lignes, "en gros", ont été, sont, et pourraient être fréquemment demandées par les agences Web (ou SSII/ESN Web).

Un petit tour d’horizon de ces années 2021.22.23 donc…

Je commence :

• Les méthodes agiles, SCRUM (sauf cycles itératifs purs) : j’ai l’impression que c’est de + en + dépassé d’après certaines lectures et certains témoignages IRL, et ceux qui continuent d’utiliser ça s’en lassent (apparemment). Néanmoins je vois souvent ça dans les offres d’emploi…

• Cycles itératifs purs (un élément des méthodes agiles, cf. ce qui suit dans ce paragraphe) : cette expression n’existe pas en tant que telle, mais je désigne par là le fait de concevoir/développer/livrer/déboguer/discuter avec le client en boucle jusqu’à obtenir un produit qui lui convienne, sans toutes les fioritures qu’on rencontre dans les méthodes agiles (passage d’un totem sous la forme d’un relais, réunions standups du matin, etc.). "purs" se justifie donc par l’absence de telles fioritures, je ne savais pas comment nommer la chose sans. Pour le coup, je pense que c’est massivement utilisé et c’est "normal", quasiment intrinsèque à la nature de la relation entreprise-client et intrinsèque également à la réalisation des produits.

• Automatisation développement/publication/tests avec GitHub/GitLab : idem c’est déjà bien ancré et bien utile, massivement utilisé.

• Diverses sortes de tests : idem.

• Logiciels de time/tasks tracking/collaboration : ça peut paraître inutile de le lister ici, mais dans ma première boîte il a fallu attendre 11 ans pour qu’elle en achète un. Dans ma deuxième, 2 ans. Mais d’après mes lectures, beaucoup d’entreprises ont rapidement recours, et durablement, à ce genre de programmes.

Ça, c’était pour les process de travail que je connais à peu près. Passons aux technos :

• Kubernetes

• Docker (encore que, d’après mes lectures, la techno serait en perte de vitesse et remplacée par d’autres)

• NodeJS (à chaque fois je vois ça, partout)

• MongoDB, NoSQL

• Wordpress et Prestashop, Woocommerce (j’aime pas ces 3 trucs)

• Shopify (ça, ça a le vent en poupe et c’est censé remplacer Presta et Woocommerce, en mode nocode ou presque sauf erreur de ma part)

• ElasticSearch (j’en entends de + en + parler, parce qu’en fait c’est pas juste un outil de recherche à base de machine learning, mais carrément une suite d’API et d’outils divers qui sont utiles pour les internautes et qui donc trouvent leur place dans les sites Web, et le dev Web in fine)

• MySQL (comme toujours), SQL

• La politique RGPD a aussi engendré l’apparition de certains scripts/programmes comme : tarteaucitron.JS, etc. (nouvelle législation => nouvelles niches de commerce, nouvelles clientèles, nouvelles technos, etc.)

• Prise en compte de la vie privée des internautes : Google Recaptcha toujours utilisé, Google Maps aussi, mais hRecaptcha et OpenStreetMaps également. Surtout depuis que Google Maps est devenu payant (je ne sais pas exactement dans quelles conditions, mais je sais qu’il est devenu beaucoup plus payant qu’avant si je puis dire)

• En guise de dév Backend, il y a peut-être également une démocratisation de Go!, Python, Ruby, et surtout : Rust (un framework a récemment été publié par quelqu’un je crois, mais de là à ce qu’il soit utilisé en 2023 peut-être pas…).

• Web 3.0, Cryptos, Blockchains, Multivers, Informatique quantique, Web quantique… : attention point contestable, mais sur LinkedIn y a un ancien collègue qui n’arrête pas de spammer ça (il est dev crypto/blockchain) et certaines de mes lectures tendent à montrer une certaine tendance de ces concepts… Je pense que tout ça est encore à l’état larvaire (voire à l’état quasiment purement théorique pour les "XYZ quantique"). Certains parlent d’un el dorado.

• Encore plus futuriste mais déjà en cours et depuis belle lurette (avec cependant un regain d’intérêt) : le développement écologique, le traitement de données et la structuration de données adaptés, et idem pour des systèmes en lien avec l’exploration spatiale (on ne s’éloigne pas de la notion de backend je précise, même si ce n’est pas du Web).

Bon voilà, j’ai l’impression d’être un peu à la ramasse et de zapper plein de technos ou de process… Comment compléteriez-vous cette liste ?

Bonne journée !

Le développement écologique

🤦‍♂️
Ça m’exaspère un peu.

Pourquoi ? (vraie question) J’ai vu des gens qui s’interrogeaient réellement dessus, sur l’optimisation de leurs programmes et de leurs choix technologiques pour réduire la puissance matérielle nécessaire et la consommation d’énergie.

Dans presque tous les cas que j’ai vu, c’est soit du greenwashing, soit basé sur des métriques complètement obsolètes et pétées – comme tout ce qui se base sur le rapport de 2019 du Shift Project à ce sujet, hélas.

Pour plus d’info, Canard PC Hardware a sorti très récemment un dossier sur l’écologie et l’informatique, disponible ici sur Internet (accès payant, ou gratuit si vous avez un compte et que vous « chouinez » pour avoir l’article) ; ou chez votre marchand de journaux préféré.

Au fait, mis à part le plaisir des inventaires à la Prévert, quel est l’intérêt de ces listes ?

Bonne question, c’est une demande de Herbe pour… On sait pas quoi en fait. Mais en vrai j’ai bien aimé lire son message alors j’ai mis le mien

augmenter les stats @spacefox, augmenter les stats.

c’est pour l’algorithme :m:p

Bonjour à tous, merci pour vos réponses

Je voulais voir si les réponses corroboraient ce que j’ai fait dans mes 2 boîtes et ce que je lis sur les offres d’emploi ! Et la réponse est oui ! C’est fou mais j’ai l’impression que beaucoup d’agences Web travaillent avec React par exemple, et je vois qu’ElasticSearch revient souvent aussi, etc.

Par ailleurs c’est aussi pour le fun (veille technologique) : découvrir de nouvelles technos, échanger à leur sujet.

Pourquoi ?

@artragis

Je ne sais pas ce que fait le monde des SSII/ESN mais chez les éditeurs à que j’ai pu voir, ça me semble encore très ancré et loin d’être sur le déclin.

C’est juste que les agences Web dans lesquelles j’ai bossé sont constamment à la ramasse, du coup les chefs de projets/directeurs techos n’ont pas envie d’appliquer SCRUM, sans doute par "manque de temps - selon leur façon de voir les choses". Ils préfèrent consacrer leurs ressources à l’avancée du projet pur et dur (i.e.: coder, coder, coder, résoudre tâche, résoudre tâche, résoudre tâche). Bon au moins ils utilisent Kanban avec des outils comme Asana ou un bon vieux tableau blanc à post-its (voire les deux ensemble, comme dans ma dernière boîte).

Disons qu’on est à l’ère de la conteneurisation. Donc docker, podman ou tout logiciel compatible avec les API utilisés par les principaux orchestrateurs genre kubernates sont la base et ne sont pas en perte de vitesse. Docker a aujourd’hui des concurrents dans le domaine de la conteneurisation car rares sont les personnes qui utilisent les fonctionnalités propres à docker.

Oui c’est ce que j’avais aussi compris de la situation actuelle.

En vrai c’est les concepts de gitops et de CI/CD qui sont vraiment sur le devant de la scène

C’est clair, un admin syst m’en a beaucoup parlé d’ailleurs. C’est un truc qu’il faut absolument que je bosse car malgré tout, je n’ai jamais eu l’occasion d’utiliser ça en entreprise.

Côté bdd, en vrai j’observe qu’on a enfin un retour à la raison sur l’usage du NoSQL. Non pas qu’on l’utilise moins, mais qu’on arrête de l’utiliser pour tout et n’importe quoi

Oui !

Je constate sans surprise que ce sont toujours les mêmes db qui reviennent : mysql/mariadb, postgres, mongodb. J’aurais pas pensé qu’Orale DB serait moins utilisé dans le milieu professionnel par contre. Mais pas étonnant si c’est une question de $$$ en effet.

En tout cas j’allais m’y intéresser perso, vraiment pour des raisons écologiques. Il me semblait qu’on pouvait avoir une action pro-environnementale non-négligeable au niveau du stockage des données et des transferts de données (et un peu moins au niveau du traitement). Mais du coup ça me démotive un peu

@Nek

Merci !

Tout pareil !

Par contre étonnamment, tu ne classes pas Sylius en tant que CMS plutôt ? Enfin c’est du détail.

Par contre je trouve ça ouf que Prestashop continue d’être utilisé, c’est tellement pourri. Les deux boîtes dans lesquelles j’ai travaillées détestaient Presta, on passait énormément de temps à déboguer des modules qui faisaient des die au lieu de backlog les exceptions (donc pour déboguer ça c’était pas de la tarte au citron ( ), surtout s’il y avait une histoire de hooks, blablabla). Et ça c’était qu’une catégorie de problèmes. En réalité il y en a bien d’autres avec Presta (on en parle de leur soit-disant conversion Symfony ?…) (et la signature des fonctions hooks back-end qui ressemble à celle de leur équivalent front-end MAIS qui diffèrent quand même un peu : dans l’un c’est parfois un Objet qui est passé tandis que dans l’autre c’est un Array qui contient seulement quelques propriétés/valeurs de l’Objet voire avec quelques modifications, entre autres incohérences juste pour t’enquiquiner) (bref). Et même les admin syst détestaient ça… Et puis paie la doc… 0 doc convenable, 0 forum techos, bref Presta c’est n’importe quoi.

On m’a récemment proposé un post de Lead Dev Prestashop j’ai aussitôt refusé je suis pas maso à ce point bref.

Par contre je trouve ça ouf que Prestashop continue d’être utilisé, c’est tellement pourri.

Et bah détrompe toi, par rapport à du woocommerce c’est vraiment solide en fait. Pour des usages simples c’est assez cool prestashop, surtout les dernières versions. Le problème vient plutôt et surtout des modules en fait.

Lead dev prestashop par contre j’avoue c’est dur .

La finalité c’est que c’est plutôt fait pour des petites boutiques que des gros sites, et par rapport à ça, le taff est vraiment pas si mal: les sites sont généralement beaucoup plus cohérents que les woocommerces qui n’ont aucune structuration… (ce qui se répercute directement sur l’ensemble du site woocommerce (stablilité, maintenabilité, api inexploitable, google shopping éclaté, performances catastrophiques))

Par contre étonnamment, tu ne classes pas Sylius en tant que CMS plutôt ? Enfin c’est du détail.

Ouais pour moi c’est plus de l’ordre du framework parce que c’est vraiment des composants mis bout à bout. Et tu n’utilises pas sylius si tu veux une boutique toute faite en réalité (même si c’est possible), tu vas l’utiliser pour pouvoir coder efficacement et lancer une suite de tests efficace prééablie…

Le problème vient plutôt et surtout des modules en fait.

homph, c’est pas ce qu’on se disait dans mes deux boîtes (même si oui, les modules représentent la majorité des pbs ; mais Presta en lui-même, ainsi que sa documentation et sa " " " " communauté " " " " sont problématiques aussi - spoiler : commu' inexistante/inatteignable).

Ouais pour moi c’est plus de l’ordre du framework parce que c’est vraiment des composants mis bout à bout. Et tu n’utilises pas sylius si tu veux une boutique toute faite en réalité (même si c’est possible), tu vas l’utiliser pour pouvoir coder efficacement et lancer une suite de tests efficace prééablie…

J’ai légèrement effleuré Sylius du bout du bout du bout du petit doigt : si je comprends bien, c’est adapté aux clients qui veulent du sur-mesure plus maîtrisé de bout-en-bout par l’équipe de devs que Prestashop c’est ça ? Vu que les devs vont de voir agir beaucoup pour assembler les "composants" dont tu parles, voire les réécrire/surcharger/ou en écrire de nouveaux (bref, similairement à un framework comme tu dis).

C’est intéressant à maîtriser non ? Ce n’est pas du tout la première fois que j’en entends parler et on a eu un projet sur ça dans ma dernière boîte. A noter que 90% des sites e-commerce c’était Prestashop.

C’est hyper intéressant Sylius, oui. Et quand je parle d’assembler des composants, je parle de leur longue liste à eux (et des plugins de la commu).

Cependant, Sylius, c’est hyper mal documenté. Un vrai problème.

• Les méthodes agiles, SCRUM (sauf cycles itératifs purs) : j’ai l’impression que c’est de + en + dépassé d’après certaines lectures et certains témoignages IRL, et ceux qui continuent d’utiliser ça s’en lassent (apparemment). Néanmoins je vois souvent ça dans les offres d’emploi…
• Cycles itératifs purs (un élément des méthodes agiles, cf. ce qui suit dans ce paragraphe) : cette expression n’existe pas en tant que telle, mais je désigne par là le fait de concevoir/développer/livrer/déboguer/discuter avec le client en boucle jusqu’à obtenir un produit qui lui convienne, sans toutes les fioritures qu’on rencontre dans les méthodes agiles (passage d’un totem sous la forme d’un relais, réunions standups du matin, etc.). "purs" se justifie donc par l’absence de telles fioritures, je ne savais pas comment nommer la chose sans. Pour le coup, je pense que c’est massivement utilisé et c’est "normal", quasiment intrinsèque à la nature de la relation entreprise-client et intrinsèque également à la réalisation des produits.

Ce point montre une certaine confusion sur ce qu’est Agile.

On ne fait pas du Agile, et on n'utilise pas Agile, on est agile ou on ne l’est pas. Pour devenir agile en employant un ensemble de pratiques qui aident à s’adapter rapidement au changement, il existe un certain nombre de méthodologies comme SCRUM, Kanban, XP : toutes sont valables en intervenant sur des éléments distincts du processus de création du logiciel (SCRUM est orienté "management", Kanban se contente de reproduire le tableau en colonnes pour limiter le WIP et laisse l’équipe libre de ses pratiques pour s’y tenir, XP est plutôt orienté sur les pratiques de développement…), mais aucune d’entre elles n’est ou ne peut devenir "dépassée".

Ce que l’on observe, c’est que la plupart des boîtes qui utilisent explicitement SCRUM pour "devenir" Agile se cassent les dents dessus parce qu’elles se concentrent sur les processes et les cérémonies plutôt que sur les problèmes à résoudre en se préparant à accueillir le changement quand il arrivera.

Paradoxalement, les équipes les plus agiles que j’ai pu voir sont celles qui le sont "naturellement", en reprenant à leur compte les principes Agile sans les noyer derrière une tonne de jargon ni de cérémonies. Ce n’est pas que les "fioritures" manquent : elles sont en fait présentes, mais discrètes parce que tout le monde le fait naturellement, plutôt que d’utiliser un "totem" ou de mettre en place des cérémonies (rétrospective, planning…), qui sont à voir comme des outils pour adopter des pratiques saines, et dont il faut savoir aussi se défaire lorsque l’on trouve un moyen de faire mieux, plutôt que d’y rester attaché.

Docker (encore que, d’après mes lectures, la techno serait en perte de vitesse et remplacée par d’autres)

Disons qu’on est à l’ère de la conteneurisation. Donc docker, podman ou tout logiciel compatible avec les API utilisés par les principaux orchestrateurs genre kubernates sont la base et ne sont pas en perte de vitesse. Docker a aujourd’hui des concurrents dans le domaine de la conteneurisation car rares sont les personnes qui utilisent les fonctionnalités propres à docker.

Docker n’est pas réellement en perte de vitesse. Ils ont défini un standard pour les images, les runtimes et les Dockerfiles qui sont utilisés de façon universelle aujourd’hui.

C’est inexact de parler de "concurrence" : podman et buildah ne sont pas des concurrents à Docker, CRIO et containerd ne sont pas des concurrents à son runtime. Ils font strictement la même chose et sont très largement compatibles entre eux.

La seule chose qui change c’est que :

• Docker est le produit d’une entreprise privée, alors que podman/buildah/containerd/CRIO sont libres et respectent le standard qui a été créé par l’Open Container Initiative (dont Docker fait partie), et qui est largement basé sur les specs de Docker.
• Les fournisseurs de cloud favorisent maintenant les runtimes standards, beaucoup plus stables que celui de Docker.

Quand tu développes une appli conteneurisée, tu as encore besoin d’écrire des Dockerfiles, de lancer des conteneurs sur ta machine en local pour tester, etc. Que tu utilises pour cela Docker directement ou les softs de l’OCI n’a strictement aucune importance ; c’est du détail d’implémentation. D’ailleurs mon Makefile au boulot prévoit d’utiliser l’un ou l’autre indifféremment, ça consiste juste à rendre le nom docker substituable par podman dans les commandes.

• Les méthodes agiles, SCRUM (sauf cycles itératifs purs) : j’ai l’impression que c’est de + en + dépassé d’après certaines lectures et certains témoignages IRL, et ceux qui continuent d’utiliser ça s’en lassent (apparemment). Néanmoins je vois souvent ça dans les offres d’emploi…
• Cycles itératifs purs (un élément des méthodes agiles, cf. ce qui suit dans ce paragraphe) : cette expression n’existe pas en tant que telle, mais je désigne par là le fait de concevoir/développer/livrer/déboguer/discuter avec le client en boucle jusqu’à obtenir un produit qui lui convienne, sans toutes les fioritures qu’on rencontre dans les méthodes agiles (passage d’un totem sous la forme d’un relais, réunions standups du matin, etc.). "purs" se justifie donc par l’absence de telles fioritures, je ne savais pas comment nommer la chose sans. Pour le coup, je pense que c’est massivement utilisé et c’est "normal", quasiment intrinsèque à la nature de la relation entreprise-client et intrinsèque également à la réalisation des produits.

Ce point montre une certaine confusion sur ce qu’est Agile.

On ne fait pas du Agile, et on n'utilise pas Agile, on est agile ou on ne l’est pas. Pour devenir agile en employant un ensemble de pratiques qui aident à s’adapter rapidement au changement, il existe un certain nombre de méthodologies comme SCRUM, Kanban, XP : toutes sont valables en intervenant sur des éléments distincts du processus de création du logiciel (SCRUM est orienté "management", Kanban se contente de reproduire le tableau en colonnes pour limiter le WIP et laisse l’équipe libre de ses pratiques pour s’y tenir, XP est plutôt orienté sur les pratiques de développement…), mais aucune d’entre elles n’est "dépassé".

Ce que l’on observe, c’est que la plupart des boîtes qui utilisent explicitement SCRUM pour "devenir" Agile se cassent les dents dessus parce qu’elles se concentrent sur les processes et les cérémonies plutôt que sur le fait de devenir génératif, de se concentrer sur les problèmes à résoudre et d’être prêt à réagir au changement quand il arrive.

Paradoxalement, les équipes les plus agiles que j’ai pu voir sont celles qui le sont "naturellement", en reprenant à leur compte les principes Agile sans les noyer derrière une tonne de jargon ni de cérémonies. Ce n’est pas que les "fioritures" manquent : elles sont en fait présentes, mais discrètes parce que tout le monde le fait naturellement, plutôt que d’utiliser un "totem" ou de mettre en place des cérémonies (rétrospective, planning…), qui sont à voir comme des outils pour adopter des pratiques saines, et dont il faut finir par se défaire plutôt que de se concentrer dessus.

Je suis, tellement, mais alors, tellement, pas d’accord avec cela. Car dans ta définition ma team serait la plus agile du game par exemple. Et je peux te dire pour le vivre que c’est faux. On a une capacité d’adaptation au changement qui ne fonctionne pas du tout car beaucoup trop élevée. Non, agile ne veut pas dire ce que ça dit. AGILE c’est un framework de méthodologie à suivre à la lettre pour que tout se passe bien. Agile n’invalide pas toutes les autres méthodes, et SCRUM n’est pas nécessairement la meilleure façon de travailler en agile, certes. Mais tout de même il n’y a rien de naturel là dedans et les cérémonies ne sont pas des blagues.

Par contre je dirais que agile a un coût, mais c’est pour gagner en qualité au niveau du produit et en séreinité des équipe.

Non, agile ne veut pas dire ce que ça dit. AGILE c’est un framework de méthodologie à suivre à la lettre pour que tout se passe bien.

Ne pas être d’accord, c’est ton choix. Faut juste être conscient que ce que tu dis ici entre en contradiction complète avec deux bonnes grosses décennies de littérature sur le sujet (la manifeste a été signé en 2001…). Y compris les mouvements "complémentaires" qui se basent sur la philosophie Agile (non, désolé, ce n’est pas un framework) pour aller au-delà, comme DevOps ou le Software Craftsmanship. L’affirmer de façon aussi vindicative ne changera pas le fait que c’est juste faux.

La boîte dans laquelle je bosse est la plus agile que j’aie connue de ma carrière : on n’y implémente aucune méthodologie ni n’utilise aucun jargon (on ne parle pas de kanban, ni de ceremonies, ni de rétro, ni de standup, ni de totem, ni de user cards, ni …), par contre chaque semaine, ça pulse.

D’acc, pour donner du contexte au autres s’ils l’ont pas, on parle de cela: https://agilemanifesto.org/iso/fr/principles.html

Qui dit clairement pas qu’il faut faire ce qu’on veut. Mais soit, c’est comme la bible, c’est interprétable.

À aucun moment le Agile Manifesto ne dit "faites exactement comme on vous dit, à la lettre" : il te dit quoi viser, il te dit pourquoi le viser, mais à aucun moment, être Agile, c’est déplacer des post-its sur un tableau, se passer un totem, faire un poker avec des cartes numérotées avec la suite de fibonacci, ou faire une rétrospective le vendredi.

Tu es en train de dire que si tu ne fais pas du SCRUM ou du XP ou du Kanban, alors tu "ne respectes pas Agile" : c’est juste faux, et ce n’est marqué nulle part sur la page que tu viens de linker. J’ai de parfaits contre exemples sous les yeux : au travail, on ne fait ni de SCRUM, ni de XP, ni de Kanban. On a des pratiques proches, qu’on utilise et qu’on adapte au fur et à mesure que notre contexte évolue, et on se concentre sur les résultats plutôt que sur les pratiques. Paradoxalement, c’est la seule boîte que j’aie connue où on livre de la valeur à rythme constant, à qualité constante, et à effort constant. Alors bien sûr de temps en temps on se rate, mais quand on se rate on apprend, on adapte, et on s’améliore, itérativement, ce qui est exactement l’objectif d’Agile.

Il y a deux bonnes raisons à ce que ne ce soit pas un framework méthodologique "à suivre à la lettre". La première, c’est parce que ça ne fonctionne juste pas si on a besoin de se concentrer sur les rituels plutôt que sur les objectifs. La seconde, c’est parce que le but est d’organiser et d’optimiser la coopération entre des êtres humains qui sont des professionnels, et qui travaillent dans des environnements extrêmement variables. Pas orchestrer des robots.

Comme le dit Nohar, l’agile n’est pas un framework. C’est une approche du développement par des développeurs pour des développeurs.

Tu peux réduire l’agile à deux objectifs : avoir une boucle de feedback la plus courte possible (le temps entre le moment où on commence à développer quelque chose et celui où on a des retours utilisateur) et chercher à réduire au maximum cette boucle de feedback. Sans oublier qu’on livre toujours de la qualité (autant dans le code que dans les fonctionnalités livrées).

Et mine de rien, cela tire beaucoup de choses : on a besoin de discuter avec les utilisateurs/clients pour connaître leurs besoins et savoir comment y répondre. On doit éviter les effets tunnel pour accueillir les changements au plus tôt et livrer rapidement. On a besoin de CI/CD pour délivrer vite (ce qui tire encore plus de pratiques/principes), etc.

Mais ça reste avant tout une philosophie qui demande une approche technique, personnelle, structurelle et organisationnelle.

SCRUM est construit (et autres méthodologies) là-dessus pour fournir un framework : la boucle de feedback est déterminée par des sprints de une ou deux semaines avec démo/sprint review. L’amélioration continue par la rétrospective.

L’avantage, c’est que SCRUM donne un cadre normé auquel il est facile de s’attacher et permet notamment aux équipes nouvelles de se lancer dans un développement agile (c’est une des raisons pour lesquelles on commence par SCRUM).

L’inconvénient de SCRUM, c’est qu’il donne le sentiment d’être agile sans l’être (culte du cargo) : si tu fais des sprints de deux semaines mais que tu ne livres qu’une fois tous les 6 mois, ta boucle de feedback est de 6 mois. Si tu fais des rétro sans en sortir la moindre idée d’amélioration que tu mets en place immédiatement, tu ne fais pas d’amélioration continue. Si l’équipe doit attendre le retour de vacances de l’UX (ou PO) pour discuter avec les utilisateurs, tu ne peux pas t’adapter.

Je n’entrerai pas dans les détails des estimations, sprint plannings, etc. mais il y aurait aussi des choses à dire…

Dernier point : SCRUM est orienté gestion de projet alors que l’agile est pour les équipes de développement (sans compter que SCRUM est tellement bien qu’on a besoin d’une personne dans chaque équipe pour forcer les autres à suivre le process)

Si tu veux plus d’infos sur les déboires des méthodologies comme SCRUM, tu peux lire les articles comme the tragedy of craftsmanship de Uncle Bob, agile hangover de Sandro Mancuso ou developers should abandon agile de Jeffries. En français, tu peux regarder la conférence de Arnaud Lemaire Et si on redémarrait l’agile ?