Reprise du message précédent :

 
Ben je ne pense pas que ce soit contradictoire. Effectivement, sur ce sujet, je pense que les biais sont très nombreux. Ça ne m’empêche pas d’avoir une opinion moi-même et qui n’est pas autant arrêtée que tu sembles le penser. J’ai longtemps défendu SCRUM,  le manifesto (d'ailleurs je continue à en défendre la plus grande partie), et même le principe des sprints.
Le seul reproche qu’on pourrait me faire, c’est de ne pas détacher (pour le moment, je pense éditer mes messages plus tard) mes opinions de mon genre d’exposé qui n’en d'ailleurs même pas vraiment un. Je pose quelques bases pour ouvrir la discussion et comme tout topic sur un forum comme HFR, c’est aussi fait pour faire réagir. J’ai ni la prétention, ni probablement les compétences pour faire un exposé sur un sujet aussi complexe d'une manière parfaitement neutre.
Si tu penses que qu'un SCRUm classique correctement implémenté avec des sprints peut marcher, c'est super, tu peux très bien le défendre ici, et même ça m’intéresse. C’est pas parce qu'on a pas réussi que c'est impossible, et même le fait que je connaisse bcp de monde qui sont contre (pour des raisons souvent différentes d’ailleurs), ça ne prouve rien dans l'absolu. J’ai mon opinion, mais ça s’arrête là.

Témoignage un peu extrême, mais voilà où ça peut mener quand c'est pris en main par des managers farfelus ou zélés :

https://agile.developpez.com/actu/3 [...] ificielle/

J'ai comme vous l'avez vu un appriori négatif sur tout ça mais perso, j'apprécie l'opinion de Hermes car elle est justement tempérée et il semble conscient des dérives possibles. Ça me permet de voir un peu plus le côté positif de la chose sur ce topic.  
 
Le soucis est que (tres) trop souvent, les gens amènent l'agile comme la bible ou le coran.  

Hermes est surement mesuré grâce à son parcours de dev où il a vu ce que c'était d'être de l'autre côté.
Comme toute méthode il faut piocher ce qui peut fonctionner pour l'équipe en place

J'ai connu que la méthode agile dans mes différents jobs car j'ai principalement bossé dans des startups.
J'ai jamais connu l'enfer que décrivent certains.
 
Par contre mes reproches à cette méthode sont les suivants:
- difficile de faire des trucs un peu long terme ou un peu R&D: on est encouragés à avoir un vision court-termiste car on travaille à l'échelle de quelques semaines (mais aussi c'est très lié à la typologie de boite dans lesquelles j'ai bossé)
- management qui veut les avantages de l'agile sans les inconvénients (veulent à la fois de l'agilité et des plannings à 6 mois dans lesquels tu t'engages sur la date de livraison d'une feature X)

Ici on fait beaucoup de R&D, et très peu de développement adhoc
On travaille sur des projets dont la faisabilité/intérêt est parfois remise en cause après quelques semaines de recherche/prototypage
Donc y attribuer des sprints courts avec points calculés et connus à l'avance ça se résume un peu à faire du Mme Irma

J'suis d'accord sur les deux points.
 
Et ton parallèle est d'autant plus adéquat que dans les deux cas, les gens qui martèlent n'ont souvent soit pas lu ou soit pas compris
 
Après j'en ai probablement fait brièvement partie aussi parce que du point de vue d'un grouillot, l'agile fait miroiter pas mal d'avantages; dans mon cas j'ai particulièrement été sensible au dialogue plus direct avec le métier et au fait (lié) de donner plus de sens à ce que je faisais. Du coup j'avais l'impression d'avoir un intérêt assez direct à ce que ça fonctionne bien, mais comme évidemment ça fonctionnait pas bien... Ça braque.
Mais les promesses n'engagent que ceux qui les croient et à moins d'être particulièrement aveugle il est souvent clair assez rapidement que tu peux pas grand-chose au fait que ça fonctionne pas bien, et c'est le moment de lâcher prise. En vrai ça fait un petit moment que je suis reparti en mode ballec sur le sujet. J'ai les certifs et je connais suffisamment la théorie et le vocabulaire pour que ça ne me coupe pas d'opportunités, après je m'adapte en fonction.
 
Après c'est comme beaucoup de choses (genre le communisme ), on te vend un truc qui se base sur des prérequis inatteignables et qui ne marchera jamais vraiment (là je reparle de Scrum en particulier), mais ça veut pas dire que c'est complètement de la merde non plus. Bien au contraire même, en l’occurrence il y a beaucoup de bonnes idées dedans - reste à identifier lesquelles peuvent être adaptées à son contexte du moment pour en tirer quelque chose. Tu feras pas du VRAI SCRUM mais tu en tireras quand même des avantages.
 
... Et c'est ce qu'Hermès est en train de décrire je pense (j'avoue ne pas avoir tout lu mais je le ferai promis). Avec l'intérêt supplémentaire de son job, pour moi en tout cas, parce que qu'un CTO ça voit pas la même chose qu'un grouillot.

Bon le second oui, mais bon c'est pas la faute à agile
 
Le premier je suis aussi d'accord, si tu parles de Scrum/sprints. Rien que le passage d'une grosse user story en sous-stories pour que ça tienne dans des sprints peut déjà faire perdre suffisamment de contexte pour qu'une fois dessus, associé avec la mentalité agile "on implémente le strict minimum pour que la tâche soit complète", le résultat soit du code qui fonctionne pour la story en question mais en réalité dès le sprint suivant compliquera la mise en place de la suite, avec au global une perte d'efficacité sur le long terme vs avoir fait toute la spec d'un coup au début. Ya pas de miracle, en pratique il faut jamais vraiment laisser un dev faire ce qu'il veut même si c'est un des points de base de l'agile... Il te faut un membre de l'équipe "moins égal" que les autres pour surveiller l'architecture logicielle et penser long terme - et ça aussi, de base ça va un peu à l'encontre de l'agile.

Et comme jamais deux sans trois, je donne mon avis sur un truc qui a TOUJOURS posé de gros problèmes dans tous mes projets Scrum: le PO.
 
- indépendamment de tout le reste, la qualité du PO aura un impact absolument énorme sur les résultats de l'équipe. Ton équipe peut surperformer, si c'était vers des trucs pas importants parce que le PO fait mal son boulot, c'est DTC pour tout le monde. Pareil si besoins mal compris, mal définis, etc.
- en même temps, être un bon PO est extrêmement difficile. La théorie veut qu'il connaisse le métier et les besoins sur le bout des doigts, soit toujours dispo, soit bon communiquant envers le client ET l'équipe... Un mix de Jésus et de Superman.
- un mauvais PO va amener à des séances de grooming longues et laborieuses et/ou des stories pas claires et donc réduite d'autant le temps de boulot effectif de l'équipe
- pour couronner le tout en théorie il est seul. Un autre membre de l'équipe en vacances ça réduit un peu la vélocité. Un PO en vacances, avec un peu de malchance ça peut ruiner un sprint complet.

 
Je plussoie énormément ce message.  

Bon, je viens d'éditer enfin mon troisième post pour y décrire notre application de la méthode NNL. Je précise bien NOTRE application avec NOS solutions.
 
J'éditerai probablement les 3 premiers posts avec des warnings etc... Et prendre en compte vos remarques.  
 
Please be patient (j'ai pas bcp de temps )
 
N'hésitez pas à dire ce que vous en pensez. Si vous pensez que c'est WTF, dites le, mais surtout dites pourquoi et pourquoi il n'y aurait aucune chance que cela puisse marcher chez vous
 
https://forum.hardware.fr/forum2.ph [...] #t70351421

Drap, les premiers posts ainsi que les divers retours d'XP sont très intéressants

Drapal

Merci HLM pour ce topic. Ca va me faire un peu de lecture
 
Edit : j'ai fini de lire la première page. Mais je suis au boulot et j'ai pas les images d'illustration (filtrage).

Petite question sur l'estimation de la charge des tâches par les membres de l'équipe. C'est fait de manière anonyme sans communication entre les membres ? Parce que si c'est fait en groupe, chacun donne à son tour son estimation, le premier qui va parler va automatiquement induire un biais d'ancrage
 
C'est d'ailleurs une méthode bien connue lors d'un vote quand on n'est pas sûr d'avoir une décision prise à la majorité qui va dans le sens qu'on veut. On demande aux x premiers dont on sait qu'ils vont voter dans notre sens de s'exprimer en premier. Les indécis vont alors le plus souvent voter dans le sens du début de majorité constituée. Ceux contre vont alors soient voter comme ils le voulaient soit carrément changer leur vote pour ne pas aller contre la majorité.

Lors de ma formation sur l’agilité on utilisait le jeu de carte du poker planning (suite de Fibonacci). Sur ma mission actuelle tu mets le score dans la conversation de la réunion Teams après un top.

Si c'est IRL, le principe c'est que tout le monde retourne sa carte/son papier en même temps, justement pour éviter tout ça.
 
Ce que j'aimais bien faire aussi, c'est de faire une première passe directement après avoir lu les requirements, avant même toute discussion dans l'équipe. Parce que sinon si t'as des devs qui commencent à partir dans des "c'est facile, on à qu'à faire comme si ou comme ça" (ou inversement en mode c'est infaisable) ça peut aussi facilement baiser les avis des autres.

Tu ne le trouves pas un peu blême ?

Je pensais à un truc : pour le NNL, ne serait-il pas intéressant de découper la colonne "Maintenant" de la manière suivante :
- colonne coupée en 2 horizontalement. En haut, on y met les tâches à faire.
- la partie basse de la colonne est découpée en plusieurs colonnes : urgent, en cours, à tester.
 
J'irais même plus loin. Sur le principe énoncé par le géographe Jacques Bertin "une carte doit être vue avant d'être lue", on pourrait supprimer la colonne "urgent" et mettre un code couleur (par ex, rouge) sur les tâches urgentes. On garderait les tags pour indiquer le produit et d'autres infos sur les tâches.
 
Qu'en pensez-vous ? Bonne ou mauvaise idée ?

 
Ce que je montre dans mon document, c'est une simplification du principe NNL. Tu peux donc organiser les choses à ta guise et même rajouter des colonnes pour avoir un NOW plus organisé, utiliser différents tags etc...
 
Ce qui compte à mon sens c'est :
 
- Garder le maximum de simplicité et de lisibilité
- Avoir constamment la road map sous les yeux
- Pouvoir gérer les resources, surtout quand différents projets utilisent les mêmes resources.
 
Sinon, dans la colonne NOW, les taches sont organisées du haut vers le bas. Tu peux "stick" certaines tâches urgentes ou importantes en haut de la colonne. Mais il existe effectivement de multiples manières d'organiser la colonne NOW et/ou de la découper.

Un truc que j'aime pas avec les sous-decoupage de "Now" / "En cours" (ou whatever le nom que tu lui donnes dans ta méthode), c'est que:
- Ou tu t’arrêtes ? Genre tu as probablement une étape de review aussi, tu ajoutes une sous catégories "Review en cours ?" Idem pour toutes les "sous etapes" propres a chaque Boite/Equipe/Process
- Sur ces sous étapes (typiquement entre testing et dev, ou dev et review), tu peux facilement avoir des aller-retours. Genre un bug est trouve en testing, du coup ca repart en dev. Tu fais quoi ? Si tu (re)bouges a chaque fois la tache, tu passes ton temps a faire de la maintenance des cartes pour t'assurer qu'elles soient vraiment synchro avec ce qui se passe réellement, par contre si une fois a l’étape "Review" ou "Test" tu les (re)bouges jamais vers le dev, bin tu peux avoir une tache qui reste très longtemps en Review ou Tests (si gros débats lors de la review, ou gros bugs trouves en Testing par exemple) et du coup je ne sais pas si sous-decouper donne beaucoup plus d'infos que juste une grosse colonne "Now"

 
C'est tout à fait mon observation ici.    
 
Ici on utilise des tags quand c'est nécessaire. La seule colonne de statut rescapée des méthodes précédentes "classiques", c'est la colonne "done" chez nous.

Mon sous-découpage, c'était surtout pour faire la distinction entre les tâches n'ayant pas débutées et celles en cours. Je suis d'accord qu'on pourrait se contenter de 2 cases dans "now" : à faire : en cours.

Pourquoi ne pas simplement les mettre tout en haut de "Next" dans ce cas ?

Vrai question hein, j'essaye pas de piéger. Mais en 15 ans, j'ai teste pas mal de méthodologie de dev et d'outils divers (du Trello super simple avec 3 colonnes a du board Jira hyper détaille) et si aucun système n'est parfait, j'ai l'impression que le système le moins mauvais est au final le plus simple, du coup je me bas constamment pour essayer de simplifier au max le bouzin

Edit: Mais disons que j'ai l'impression que si tu bascules un sous ensemble de taches de "Next" vers "Now > Todo" t'es un peu en train de refabriquer un "sprint" (vu que t'auras pre-selectionne une liste de taches a faire) dans ton NNL (alors OK t'as peut être pas la "deadline" de fin de sprint qui va tomber toutes les X semaines, mais ca me donne ce sentiment)

 
Il y a une différence fondamentale entre NNL et les autres méthodes : c'est l'omniprésence de la roadmap. Tu gardes une vue d'ensemble en permanence qui te permet de donner constamment du sens à la production. Tu sais toujours où tu en es et les autres départements qui ont accès au planner aussi.  
Le NNL en plus, ne comporte pas que des tâches. Dans les colonnes NEXT et LATER, tu as essentiellement des projets qui peuvent être découpés en tâches au dernier moment avant d'entrer dans la colonne NOW. Pour garder plus de visibilité et le lien entre tâches et projets, on utilise des checklists au sein des cards sur le planner (on utilise Microsoft planner).
 
Ayant bien utilisé les méthodes plus classiques basées sur SCRUM puis ensuite pure Kanban, ça fait une très grosse différence. Parce que tu es toujours avec ta vue d'ensemble du produit alors qu'avant, on était uniquement centré sur la production avec une road map détachée, statique et au final constamment outdated qui ne reflétait même plus ce qu'on essayait de faire.
 
Faire sauter les sprints et les deadlines, tu n'as pas besoin de NNL. Pure Kanban suffit pour ça (voir mon deuxième post sur ce thread)
 
La véritable agilité ne se trouve pas dans la production. Elle se trouve au niveau de la roadmap. C'est ce que j'ai mis des années à comprendre.

Je le voyais pas comme ça mon découpage en 2 de la colonne "now". On voit ainsi toutes les tâches prêtes à être instanciées/lancées et celles en cours de traitement.
Après, si tu as un statut sous forme de tag sur chaque tâche, tu auras aussi l'info mais ça sera peut être mois visuel. Encore une fois, j'applique le principe de Jacques Bertin : "une carte doit être vue avant d'être lue"
Notre cerveau réagit beaucoup mieux aux tailles des objets et couleurs qu'aux textes. Donc, avoir une case pour le à faire et une pour le en cours, avoir des couleurs en fonction de l'urgence et pourquoi pas une taille du rectangle différente représentant chaque tâche suivant sa charge (petite rectangle = faible charge, gros rectangle = grosse charge) ça facilite la lecture d'un premier coup d'oeil le kanban. Après, si tu veux plus de détail, tu vas lire les tags mis sur tes tâches.

Je comprend pas le rapport avec mon post
Même si je suis d'accord avec le fond, je trouve aussi super important de connaître la vision long terme, le contexte et le POURQUOI on bosse sur telle tache/projet (et pour être clair: même pour un dev, ca doit pas être réserve au PO ou whatever le nom que la boite donne au gestionnaire du projet/soft/programme).
 
Après je trouve qu'aussi une des difficultés dans tout projet management, c'est le niveau de granularité du decoupage: a quel point tes taches sont petites ou grosses ?  
Genre tu as un projet (feature/business oriented), qui implique du dev nouveau, mais avec un gros refactoring en pre-requis.  
Est ce que ce refactoring est lui même un projet (je dirais que non, mais je peux comprendre l'argument inverse) ? Si tu as 2-3 dev qui bossent dessus en meme temps par exemple pendant 2 semaines, est ce que c'est une seule tache ? Une tache par dev ? Une tache par "module technique" ?
 
Et c'est aussi indirectement en lien avec la question bonus, quid des Epic ? Pour des grosses applications, un découpage en "juste" deux niveaux c'est pas toujours suffisant (ou alors tu te retrouves avec des projets immenses), et l'etage N+3 est pas forcement intéresse par le detail des 10 projets nécessaires pour mener a bien tel objectif roadmap/business.
 
 
@rufo: Pas sur de bien comprendre ton point: visuellement, savoir qu'il faut prendre les taches "de haut en bas" depuis la colonne NEXT me parait encore plus simple que de rajouter une sous-colonne "TODO" dans ta colonne "NOW" (surtout qu'encore une fois, si tu mets le doigts dans cet engrenage, tu risques de te retrouver dans 2 ans avec pleins d'autres sous colonnes).

Dans la colonne "NEXT", j'avais compris qu'on y mettait que des projets. Du coup, je trouvais nécessaire d'avoir le distingo entre tâches prêtes à être lancées et tâches en cours grâce à un découpage en 2 de la colonne "NOW".

Hello, l'année dernière j'avais été intégré a une "équipe agile" a 100% en plus de ma vrai équipe. Ca a été un fiasco total et on m'a vite sorti du coté Agile. Mais ils ont décidé de passer notre équipe en agile maintenant.
 
Je ne vois même pas comment c'est possible. Un bon 50% de notre boulot c'est du support qui peut surgir a tout instant et souvent avec des arrêts de productions a gérer donc du boulot de pompier. L'autre 50% c'est faire des upgrades de système en appliquant une méthodologie similaire au cycle en V stricte, on ne fait pas de dev a proprement parler, que du paramétrage.
 
On est 3 dans l'équipe, dont un nouveau qui a encore besoin de quelques mois de formation. Tous avec des profils différents et absolument pas interchangeables en dehors d'une couche basique. Nos clients? L'intégralité du site. Donc même si on ne nomme qu'une seule personne par département, on en a quasiment une 20ène. Et avec des dépendances avec quasiment tous en fonction des sujets. Sujets qui vont aller de quelques semaines a une année avec des taux de charge qui peuvent nous occuper de 10 a 80%.
 
On nous a collé un PO et Scrum a mis temps, partagés avec une autre équipe agile. On n'aura plus le droit de communiquer avec l'extérieur et tout sollicitation devra passer par eux au préalable. Sachant qu'on a des horaires qui peuvent être pas mal décalés (jusqu’à 2h de décalage).
 
Comment faire pour que ça puisse fonctionner? Parce que là je vois pas et je me fais juste traiter de réfractaire au changement et que l'approche Agile c'est justement d'essayer.

Un bel exemple où l'agilité est un but et pas un moyen, sans doute pour satisfaire quelques N+3 dont l'objectif est d'agiliser tout le département, peu importe la pertinence. En bonus vous recrutez 2 personnes qui vont pointer sur un budget supplémentaire et ne vont rien apporter à part vous freiner et dégrader la qualité de service.
Mais vous serez agiles et ça c'est le plus important

 
Après ça dépend de quelle agilité on parle.
 
L'agilité basée sur SCRUM + Weekly sprint et le fait de réussir à compléter toutes les tasks à la fin du sprint est visiblement une connerie dans leur cas vu qu'ils sont majoritairement dans une situation où tout peut arriver tout le temps et à tout moment.  
 
Par contre, dans leur cas spécifique, une agilité basée par exemple sur un pure kanban avec daily reviews pour prioriser les tasks à la volée sans sprint pourrait fonctionner (mais visiblement, c'est pas ce qu'ils ont l'air d'envisager)

Oui je suis d'accord un kanban serait plus adapté.
Mais la question de fond demeure : pourquoi avoir voulu changer le fonctionnement actuel ? Est-ce que ça ne fonctionnait pas ou bien est-ce juste une volonté de passer en agile pour répondre à des objectifs qui ne sont pas ceux de son équipe ? Très souvent malheureusement on est dans le deuxième cas.

 
Sinon, j'ai pas réagi là dessus, mais un product owner ne devrait pas être scrum master (enfin en théorie). Rien que ça... Ça me fait sérieusement douter du fait qu'ils comprennent ce qu'ils font.

Ca phrase pourrait être interprété comme on leur a mis 2 personnes : un PO et un scrum master. Du reste, le "s" à "partagés" semblerait aller dans ce sens d'interprétation

 
Bah c'est le à mis-temps qui m'a fait penser que c'était une seule personne, mais tu as peut-être bien raison.

Les 2 peuvent être à mi-temps

 
En relisant, je pense que cette ou ces personnes sont à temps plein, mais partagent leur temps entre deux équipes qui du coup, ont un de leurs mi-temps.

Le message de Vylkor prête à interprétation, voilà ce que c'est de ne pas se mettre d'accord sur la définition du Done d'un message prêt à être posté

Désolé pour l'update tardive, c'est bien deux personnes a mi-temps (je ne sais pas écrire désolé ), qui ont également les rôles pour une deuxième équipe agile.
 

 
Le pourquoi, c'est parce que le top management a décrété que l'agile c'était le futur et grâce a ça on apporterait plus de résultats plus vite. Ça a commencé avec les équipes projets et maintenant tout le monde doit y passer.
 
Coté équipe, nos problématiques sont surtout:
-Clients qui changent d'avis tout le temps.
-Clients difficiles a impliquer dans les changements car sans temps réellement alloué.
-Services supports défaillants, donc on récupérait beaucoup de tâches en dehors de notre scope mais qui devaient être traitées.
-Nombre de sujets croissant sans perspectives d'augmentation des ressources a court terme.
-Manque de ressource spécialisée dans un domaine pour régler ces problématiques.
-Aucun reporting vers le management, on est une sorte de boite noire. Mais faut dire personne ne nous pose de questions donc on fait nos trucs et ça marche au final. Depuis plus d'un ans on a plus de daily par exemple. Un sujet arrive "Qui le prend?" dans le bureau et c'est fini.
 
Mais nos clients étaient satisfaits au final, les deadlines respectés (même quand cela semblait impossible) et le service assuré. Donc personne ne nous posait trop de questions.
 
 
Et j'ai eu une discussion avec le management aujourd'hui. Plus ouvert que prévu, certains points semblaient avoir été oublié par rapport aux expériences passées. Il n'empêche que je ne suis pas totalement rassuré. Un système agile en itération de 15 jours semble être le standard qu'ils veulent appliquer, je vais devoir travailler a fond le sujet pour expliquer pourquoi ce modèle s'applique difficilement a notre poste et qu'un Agile Kanban semblerais plus adéquat. Le soucis aussi c'est qu'on vas devoir utiliser obligatoirement un Azure DevOps configuré pour faire de l'itération de 15 jours, sans possibilité de paramétrage a notre niveau. Donc ça risque d'être compliqué
 
J'ai tenté l'image "Comment voulez vous que j'aille installer des vis si vous me donnez un marteau et m'interdisez le reste?". A voir si ça fait du chemin...

 
Pour le genre de situation que tu décris, c'est le principe même des itérations qui ne fonctionne pas.
 
Par contre, oui, un Kanban agile (appelé pure Kanban, voir mon deuxième post sur ce topic) est bien plus adapté à leurs besoins et sera sans doute bien plus efficace. Il permet aussi de mettre des deadlines pour les tâches qui en ont besoin sans paralyser le système. Mais bon, ils auront peut-être (comme nous) besoin de temps et de faire des erreurs pour changer leur système.
 
Le drame des méthodes agiles, c'est que bien souvent, les gens plongent la tête la première dedans en tentant d'appliquer SCRUM sans considérer les alternatives, sans savoir si c'est adapté à leur cas et sans aucun recul. Et le pire, c'est qu'ensuite, une fois qu'ils ont embauché leur SCRUM master, il est évident que ce dernier ne va pas remettre en cause son propre rôle et usera de tous les moyens dont il dispose pour s'accrocher. C'est aussi cela qui fait qu'on peut rapidement se retrouver dans des situations ultra toxiques.
 
Et pas mal de consultants ne valent pas forcément mieux et vont tenter de vendre SCRUM à tous prix...
 
Bref, alors que l'agilité est VRAIMENT une bonne chose si bien adapté et bien appliqué et que ça peut booster la productivité, souvent ça va produire l'effet inverse.
 
Je finirai en disant que de toutes manières, l'erreur, c'est déjà d'imposer un système sans obtenir l'approbation de ceux et celles qui vont le subir.