Pour faire plus creux que l'agilité elle-même, fallait forcer…
Je suis fondamentalement convaincu que ce modèle est en train de tuer l'entreprise dans laquelle je travaille, nos talents s'en vont un par un, chaque fin de sprint sont remontés les même problèmes pour ne jamais être traités, les équipes sont à bout.
Chez nous, c'était la méthode YOLO qui fonctionnait bien. Puis on a changé de direction…
Ah ça fait joli pour les clients. Mais derrière la jolie façade, on est tous en souffrance. Mais bon, on est agile alors tout va bien hein…
La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.
[…] chaque fin de sprint sont remontés les même problèmes pour ne jamais être traités, les équipes sont à bout.
Le manifest agile explique pourtant :
À intervalles réguliers, l’équipe réfléchit aux façons de devenir plus efficace, puis modifie son comportement et l’ajuste en conséquence.
Loin de moi l'idée de te dire comment tu dois ou pas t'organiser dans ton travail, mais ne pas respecter la méthode et la blâmer ne me semble pas correct. Je ne sais pas pourquoi vous l'implémenter mal (mauvaise compréhension à différents niveaux, sabotage, mauvais contexte,…),mais refuser de corriger les problèmes rencontrés quelque soit la méthode de travail me semble regrettable et je peux comprendre tant de départs.
et peut-être aussi une façon de diminuer les coûts
C'est un reproche ? Parce qu'en soit diminuer les coûts n'est pas un problème c'est plutôt comment qui peut être un problème ou au détriment de quoi (bon je ne vois pas en quoi l'agilité réduit les coûts en plus).
Posté par BAud (site web personnel) .
Évalué à 4.
Dernière modification le 04 septembre 2021 à 19:31.
bin quand on te parle d'agilité et respecter un cycle en V (ou W), oui tu peux fuir…
vécu : « ya pas de spec' tous est dans l'UC » (oui, UC, ça veut dire use-case donc traduit vite fait du post-it de besoin client en spec cohérente…)
pfff, j'ai fait de l'agile et de l'XP (extreme-programming) quand ce n'était pas encore à la mode (genre avant 2000), mais au moins yavait des specs (différenciant besoin utilisateur, besoin logiciel et implémentation avec des règles de gestion claires, donc documentées).
Il n'y a que dans le logiciel libre et quand j'ai la main sur l'écran du développeur (en entreprise) que j'ai pu le mettre en œuvre.
Sinon, c'est du YOLO, croive qui pourra :-) (mais oui, parfois ça fonctionnait en donnant la bonne information avant la livraison, le TDD a ses limites… cet acronyme est laissé à la bonne volonté du lecteur)
À la mode en France, das la mesure où de plus en plus de boîtes veulent en faire et ne jurent plus que par ce mot même s'il en sont bien loin quand on y regarde de plus près.
Exemple, ces cinq dernières années, j'ai eu des clients qui disaient faire de l'agilité (c'est dans leurs offres d'emplois) parce-que ça utilise Jira et que les spécifications sont changées au jour le jour ou presque (d'ailleurs je sens bien que agilité à certain endroits est juste synonyme de flexibilité insensée)
Pour les coûts, de ce que j'ai vu aussi, c'est quand l'agilité arrive par le marketing qui vend que l'entreprise peut s'adapter à n'importe quel demande de leur clientèle en un claquement de doigt sans autre coup et donc en faisant plus de rentabilité, ou quand le micro-management qui a vendu des réduction de coûts et fait miroiter des marges se retrouve à faire du contexte-switching constant en s'imaginant agile.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Posté par Nibel .
Évalué à 8.
Dernière modification le 04 septembre 2021 à 03:52.
Ce sont des problèmes qui ne peuvent être réglés par l'équipe elle-même, ils nécessitent une intervention de plus haut.
On demande depuis 2 ans un QA qui nous est refusé.
On demande depuis plus d'un an une machine supplémentaire pour faire notre recette interne parce que nos machines actuelles sont saturées.
On demande depuis des mois d'arrêter aux commerciaux de fixer des dates de livraison irréalistes sans discussion préalable avec les équipes techniques. Mais les commerciaux sont les rois.
On demande depuis toujours d'arrêter de modifier le périmètre du sprint tous les jours et de faire rentrer des nouvelles fiches "urgentes" avec une priorisation catastrophique.
L'équipe n'a pas la main là-dessus. On est sous pression de la part de la direction et des commerciaux.
L'agilité ne peut pas fonctionner pour notre équipe. On a plus d'une vingtaine de clients, plus d'une cinquantaines de gammes de produits, chaque produit étant en plus personnalisé par client. Les produits peuvent même avoir des technos différentes et tous les devs de l'équipe ne sont pas en capacité d'intervenir sur toutes les technos (on est plus que 2 devs sur les 7 à pouvoir intervenir sur tous les produits). Et chaque commercial veut chouchouter son client et traiter sa demande le plus vite possible, peu importe si les équipes techniques en ont les capacités.
On VEUT corriger ça. Mais c'est au-dessus que ça ne veut pas.
Et voila comment l'agilité devient un cauchemar.
La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.
Posté par _kaos_ .
Évalué à -7.
Dernière modification le 04 septembre 2021 à 06:11.
On VEUT corriger ça.
Pourtant, le dicton le dit bien : Quand on veut, on peut.
On demande depuis 2 ans un QA qui nous est refusé.
Il suffit de se limiter strictement aux fonctionnalités atomiques demandées pour impacter au minimum l'ensemble en place,
On demande depuis plus d'un an une machine supplémentaire pour faire notre recette interne parce que nos machines actuelles sont saturées.
Avec une bonne CI/CD, le workflow sera totalement transparent car constitué de micro-incréments,
On demande depuis des mois d'arrêter aux commerciaux de fixer des dates de livraison irréalistes sans discussion préalable avec les équipes techniques.
C'est le principe même du release early, non ?
On demande depuis toujours d'arrêter de modifier le périmètre du sprint tous les jours
Par construction, les tâches sont tellement fragmentées qu'elles ne devraient de toute façon pas demander plus d'une journée de travail pour un développeur honnête.
En conclusion, l'agilité n'est vraiment pas faite pour vous, et il faut laisser faire les gens compétents.
Par construction, les tâches sont tellement fragmentées qu'elles ne devraient de toute façon pas demander plus d'une journée de travail pour un développeur honnête.
J'en parlerai à mes connaissances qui font de dev.
Mwahaha !
Ah, bon, bah voilà ce qu'on en pense collégialement…
Non, sérieusement, tu peux découper en toutes petites tâches si ton projet est bien codé, bien conçu, bien architecturé dès l'origine, voire que tu es en mode maintenance.
Mais bon parfois ton boulot de dev, c'est de réécrire des pans de code, et de faire ça sans filet de sécurité (tests automatiques, tests de non régression, etc), et ça se fait pas en une journée, ça n'a pas de sens.
Une simple étude de faisabilité peut prendre plusieurs jours, un comparatif entre deux solutions pour résoudre un problème peut durer plusieurs jours, simplement comprendre le code existant d'une fonctionnalité peut demander plus d'une journée.
Enfin un truc qui va au-delà de changer la couleur de fond du bouton
Quand je lis qu'une tâche ne devrait « honnêtement » pas durer plus d'une journée, j'ai l'impression qu'on a affaire à une équipe de stagiaire super bien encadrée, dans un projet simple et sans impact majeur, avec une chaîne de développement continu parfaitement mise en place, des tests unitaires, des tests de non régression, etc. à chaque commit sur une branche.
Un jeu de société du développement logiciel quoi…
Mais bon, ceci ne représente que mon avis, mâtiné de mon expérience, ça n'engage que moi.
On demande depuis 2 ans un QA qui nous est refusé.
Je ne vois pas le rapport avec la méthode de travail.
On demande depuis plus d'un an une machine supplémentaire pour faire notre recette interne parce que nos machines actuelles sont saturées.
Idem
On demande depuis des mois d'arrêter aux commerciaux de fixer des dates de livraison irréalistes sans discussion préalable avec les équipes techniques. Mais les commerciaux sont les rois.
Je vois pas le rapport avec l'agilité.
On demande depuis toujours d'arrêter de modifier le périmètre du sprint tous les jours et de faire rentrer des nouvelles fiches "urgentes" avec une priorisation catastrophique.
Je présume que vous tentez de faire du scrum et ça c'est interdit. Aucune modification du sprint sans l'accord de l'équipe. Tu peux chercher tout ce qui parle d'engagement (ou commitment) qui parle de ça en scrum.
L'agilité ce n'est pas une prise de pouvoir des commerciaux au contraire la première valeur agile c'est la discussion. Je m'avance, mais j'ai l'impression qu'avant vous étiez protégé par un fonctionnement opaque par rapport au reste de l'entreprise et que maintenant que "l'agilité" a surtout été l'occasion de vous transformer en exécutants.
De mon point de vue le problème de l'agilité c'est d'avoir prêté le flan à tout un tas de choses qui se revendiquent agile mais qui ne le sont pas du tout.
Pour les trois premiers points, si je m'en tiens rigoureusement au manifeste agile :
Construisez les projets à partir de personnes motivées. Donnez-leur l’environnement et le soutien dont elles ont besoin et faites-leur confiance pour mener à bien le travail.
On ne nous donne ni l'environnement (machine) ni le soutient (QA supplémentaire) dont nous avons besoin.
Les personnes en charge du métier ou des affaires et les personnes en charge de la réalisation doivent travailler ensemble chaque jour, tout au long du projet.
Les commerciaux ne travaillent pas avec nous. Ils nous imposent des dates sans tenir compte de nos capacités de réalisation et chaque commercial a le projet le plus urgent du monde.
Je présume que vous tentez de faire du scrum et ça c'est interdit. Aucune modification du sprint sans l'accord de l'équipe. Tu peux chercher tout ce qui parle d'engagement (ou commitment) qui parle de ça en scrum.
Mais l'avis de l'équipe, la direction s'en fout, les commerciaux s'en foutent. On n'est pas maître de notre sprint. Ce sont les commerciaux qui font la pluie et le beau temps sur notre sprint, pas les équipes techniques. Peu importe notre capacité de réalisation, c'est pas l'équipe qui décide, c'est les commerciaux. Et même si c'est totalement en contradiction avec le SCRUM guide, on s'en fout.
Pour résumer en deux lignes, on a déjà fait intervenir deux consultants experts agiles externes différents pour tenter de régler quelques problèmes. Dans les deux cas les bras leur en sont tombés et ils ont conclu : "votre équipe n'est pas adaptée pour de l'agilité, vous devez trouver une autre organisation".
Mais la direction veut qu'on fasse de l'agilité et c'est non-négociable sans nous en donner les moyens, alors on essaye d'appliquer des concepts qui ont pour seuls résultats d'impacter négativement notre productivité, notre humeur, notre qualité de travail.
C'est une injonction dichotomique permanente : faites de l'agilité mais faites comme on vous dit même si ça s'oppose à l'agilité.
La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.
On ne nous donne ni l'environnement (machine) ni le soutient (QA supplémentaire) dont nous avons besoin.
J'ai bien compris mais une autre méthode ferait qu'on réponde à ce besoin ? Ou supprimerait ce besoin ?
Mais l'avis de l'équipe, la direction s'en fout, les commerciaux s'en foutent.
Et c'est quelque chose qui est lié à l'agilité ? Tu semble dire plus haut que tout allait mieux avec la méthode « YOLO » je ne vois pas comment une méthode d'organisation de votre équipe va changer le respect que la boite a pour votre équipe et votre travail.
Tu commence par des reproches contre l'agilité tout en disant que factuellement vous ne faites pas d'agilité. Un grand nombre de discours autour de l'agilité (ainsi qu'un marché autour de ça) est creux et problématique, mais je ne pense pas que ce soit lié à la méthode en elle même. D'ailleurs ça ne concerne que scrum (et peut être safe dans une autre mesure) et bien moins kanban et pas du tout xp (allé je suis sûr qu'aucun des 2 consultants ne connait réellement xp).
Dans l'équipe où je travail, on se fout des méthodes agiles. On a une boucle de feedback toutes les 2 semaines et pour le reste on s'organise comme on souhaite le faire (on a une board pour évaluer le travail en cours qui est inspirée de kanban, mais personnalisée), ce qui se rapproche des sprint planning ne sont pas vraiment des planifications, mais plus une étape pour discuter des nouvelles tâches, etc. À mon sens voir l'agilité comme un ensemble de pattern que tu choisi d'appliquer et comment tu les applique plutôt qu'un framework qui pose un cadre dans le quel tu dois évoluer me semble plus sain.
Dans l'équipe où je travaille, on se fout des méthodes agiles. On a une boucle de feedback toutes les 2 semaines
ah, là oui, ça peut s'appliquer, la visibilité de bout en bout est nécessaire, mais quand tu as une MOA qui te rétorque que tout a été dit dans la RU précédente, dont il n'y a pas de CR, bin là tu t'enfonces avant de vouloir les défoncer :D)
Je ne comprends pas où tu veux en venir ? C'est une plainte que tu travailles dans un contexte que tu n'aime pas ?
Que ce soit toi ou les autres vous êtes entrain d'expliquer que dans des entreprises dysfonctionnelles l'agilité ne marche pas. Et oui ça ne fait pas des miracle. Incroyable n'est-ce pas ?
Aucune méthode agile refuse complètement les spécifications. Elles disent qu'elles peuvent être remises en cause en court de route du fait d'une évolution des besoins ou des interactions entre les développements et les commanditaires.
Faire n'importe quoi, appeler ça de l'agilité et se dire que c'est bien pourri. Rigolo 3 minutes, mais ça ne sert pas à grand chose si le but c'est de savoir comment s'organiser (après si le but est simplement de se plaindre ça marche bien je suis d'accord).
On demande depuis 2 ans un QA qui nous est refusé.
Plutôt que d'essayer d'obtenir des compétences externes, il faut développer son Just-In time learning grâce à une gamification adéquate et utiliser à bon escient ses relationships.
On demande depuis plus d'un an une machine supplémentaire pour faire notre recette interne parce que nos machines actuelles sont saturées
Plutôt que de maintenir des ordinateurs dépassés, il faut mettre en place une stratégie de cloud bursting qui sera la base d'une sustainable innovation
On demande depuis des mois d'arrêter aux commerciaux de fixer des dates de livraison irréalistes sans discussion préalable avec les équipes techniques. Mais les commerciaux sont les rois.
Plutôt que de relever les points négatifs de ses collègues, il faut identifier des change champions en charge d'être moteur des paradigms shifts qui vous permettront d'être future ready.
On demande depuis toujours d'arrêter de modifier le périmètre du sprint tous les jours et de faire rentrer des nouvelles fiches "urgentes" avec une priorisation catastrophique.
Plutôt que de s'adapter aux contraintes, il faut faire un deep dive sur les causes vous empêchant d'engager vos clients correctement.
À leur décharge (bon, tapez pas, j'essaye), ça perd beaucoup à la traduction, genre
"sûreté de fonctionnement est efficiente" j'imagine que c'est "operationnal efficency".
j'avoue par contre "découpler budget annuel et engagements de dépenses, agiliser la gestion budgétaire, et lisser les « projets » sur plusieurs exercices." je laisse tombé, je leur trouve pas d'excuse.
Et puis en relisant un peu en essayant de comprendre, je me dis que c'est juste une grosse blague en fait ? Hein, c'est ça ? Second degrés voire plus, tout ça ? Mince je suis presque tombé dedans.
Autres hypothèses, ils testent une nouvelle IA à base de pipotron.
Ne rigole pas. J'ai eu un client qui me payait pour faire ce genre de choses mais plus joliment… Lui était très bien payé pour faire des formations avec plein de mots dans le genre. D'ailleurs, tu as oublié "engagement" et "enpowerment".
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
Et alors, je vois sur linkedin que ce client est coach "agile". C'est bien ce que je disais, c'est la fois du marketing et à la mode. Et ça n'a plus grand chose à voir avec le développement informatique.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
Je ne sais pas ce qui me déconcerte le plus là dedans: le buzzword bingo gagnant à chaque paragraphe, le fait cue l'entreprise soit domiciliée dans une péniche, ou le nom de la péniche qui est unjeu de mot digne des meilleurs salons de coiffure?
Plutôt qu’adopter par voie hiérarchique le modèle Spotify en squad et tribu*T*s, aller vers le management de soutien qui évite l’injonction d’être agile.
# J'en ai une 11ème
Posté par Milo . Évalué à 10. Dernière modification le 03 septembre 2021 à 17:31.
La 11ème façon c'est de laisser des consultants jargonner à tout va et pondre des textes imbitables …..
[^] # Re: J'en ai une 11ème
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 5. Dernière modification le 03 septembre 2021 à 17:43.
Imbitables et creux je dirais même.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: J'en ai une 11ème
Posté par Nibel . Évalué à 3.
Pour faire plus creux que l'agilité elle-même, fallait forcer…
Je suis fondamentalement convaincu que ce modèle est en train de tuer l'entreprise dans laquelle je travaille, nos talents s'en vont un par un, chaque fin de sprint sont remontés les même problèmes pour ne jamais être traités, les équipes sont à bout.
Chez nous, c'était la méthode YOLO qui fonctionnait bien. Puis on a changé de direction…
Ah ça fait joli pour les clients. Mais derrière la jolie façade, on est tous en souffrance. Mais bon, on est agile alors tout va bien hein…
La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.
[^] # Re: J'en ai une 11ème
Posté par barmic 🦦 . Évalué à 7.
Le manifest agile explique pourtant :
Loin de moi l'idée de te dire comment tu dois ou pas t'organiser dans ton travail, mais ne pas respecter la méthode et la blâmer ne me semble pas correct. Je ne sais pas pourquoi vous l'implémenter mal (mauvaise compréhension à différents niveaux, sabotage, mauvais contexte,…),mais refuser de corriger les problèmes rencontrés quelque soit la méthode de travail me semble regrettable et je peux comprendre tant de départs.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: J'en ai une 11ème
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 7.
Il se trouve que dans beaucoup d'endroits on comprend mal ce qu'est l'agilité et donc on fait un peu n'imp.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: J'en ai une 11ème
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 1. Dernière modification le 04 septembre 2021 à 13:00.
Surtout, l'agilité est d'abord, souvent, un argument marketing vu que c'est à la mode (et peut-être aussi une façon de diminuer les coûts).
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: J'en ai une 11ème
Posté par barmic 🦦 . Évalué à 5.
À la mode ? Depuis 20 ans ?
C'est un reproche ? Parce qu'en soit diminuer les coûts n'est pas un problème c'est plutôt comment qui peut être un problème ou au détriment de quoi (bon je ne vois pas en quoi l'agilité réduit les coûts en plus).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: J'en ai une 11ème
Posté par BAud (site web personnel) . Évalué à 4. Dernière modification le 04 septembre 2021 à 19:31.
bin quand on te parle d'agilité et respecter un cycle en V (ou W), oui tu peux fuir…
vécu : « ya pas de spec' tous est dans l'UC » (oui, UC, ça veut dire use-case donc traduit vite fait du post-it de besoin client en spec cohérente…)
pfff, j'ai fait de l'agile et de l'XP (extreme-programming) quand ce n'était pas encore à la mode (genre avant 2000), mais au moins yavait des specs (différenciant besoin utilisateur, besoin logiciel et implémentation avec des règles de gestion claires, donc documentées).
Il n'y a que dans le logiciel libre et quand j'ai la main sur l'écran du développeur (en entreprise) que j'ai pu le mettre en œuvre.
Sinon, c'est du YOLO, croive qui pourra :-) (mais oui, parfois ça fonctionnait en donnant la bonne information avant la livraison, le TDD a ses limites… cet acronyme est laissé à la bonne volonté du lecteur)
et qu'on ne me parle pas de ISO 9003 /o\
[^] # Re: J'en ai une 11ème
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 4.
À la mode en France, das la mesure où de plus en plus de boîtes veulent en faire et ne jurent plus que par ce mot même s'il en sont bien loin quand on y regarde de plus près.
Exemple, ces cinq dernières années, j'ai eu des clients qui disaient faire de l'agilité (c'est dans leurs offres d'emplois) parce-que ça utilise Jira et que les spécifications sont changées au jour le jour ou presque (d'ailleurs je sens bien que agilité à certain endroits est juste synonyme de flexibilité insensée)
Pour les coûts, de ce que j'ai vu aussi, c'est quand l'agilité arrive par le marketing qui vend que l'entreprise peut s'adapter à n'importe quel demande de leur clientèle en un claquement de doigt sans autre coup et donc en faisant plus de rentabilité, ou quand le micro-management qui a vendu des réduction de coûts et fait miroiter des marges se retrouve à faire du contexte-switching constant en s'imaginant agile.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: J'en ai une 11ème
Posté par Nibel . Évalué à 8. Dernière modification le 04 septembre 2021 à 03:52.
Ce sont des problèmes qui ne peuvent être réglés par l'équipe elle-même, ils nécessitent une intervention de plus haut.
On demande depuis 2 ans un QA qui nous est refusé.
On demande depuis plus d'un an une machine supplémentaire pour faire notre recette interne parce que nos machines actuelles sont saturées.
On demande depuis des mois d'arrêter aux commerciaux de fixer des dates de livraison irréalistes sans discussion préalable avec les équipes techniques. Mais les commerciaux sont les rois.
On demande depuis toujours d'arrêter de modifier le périmètre du sprint tous les jours et de faire rentrer des nouvelles fiches "urgentes" avec une priorisation catastrophique.
L'équipe n'a pas la main là-dessus. On est sous pression de la part de la direction et des commerciaux.
L'agilité ne peut pas fonctionner pour notre équipe. On a plus d'une vingtaine de clients, plus d'une cinquantaines de gammes de produits, chaque produit étant en plus personnalisé par client. Les produits peuvent même avoir des technos différentes et tous les devs de l'équipe ne sont pas en capacité d'intervenir sur toutes les technos (on est plus que 2 devs sur les 7 à pouvoir intervenir sur tous les produits). Et chaque commercial veut chouchouter son client et traiter sa demande le plus vite possible, peu importe si les équipes techniques en ont les capacités.
On VEUT corriger ça. Mais c'est au-dessus que ça ne veut pas.
Et voila comment l'agilité devient un cauchemar.
La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.
[^] # Re: J'en ai une 11ème
Posté par _kaos_ . Évalué à -7. Dernière modification le 04 septembre 2021 à 06:11.
Pourtant, le dicton le dit bien : Quand on veut, on peut.
Il suffit de se limiter strictement aux fonctionnalités atomiques demandées pour impacter au minimum l'ensemble en place,
Avec une bonne CI/CD, le workflow sera totalement transparent car constitué de micro-incréments,
C'est le principe même du release early, non ?
Par construction, les tâches sont tellement fragmentées qu'elles ne devraient de toute façon pas demander plus d'une journée de travail pour un développeur honnête.
En conclusion, l'agilité n'est vraiment pas faite pour vous, et il faut laisser faire les gens compétents.
Nan mais on croit rêver !
Matricule 23415
[^] # Re: J'en ai une 11ème
Posté par Yth (Mastodon) . Évalué à 5.
J'en parlerai à mes connaissances qui font de dev.
Ah, bon, bah voilà ce qu'on en pense collégialement…
Non, sérieusement, tu peux découper en toutes petites tâches si ton projet est bien codé, bien conçu, bien architecturé dès l'origine, voire que tu es en mode maintenance.
Mais bon parfois ton boulot de dev, c'est de réécrire des pans de code, et de faire ça sans filet de sécurité (tests automatiques, tests de non régression, etc), et ça se fait pas en une journée, ça n'a pas de sens.
Une simple étude de faisabilité peut prendre plusieurs jours, un comparatif entre deux solutions pour résoudre un problème peut durer plusieurs jours, simplement comprendre le code existant d'une fonctionnalité peut demander plus d'une journée.
Enfin un truc qui va au-delà de changer la couleur de fond du bouton
Quand je lis qu'une tâche ne devrait « honnêtement » pas durer plus d'une journée, j'ai l'impression qu'on a affaire à une équipe de stagiaire super bien encadrée, dans un projet simple et sans impact majeur, avec une chaîne de développement continu parfaitement mise en place, des tests unitaires, des tests de non régression, etc. à chaque commit sur une branche.
Un jeu de société du développement logiciel quoi…
Mais bon, ceci ne représente que mon avis, mâtiné de mon expérience, ça n'engage que moi.
[^] # Re: J'en ai une 11ème
Posté par _kaos_ . Évalué à 4. Dernière modification le 04 septembre 2021 à 17:35.
Petit indice : j'ai été dev pendant 15 ans à plein temps, et je suis toujours dans ce milieu, je connais très bien les a prioris.
Manifestement suffisamment pour masquer le subterfuge du second degré :)
Je n'aurais jamais attaqué aussi frontalement si j'étais sérieux.
Matricule 23415
[^] # Re: J'en ai une 11ème
Posté par barmic 🦦 . Évalué à 8.
Je ne vois pas le rapport avec la méthode de travail.
Idem
Je vois pas le rapport avec l'agilité.
Je présume que vous tentez de faire du scrum et ça c'est interdit. Aucune modification du sprint sans l'accord de l'équipe. Tu peux chercher tout ce qui parle d'engagement (ou commitment) qui parle de ça en scrum.
L'agilité ce n'est pas une prise de pouvoir des commerciaux au contraire la première valeur agile c'est la discussion. Je m'avance, mais j'ai l'impression qu'avant vous étiez protégé par un fonctionnement opaque par rapport au reste de l'entreprise et que maintenant que "l'agilité" a surtout été l'occasion de vous transformer en exécutants.
De mon point de vue le problème de l'agilité c'est d'avoir prêté le flan à tout un tas de choses qui se revendiquent agile mais qui ne le sont pas du tout.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: J'en ai une 11ème
Posté par Nibel . Évalué à 9.
Pour les trois premiers points, si je m'en tiens rigoureusement au manifeste agile :
On ne nous donne ni l'environnement (machine) ni le soutient (QA supplémentaire) dont nous avons besoin.
Les commerciaux ne travaillent pas avec nous. Ils nous imposent des dates sans tenir compte de nos capacités de réalisation et chaque commercial a le projet le plus urgent du monde.
Mais l'avis de l'équipe, la direction s'en fout, les commerciaux s'en foutent. On n'est pas maître de notre sprint. Ce sont les commerciaux qui font la pluie et le beau temps sur notre sprint, pas les équipes techniques. Peu importe notre capacité de réalisation, c'est pas l'équipe qui décide, c'est les commerciaux. Et même si c'est totalement en contradiction avec le SCRUM guide, on s'en fout.
Pour résumer en deux lignes, on a déjà fait intervenir deux consultants experts agiles externes différents pour tenter de régler quelques problèmes. Dans les deux cas les bras leur en sont tombés et ils ont conclu : "votre équipe n'est pas adaptée pour de l'agilité, vous devez trouver une autre organisation".
Mais la direction veut qu'on fasse de l'agilité et c'est non-négociable sans nous en donner les moyens, alors on essaye d'appliquer des concepts qui ont pour seuls résultats d'impacter négativement notre productivité, notre humeur, notre qualité de travail.
C'est une injonction dichotomique permanente : faites de l'agilité mais faites comme on vous dit même si ça s'oppose à l'agilité.
La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.
[^] # Re: J'en ai une 11ème
Posté par barmic 🦦 . Évalué à 3.
J'ai bien compris mais une autre méthode ferait qu'on réponde à ce besoin ? Ou supprimerait ce besoin ?
Et c'est quelque chose qui est lié à l'agilité ? Tu semble dire plus haut que tout allait mieux avec la méthode « YOLO » je ne vois pas comment une méthode d'organisation de votre équipe va changer le respect que la boite a pour votre équipe et votre travail.
Tu commence par des reproches contre l'agilité tout en disant que factuellement vous ne faites pas d'agilité. Un grand nombre de discours autour de l'agilité (ainsi qu'un marché autour de ça) est creux et problématique, mais je ne pense pas que ce soit lié à la méthode en elle même. D'ailleurs ça ne concerne que scrum (et peut être safe dans une autre mesure) et bien moins kanban et pas du tout xp (allé je suis sûr qu'aucun des 2 consultants ne connait réellement xp).
Dans l'équipe où je travail, on se fout des méthodes agiles. On a une boucle de feedback toutes les 2 semaines et pour le reste on s'organise comme on souhaite le faire (on a une board pour évaluer le travail en cours qui est inspirée de kanban, mais personnalisée), ce qui se rapproche des sprint planning ne sont pas vraiment des planifications, mais plus une étape pour discuter des nouvelles tâches, etc. À mon sens voir l'agilité comme un ensemble de pattern que tu choisi d'appliquer et comment tu les applique plutôt qu'un framework qui pose un cadre dans le quel tu dois évoluer me semble plus sain.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: J'en ai une 11ème
Posté par BAud (site web personnel) . Évalué à 3.
ah, là oui, ça peut s'appliquer, la visibilité de bout en bout est nécessaire, mais quand tu as une MOA qui te rétorque que tout a été dit dans la RU précédente, dont il n'y a pas de CR, bin là tu t'enfonces avant de vouloir les défoncer :D)
oui, j'ai laissé quelques acronymes…
[^] # Re: J'en ai une 11ème
Posté par barmic 🦦 . Évalué à 3.
Je ne comprends pas où tu veux en venir ? C'est une plainte que tu travailles dans un contexte que tu n'aime pas ?
Que ce soit toi ou les autres vous êtes entrain d'expliquer que dans des entreprises dysfonctionnelles l'agilité ne marche pas. Et oui ça ne fait pas des miracle. Incroyable n'est-ce pas ?
Aucune méthode agile refuse complètement les spécifications. Elles disent qu'elles peuvent être remises en cause en court de route du fait d'une évolution des besoins ou des interactions entre les développements et les commanditaires.
Faire n'importe quoi, appeler ça de l'agilité et se dire que c'est bien pourri. Rigolo 3 minutes, mais ça ne sert pas à grand chose si le but c'est de savoir comment s'organiser (après si le but est simplement de se plaindre ça marche bien je suis d'accord).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: J'en ai une 11ème
Posté par NicolasP . Évalué à 6.
Plutôt que d'essayer d'obtenir des compétences externes, il faut développer son Just-In time learning grâce à une gamification adéquate et utiliser à bon escient ses relationships.
Plutôt que de maintenir des ordinateurs dépassés, il faut mettre en place une stratégie de cloud bursting qui sera la base d'une sustainable innovation
Plutôt que de relever les points négatifs de ses collègues, il faut identifier des change champions en charge d'être moteur des paradigms shifts qui vous permettront d'être future ready.
Plutôt que de s'adapter aux contraintes, il faut faire un deep dive sur les causes vous empêchant d'engager vos clients correctement.
Voilà, je peux postuler sur la péniche ?
[^] # Re: J'en ai une 11ème
Posté par steph1978 . Évalué à 2.
À leur décharge (bon, tapez pas, j'essaye), ça perd beaucoup à la traduction, genre
"sûreté de fonctionnement est efficiente" j'imagine que c'est "operationnal efficency".
j'avoue par contre "découpler budget annuel et engagements de dépenses, agiliser la gestion budgétaire, et lisser les « projets » sur plusieurs exercices." je laisse tombé, je leur trouve pas d'excuse.
Et puis en relisant un peu en essayant de comprendre, je me dis que c'est juste une grosse blague en fait ? Hein, c'est ça ? Second degrés voire plus, tout ça ? Mince je suis presque tombé dedans.
Autres hypothèses, ils testent une nouvelle IA à base de pipotron.
# Grand Merci Très Honoré
Posté par volts . Évalué à 5.
Grâce à cet article, j'ai fait mon business loto de la semaine :3
Oui, j'ai honteusement généré le loto depuis un logiciel dans un nuage. Personne n'est parfait…
[^] # Re: Grand Merci Très Honoré
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 4.
Ne rigole pas. J'ai eu un client qui me payait pour faire ce genre de choses mais plus joliment… Lui était très bien payé pour faire des formations avec plein de mots dans le genre. D'ailleurs, tu as oublié "engagement" et "enpowerment".
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: Grand Merci Très Honoré
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 2.
Et alors, je vois sur linkedin que ce client est coach "agile". C'est bien ce que je disais, c'est la fois du marketing et à la mode. Et ça n'a plus grand chose à voir avec le développement informatique.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: Grand Merci Très Honoré
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
C'est le mélange de langues qui ne me fait pas monter au ciel ; je ne comprends pas tous ces mots qui ne sont point dans mon Larousse
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Grand Merci Très Honoré
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 3.
Même quand on les comprend, on fait on ne les comprend pas parce qu'ils sont bizarrement employés.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
# Péniche Nouvelle Vague
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 4. Dernière modification le 03 septembre 2021 à 23:55.
Je ne sais pas ce qui me déconcerte le plus là dedans: le buzzword bingo gagnant à chaque paragraphe, le fait cue l'entreprise soit domiciliée dans une péniche, ou le nom de la péniche qui est unjeu de mot digne des meilleurs salons de coiffure?
# Lapsus révélateur ?
Posté par El Titi . Évalué à 1.
[^] # Re: Lapsus révélateur ?
Posté par BAud (site web personnel) . Évalué à 2.
ya une contrepèterie ?
[^] # Re: Lapsus révélateur ?
Posté par El Titi . Évalué à 2.
https://www.larousse.fr/dictionnaires/francais/tribut/79526
vs
https://www.larousse.fr/dictionnaires/francais/tribu/79517
[^] # Re: Lapsus révélateur ?
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
On parle bien d'organisation tribale d'escouades, donc sans thé…
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Lapsus révélateur ?
Posté par El Titi . Évalué à 2.
Oui et il y a en un dans l'article. D'où mon titre.
[^] # Re: Lapsus révélateur ?
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Oups oui, ai mentalement corrigé …désolé pour le bruit.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.