Discussion :

[Ryu2000]

Au final l'agilité se transforme en une torture de réunions sans fin

Faites des sprint plus long (1 mois par exemple).
Comme ça les réunions de sprint planning 1, sprint planning 2, rétrospective seront moins fréquentes
Si par contre vous faites des sprints d'une semaine, effectivement ça fait beaucoup trop de réunions...

Tant que l'on ne se décidera pas à utiliser des commerciaux qui savent ce qu'est le développement

Ça existe ?

En faites ils pourraient juste demander aux développeurs une estimation du temps nécessaire pour réaliser la tâche, avant de faire des promesses au client.

[rheracles]

L'article comme les commentaires en dessous montrent effectivement que l'agilité met beaucoup de temps à infuser.

L'expression "les méthodes agiles" est en qq sorte presque un oxymore, on parlera plutôt de frameworks agiles.

L'agilité est finalement naturelle, des enfants ou des jeunes qui voudraient lancer un projet par eux-mêmes fonctionneraient naturellement en agile sans le savoir.

La difficulté consiste à se déshabituer d'habitudes héritées d'autres domaines du monde du travail, qui ne collent pas à la plupart des projets de SI.

[blbird]

L'agilité est finalement naturelle, des enfants ou des jeunes qui voudraient lancer un projet par eux-mêmes fonctionneraient naturellement en agile sans le savoir.

Ca te semble peut-être naturel, aussi facile que même des enfants devraient y arriver, mais le contexte des très nombreux projets de toute taille que j'ai pu voir s'y prête peu selon mon expérience (délais et budget imposés dès le début).

[youtpout978]

Ca te semble peut-être naturel, aussi facile que même des enfants devraient y arriver, mais le contexte des très nombreux projets de toute taille que j'ai pu voir s'y prête peu selon mon expérience (délais et budget imposés dès le début).

Au finale agilité et test unitaire même combat ...

[grunk]

Mais, si tous les développeurs prenaient l'habitude de refuser ces délais impossibles qu'on essaye de leur imposer à la dernière minutes, en faisant comprendre au client que le développement ce n'est ni facile ni magique, et que

Tant que l'on ne se décidera pas à utiliser des commerciaux qui savent ce qu'est le développement, qui prennent en compte le triangle d'or, les mentalités ne pourront pas évoluer.

En faites ils pourraient juste demander aux développeurs une estimation du temps nécessaire pour réaliser la tâche, avant de faire des promesses au client.

J'ai déjà du mal à faire comprendre que "non je peux pas te donner une release là maintenant tout de suite avec toutes les dernières nouveauté". On a un process de release à respecter qui prend un certains temps et qui garantie une certaine stabilité mais ca c'est juste inconcevable pour eux.
Chez nous les commerciaux on généralement le réflexe de demander les délais de dév, sauf que ce qui n'est généralement pas fait c'est la prise en compte de la charge de travail. Comme on mène de front à minima une dizaine de projet , si je dis il y'a 3 jours de dév , il comprenne c'est prêt dans 3 jours alors qu'en fait ça peut être 2 mois en fonctions des priorité des différents projets.

Mais clairement un des gros problèmes c'est la manque de connaissance transverse. Les commerciaux/marketeux ne connaissent pas nos contraintes et on connais pas forcément les leurs non plus.

[el_slapper]

(.../...)La difficulté consiste à se déshabituer d'habitudes héritées d'autres domaines du monde du travail, qui ne collent pas à la plupart des projets de SI.

Habitudes qui viennent généralement d'un besoin de contrôle de la part du chef. Ce qui rend les méthodes agiles si difficiles à appliquer, c'est que le chef refuse de ne pas diriger l'équipe comme bon lui semble.

J'ai déjà du mal à faire comprendre que "non je peux pas te donner une release là maintenant tout de suite avec toutes les dernières nouveauté". On a un process de release à respecter qui prend un certains temps et qui garantie une certaine stabilité mais ca c'est juste inconcevable pour eux.

On a les mêmes à la maison. Et ils seraient capables de livrer une release avec 0% de couverture de test des nouvelles fonctionnalités ou de non-regression(en fait, ils l'ont déjà fait), ou de demander à un dev de faire la modif sur site, en loucedé, sans passer par un buils propre(ah zut, déjà fait aussi).

Chez nous les commerciaux on généralement le réflexe de demander les délais de dév, sauf que ce qui n'est généralement pas fait c'est la prise en compte de la charge de travail. Comme on mène de front à minima une dizaine de projet , si je dis il y'a 3 jours de dév , il comprenne c'est prêt dans 3 jours alors qu'en fait ça peut être 2 mois en fonctions des priorité des différents projets.

ou alors le dev répond "temps de dev", mais derrière, il faut builder et tester que le build n'a rien cassé. Ca aussi, c'est oublié très souvent. On a un(e) expert métier qui a demandé un feature, le feature est développé, l'expert métier doit tester pour vérifier que le dev a bien compris...mais ça tourne déjà chez le client. Pas buildé, patché à la rache. Si, si.

Mais clairement un des gros problèmes c'est la manque de connaissance transverse. Les commerciaux/marketeux ne connaissent pas nos contraintes et on connais pas forcément les leurs non plus.

Très important de souligner que eux non plus n'ont pas une vie facile. Ils nous martyrisent certes, mais ils sont eux-mêmes martyrisés par des clients souvent impossibles. On a 7-8 gros clients, et un seul est vraiment sérieux - bizarrement, les projets avec ce client-là se passent toujours de manière impeccable, avec un scope respecté, des délais respectés, et des frottements à la livraison de l'ordre de l'anecdotique. Chez tous les autres clients, on raye fortement la camionnette à chaque fois qu'on fait une livraison majeure. Ben oui, mais quand on a un client qui ne connait pas son propre SI, ses propres besoins, qui ne donne jamais de ressources pour connaitre ses spécificités, qui a une infrastructure serveur 5 fois en dessous des prérequis minimaux, dont les ingénieurs systèmes cassent régulièrement les serveurs, qui refusent de former leur personnel, qui lève une "crise" pour une simple demande de feature à laquelle nous n'avons pas répondu en 48 heures(une fois, le big boss milliardaire américain a débarqué en jet privé à ce sujet, ça les a calmés - mais pas pour longtemps, hélas), et qui se servent de notre support pour lui apprendre son métier(authentique), fatalement, les projets connaissent plus de surprises.

Et les commerciaux sont face à ça, tout le temps. Ils n'ont définitivement pas une vie facile.

[xbrossard]

Petites choses concernant ma "soit disant" non-compréhension: peut être l'ais-je mal exprimé, mais je ne critique pas l'agilité en soit, mais je décris ce que je vois de l'utilisation qui en est fait dans les entreprises de mes nombreuses expériences (dont plus de 10 ans en SSII, l'essentiel du marché mais aussi le pire...).

Donc, concernant l'utilisation des outils, cela devrait faire partie d'un plan qualité du projet défini au début de celui-ci...or dans la pratique, le PAQ ne fait pas vraiment partie de la culture Agile. Donc bien souvent, on voit les développeurs choisir chacun dans leur coin ce qu'ils veulent.

Concernant la documentation, j'ai le regret de te dire que malheureusement dans la plupart des projets agile que j'ai vu, la moindre contrainte sur la documentation signifie pour le responsable "pas de doc, on verra après si on a le temps". Quand a fournir une documentation sur l'utilisation d'une fonctionnalité, c'est bien pour la réutilisation, moins pour la maintenance. Et au final ce que je critiquais, à savoir que la connaissance est seulement dans la tête du développeur qui a crée la fonctionnalité, est bien réelle.

Ce qu'on se rend compte avec les méthodes agiles, c'est que dans le principe, ça marche, mais dans la réalité des faits, ce n'est pas le cas... d'un autre coté, il y a beaucoup de choses dans la vie qui marche pareil; par exemple, en principe le communisme ça devrait marcher, mais dans la réalité...

Et au final, quand je parle de l'agilité avec d'autres personnes, ils finissent toujours par dire: "l'agilité, ça marche bien si tout le monde joue le jeu et que les gens sont compétents". L'embêtant, c'est que ce raisonnement marche pour toutes les autres méthodologies: le cycle en vie marche très bien aussi si tout le monde joue le jeu et que tout le monde est compétent... Une vraie bonne méthode devrait marcher avec des incompétents, ce qui a toujours été jugé rédhibitoire en agilité.

Dernière petite chose concernant l'architecture: n'oublions pas qu'à l'origine, les méthodes Agiles prônaient le principe de l'architecture émergente, qui apparaissait miraculeusement au milieu du code. Outre le fait que je crois peu en ce principe (la tour Effeil aurait elle pu apparaître en suivant ce principe?), j'ai remarqué que souvent les projets agiles s'appuient lourdement sur des frameworks près à l'emploi qui garantissent (en partie) cette bonne architecture, et là je me dit: "est-ce que les méthodes agiles auraient permis leur existence s'ils n'existaient pas?" (est-ce qu'un outil comme Spring aurait pu "émerger" d'un projet agile? je ne crois pas).
J'ai fait par exemple, en tant qu'architecte, des frameworks permettant d'écrire du code portable et réutilisable quelque soit l'architecture sous-jacente (enfin presque...). Je peux te dire que c'est très complexe et a un coût non négligeable que peu d'entreprises seraient prêtes à fournir, surtout quand ce n'est pas facturable à un client. Au final, dans l'urgence, les développeurs font du code spécifique qui a toutes les chances d'être redéveloppé en cas de changement d'architecture (exemple simple: passage de l'application en machine virtuelle -> ressource mémoire plus limité -> la belle appli très gourmande ne marche plus).

De même, une application bien codé (découpage en couches) nécessite plus de temps, qui ne sera pas forcément justifiable en agilité....

Au final, une application de l'agilité peut se faire sur un projet simple, type CRUD sur un modèle fonctionnel pas trop complexe, dans un environnement peu évolutif, en s'appuyant massivement sur des frameworks qui garantissent la qualité de l'ensemble...le genre de projet qui réussissent quelque soit la méthodologie (avec une bonne équipe)

[Almopine]

Mon expérience de la méthode agile c'est que la gestion de projet ne prend plus la peine de rédiger un cahier des charges ou de faire une roadmap cohérente, toute façon c'est agile.

Les impératif n'étant pas anticiper et les features mal rédiger, les sprints changent constamment mais c'est justement le coeur de l'agilité, par contre si la difficulté est accrus par une mauvaise gestion de projet ça change pas ta deadline de fin de sprint à toi, oh non. Et au final le retard t'es imputé parce que tu t'es engagé en début de sprint sur des specs mal rédiger sans que le client le sache de toute façon. C'est toujours le dev le responsable, au moins en cycle en v la gestion de projet et la maitrise d'ouvrage avait un minima de responsabilité, la c'est forcément le dev qui est incompétent.

[el_slapper]

(.../...)Et au final, quand je parle de l'agilité avec d'autres personnes, ils finissent toujours par dire: "l'agilité, ça marche bien si tout le monde joue le jeu et que les gens sont compétents". L'embêtant, c'est que ce raisonnement marche pour tou(.../...)

Aucune méthode ne marche avec des gens qui ne font pas l'affaire. Tu ne gagnes pas la ligue des champions avec des joueurs aux pieds carrés(genre moi). Point.

JE me demande si ce n'est pas là le vrai problème : on cherche des méthodes pour s'éviter d'avoir à chercher des gens qui font l'affaire. Mais ça ne marche pas, alors on accuse la méthode, plutôt que des recrutements faillis.

[petitours]

Bonjour

je prétends être agile uniquement au sens de m'adapter aux exigences qui évoluent, donc bien loin de la méthode agile...

Une question me turlupine depuis des lustres :
Comment ? sur quel type de projet ? Quel client est capable de s'engager sur un projet sans avoir une idée du budget qu'il doit et va engager et du résultat qu'il va obtenir, ne serait ce qu'en terme de bénéfice client (pour ses clients, sa propre source de revenus) ?
Perso quand j'interviens sur un projet il y a a minima quelqu'un qui a un business plan avec un truc à développer pour générer un business de X sur lequel il peut imaginer investir Y, tant qu'il est capable de lancer le truc sur le marché d'ici le mois Z avec la communication qui va bien avec.

Qui donc peut se lancer dans un projet qui va couter entre 2 et 2000k€ pour faire on ne sait pas quoi avec un déploiement et une maintenance subie le tout avec une dead line inconnue ?

Si vous avez des exemples concrets de projets avec le récit global de son déroulement je suis très intéressé.

[Ryu2000]

Qui donc peut se lancer dans un projet qui va couter entre 2 et 2000k€ pour faire on ne sait pas quoi avec un déploiement et une maintenance subie le tout avec une dead line inconnue ?

Avec les méthodes agiles ont peut donner l'accès à l'application très tôt dans le processus de développement.
Le client va ensuite orienter le développement pour que l'application réponde à ses besoins.

Alors qu'en cycle en V strict, le client signerai le cahier des charges, 2 ans plus tard les développeurs livreraient l'application et le client verrait que ça ne correspond pas du tout à ses besoins actuels, du coup il aurait payé 2 ans de développement pour rien.

Avec des méthodes agiles il y a moyen de prolonger de 3 mois en 3 mois, si le client commence à perde espoir, il peut stopper le développement.

[petitours]

Avec les méthodes agiles ont peut donner l'accès à l'application très tôt dans le processus de développement.
Le client va ensuite orienter le développement pour que l'application réponde à ses besoins.

Je suis d’accord avec ça mais pour moi en dev classique on a la notion de POC qui marche trés bien
Le POC ça coute X , c'est prêt dans Y temps et ça s'inscrit logiquement dans un processus de développement du client qui teste ainsi son concept.

Le POC répond selon moi toujours au cycle en V, avec une sorte de garantie de résultat dans la mesure où c'est pas fait pour être parfait, c'est juste fait pour tester un concept générateur de valeur pour le client.

C'est la que je me trompe ? un POC peut etre considéré comme les premiers sprint d'une methode agile ?

[koala01]

Je suis d’accord avec ça mais pour moi en dev classique on a la notion de POC qui marche trés bien
Le POC ça coute X , c'est prêt dans Y temps et ça s'inscrit logiquement dans un processus de développement du client qui teste ainsi son concept.

Le POC répond selon moi toujours au cycle en V, avec une sorte de garantie de résultat dans la mesure où c'est pas fait pour être parfait, c'est juste fait pour tester un concept générateur de valeur pour le client.

C'est la que je me trompe ? un POC peut etre considéré comme les premiers sprint d'une methode agile ?

Et, trop souvent, on va te dire que "bah, vu que le POC fonctionne, pourquoi faudrait il payer une deuxième fois le développement de cette fonctionnalité ? Contentons nous donc de récupérer le POC", malgré tous les problèmes ( de conception, bug et autres) qu'il pourrait contenir.

Résultat des courses, le POC (Proof Of Concept), qu devait être "provisoire" (on se contente juste de démontrer de manière rapide, et sans trop s'inquiéter du code produit que "quelque chose est faisable") se transforme en du "provisoirement définitif", car il devient alors même difficile de faire admettre le moindre besoin de refactorisation.

Rendez deux trois POC "provisoirement définitif" et intégrez les à votre projet, et vous serez rapidement confronté à toutes les décisions de ne pas respecter tel ou tel principe (je pense entre autres aux principes SOLID) "prises dans l'urgence" qui se ligueront contre vous pour vous empêcher de prendre de bonnes décisions et pour vous obliger "contourner le problème", en prenant une nouvelle fois (en connaissance de cause) la décision de ne pas respecter tel ou tel principe, ce qui ne fera que vous préparer le terrain pour ... être confronté à un problème "encore plus délicat" qui devra de nouveau être contourné lorsqu'il s'agira d'intégrer "la fonctionnalité suivante".

Je n'ai rien contre le principe d'un POC, à la seule condition qu'il soit strictement impossible de l'intégrer "tel quel" dans le langage, ce qui implique ad minima qu'il soit écrit dans un langage totalement incompatible avec celui utilisé pour le "projet principal". Le gros problème étant qu'il est de plus en plus facile d'intégrer des éléments écrits dans des langages différents dans nos projets

[Marco46]

la gestion de projet ne prend plus la peine de rédiger un cahier des charges ou de faire une roadmap cohérente, toute façon c'est agile.

Tu peux avoir une roadmap ce n'est pas un problème, simplement elle n'est pas figée.

Il n'y a pas de cahier des charges au sens waterfall ou cycle en V, il y a une liste d'US priorisée, le backlog.

Les impératif n'étant pas anticiper

Ben si ya un backlog.

les features mal rédiger

Si votre product owner ne fait pas son travail c'est sûr que c'est difficile de développer. Les US doivent être bien rédigées, si elles ne le sont pas elles sortent du backlog.

les sprints changent constamment mais c'est justement le coeur de l'agilité

Un PO ne peut pas modifier le contenu du sprint pendant un sprint, seuls les devs peuvent sortir des US qu'ils considèrent incomplètes (ils n'ont pas les billes pour travailler) ou en intégrer d'autres sur la base du backlog si le stock d'US pour le sprint est épuisé.

par contre si la difficulté est accrus par une mauvaise gestion de projet ça change pas ta deadline de fin de sprint à toi, oh non

La deadline de fin de sprint n'est pas contraignante sur le contenu du sprint. C'est pas parce que tu as 10 US dans ton sprint que tu dois toutes les faire. A la deadline tu livres en démo seulement ce qui est terminé, le reste retourne dans le backlog pour le sprint suivant.

Et au final le retard t'es imputé parce que tu t'es engagé en début de sprint sur des specs

Il n'y a pas de notion de retard en agile, il y a des échéances de livraison sur lesquelles tu livres ce qui est terminé. Le contenu d'un sprint n'est pas un engagement. Le seul engagement c'est que ce qui est terminé en fin de sprint est déployable en prod.

C'est toujours le dev le responsable, au moins en cycle en v la gestion de projet et la maitrise d'ouvrage avait un minima de responsabilité

Je ne vois pas au nom de quoi le PO ou le Scrum Master perdraient toute responsabilité.

la c'est forcément le dev qui est incompétent

Manifestement dans le fonctionnement que tu décris c'est la gestion de projet qui l'est.

Mon expérience de la méthode agile

J'ai émincé ton post pour y répondre point par point, j'aurais pu prendre d'autres interventions ici mais à chaque fois ce que je remarque c'est que ce n'est pas l'agile qui est en cause mais sa pratique. Quand on fait n'importe quoi ça donne n'importe quoi. Et oui quand on fait n'importe quoi en prétendant faire de l'agile c'est horrible à supporter pour les devs, mais ce n'est pas pour autant que l'agile c'est pourri.

Je dois être chanceux mais à chaque fois que j'ai été dans une équipe Scrum ça s'est très bien passé et il y avait très peu des écueils que vous présentez. Il y en a toujours certains parce que passer en agile c'est changer tout le fonctionnement de l'organisation et beaucoup de personnels métiers ne comprennent pas qu'on ne peut pas s'engager sur un périmètre fermé à une date figée mais ça se discute. C'est normalement le rôle du PO et du CdP de protéger les devs de ça. Apparemment vous décrivez souvent une situation inverse où le PO et le CdP transfèrent la pression sur les devs. C'est juste qu'ils sont incompétents ou qu'ils manquent de balls.

[Marco46]

Qui donc peut se lancer dans un projet qui va couter entre 2 et 2000k€ pour faire on ne sait pas quoi avec un déploiement et une maintenance subie le tout avec une dead line inconnue ?

Ce que tu décris ça s'appelle un forfait. On ne fait pas d'agile avec du forfait.

Forfait = périmètre fonctionnel figé, deadline figée, coût figé

En agile tu as des deadlines figées, tu peux avoir un coût figé, mais tu ne peux pas, en aucun cas, avoir un périmètre fonctionnel figé.

[edrobal]

Ce qui me stupéfie dans l'informatique qui est censé être un monde ouvert (agile ?) c'est la soumission incroyable aux effets de mode.

[Marco46]

Ce qu'on se rend compte avec les méthodes agiles, c'est que dans le principe, ça marche, mais dans la réalité des faits, ce n'est pas le cas...

De part ton expérience peut-être mais ce n'est pas le cas de tout le monde. Perso j'ai probablement eu plus de chance.

Une vraie bonne méthode devrait marcher avec des incompétents, ce qui a toujours été jugé rédhibitoire en agilité.

Si tu fais du waterfall ou du cycle en V avec des incompétents tu iras à l'abattoir aussi sûrement qu'avec une "méthode" agile.

Dernière petite chose concernant l'architecture: n'oublions pas qu'à l'origine, les méthodes Agiles prônaient le principe de l'architecture émergente, qui apparaissait miraculeusement au milieu du code.

Absolument pas. Tu confonds avec l'extreme programming couplé à la clean architecture dont le but est de révéler l'implémentation via l'écriture des tests avant le code.

La pratique de l'agile ne dispense pas d'effectuer de la conception logicielle. L'usage d'un framework quelconque non plus d'ailleurs.

[Pyramidev]

Dernière petite chose concernant l'architecture: n'oublions pas qu'à l'origine, les méthodes Agiles prônaient le principe de l'architecture émergente, qui apparaissait miraculeusement au milieu du code.

Absolument pas. Tu confonds avec l'extreme programming couplé à la clean architecture dont le but est de révéler l'implémentation via l'écriture des tests avant le code.

Je crois qu'il parle plutôt du bottom-up design.

Concernant Robert Cecil Martin, l'auteur de Clean Architecture: A Craftsman's Guide to Software Structure and Design, sa vision est qu'il faut d'abord avoir une idée très générale sur l'architecture du code avant d'écrire les tests unitaires. Ensuite, le code testé grossit et est réusiné. Alors, l'architecture du code testé évolue, ce qui colle à l'idée de l'architecture émergente.

Je cite un gros extrait de l'article TDD Harms Architecture de Robert Cecil Martin. Remarque pour les autres : attention au titre de l'article. Robert Cecil Martin est à fond pour le TDD. L'article s'appelle TDD Harms Architecture en référence à un article de David Heinemeier Hansson.

The idea that the high level design and architecture of a system emerge from TDD is, frankly, absurd. Before you begin to code any software project, you need to have some architectural vision in place. TDD will not, and can not, provide this vision. That is not TDD's role.

However, this does not mean that designs do not emerge from TDD – they do; just not at the highest levels. The designs that emerge from TDD are one or two steps above the code; and they are intimately connected to the code, and to the red-green-refactor cycle.

It works like this: As some programmers begin to develop a new class or module, they start by writing simple tests that describe the most degenerate behaviors. These tests check the absurdities, such as what the system does when no input is provided. The production code that solves these tests is trivial, and gradually grows as more and more tests are added.

At some point, relatively early in the process, the programmers look at the production code and decide that the structure is a bit messy. So the programmers extract a few methods, rename a few others, and generally clean things up. This activity will have little or no effect on the tests. The tests are still testing all that code, regardless of the fact that the structure of that code is changing.

This process continues. As tests of ever greater complexity and constraint are added to the suite, the production code continues to grow in response. From time to time, relatively frequently, the programmers clean that production code up. They may extract new classes. They may even pull out new modules. And yet the tests remain unchanged. The tests still cover the production code; but they no longer have a similar structure.

And so, to bridge the different structure between the tests and the production code, an API emerges. This API serves to allow the two streams of code to evolve in very different directions, responding to the opposing forces that press upon tests and production code.

I said, above, that the tests remain unchanged during the process. This isn't actually true. The tests are also refactored by the programmers on a fairly frequent basis. But the direction of the refactoring is very different from the direction that the production code is refactored. The difference can be summarized by this simple statement:

As the tests get more specific, the production code gets more generic.

This is (to me) one of the most important revelations about TDD in the last 16 years. These two streams of code evolve in opposite directions. Programmers refactor tests to become more and more concrete and specific. They refactor the production code to become more and more abstract and general.

Quand tu parles de « révéler l'implémentation via l'écriture des tests avant le code », formulé comme ça, je crois que tu parles d'autre chose. Le meilleur exemple que j'ai trouvé pour illustrer l'idée est l'article FP Basics E3 de Robert Cecil Martin.

Dans cet article, pour écrire une certaine fonction en Clojure qui découpe un texte en plusieurs lignes selon une taille maximale de ligne, il a écrit deux versions de la fonction, chacune avec un algo différent et une stratégie différente :

• Pour la première version, il a pratiqué le TDD en écrivant une succession de codes faux mais qui passent de plus en plus de tests unitaires. Ces codes intermédiaires sont présents dans l'article. Le dernier code, qui passe tous les tests, est juste.
• Dans la deuxième, il a essayé d'écrire le bon code d'un coup et l'a débogué avec le REPL.

Il a écrit qu'il avait pas mal galéré avec la deuxième approche. Il arrive plus vite à écrire un algo juste en faisant du TDD.

The entire process took at least three times longer than the TDD approach, involved a lot of nasty debugging and print statements, and caused many infinite recursive loops that blew the stack and crashed my console. In short, it was a pain. I don't recommend it.



Cela dit, il n'était pas encore habitué à la programmation fonctionnelle et à Clojure. L'article date de 2013.

[hotcryx]

On a testé SCRUM pendant 2, 3 semaines.
Finalement on a arrêté ça ne nous convenait pas.
Raison: à chaque SCRUM, on répétait la même chose sans avoir vraiment avancé

[petitours]

Résultat des courses, le POC (Proof Of Concept), qu devait être "provisoire" (on se contente juste de démontrer de manière rapide, et sans trop s'inquiéter du code produit que "quelque chose est faisable") se transforme en du "provisoirement définitif", car il devient alors même difficile de faire admettre le moindre besoin de refactorisation.

Quand je fais un POC, le POC n'est pas utilisable en prod, il ne peut devenir un provisoire définitif.
Soit ça marche pas longtemps, soit ça ne marche que dans une infra très particulière et dans la plupart des cas ça fait le job sur un jeu de donnée échantillon, quelquefois avec une fonctionnalité balaise qui n'existe pas encore mais sait juste donner le résultat qui va bien sur l’échantillon de donnée.