100 % en phase, j’ai le même avis pour les specs, à peine éditées, elles sont obsolète 
Encore une fois tout ça dépend du contexte.
jusque là, je ne suis jamais tombé sur un cas de contexte projet où l’agile ne fonctionne pas.
que ce soit un projet facile, complexe, tendu, avec grosse ou petite équipe, etc. à chaque fois, ça a marché.
Il y a trois situations types où l’Agile n’a pas de sens :
-
Catastrophe : Qu’est-ce qu’on fait encore en mêlée quotidienne autour de ce tableau de Post-It en train de prendre feu ? Les situation chaotiques sont transitoires. On peut parler de projet chaotique pour parler d’un projet qui cherche à profiter du fait d’être au pied du mur pour innover. @const a évoqué plusieurs fois cette situation de War Room où tout avance plus vite.
-
R&D, Innovation de rupture : Je discutais récemment avec qqn du monde de la recherche qui me disais que l’Agile s’y prêtait assez mal. On s’était accordé sur le fait que certains aspects s’y prêtent, comme la rédaction d’un article, l’organisation des expériences scientifiques, mais pas l’exploration pure. En effet, on ne peut pas écrire de User Story ou fixer un cap. Il faut explorer plusieurs pistes en parallèle et provoquer la sérendipité. Énormément de découvertes se font par hasard.
-
On sait quoi faire : Si tu commandes un produit et que le vendeur n’est pas capable de te donner une date de livraison à peu près fiable, c’est bizarre. Si en plus, le vendeur perd de vue les étapes par lesquelles il faut passer (appro, colisage, envoi, facturation, SAV), il ne fera pas long feu.
Au cours de la vie d’un projet, toutes ces situations peuvent se produire.
pour avoir déjà vécu plusieurs fois ton premier et troisième point, je t’assure que l’agile est la réponse évidente
pour la R&D, l’innovation, je sais pas, pour le coup, je ne vois pas le frein mais je n’ai pas de REX personnel
1 « J'aime »
Alors, clairement oui, si le but c’est d’installer du wordpress à la chaine, faire de l’agile n’a pas de sens.
Mais si on parle de génie logiciel, on fait forcément un nouveau produit original. Du coup, on peut penser savoir quoi faire, mais l’expérience montre que dans l’écrasante majorité des cas ça ne fonctionne pas. D’abord parce que les hypothèses de départ sont souvent mauvaises, et d’autre part parce que celles qui sont valides au départ sont souvent invalidées avant la fin de la fabrication du produit.
Un peu comme si tu devais fabriquer un pont entre 2 montagnes qui bougent de plusieurs mètres par semaine dans des directions aléatoires. Dans ce cas, il faut revenir au besoin de mobilité et se demander si un pont est bien la bonne solution (spoiler: probablement pas). Malheureusement le marché du logiciel sur mesure est saturé de clients qui veulent des ponts entre 2 montagnes pas immobiles …
1 « J'aime »
Peux-tu étayer tes assurances stp ? Désolé de ne pas te croire sur parole.
Dans une catastrophe comme une incendie ou une intrusion, tu as déjà appliqué une méthode agile ?
1 « J'aime »
Je pense qu’il est utile ici de regarder un produit sous le prisme du cycle de diffusion des innovations d’Everett Rogers. A la genèse du produit, on a probablement moins de connaissances. Une fois que le produit devient bien établi et bien cerné, l’incertitude sur les sujets se réduit. Il y a de plus en plus de choses qui relèvent de l’expertise. Pour éviter que le produit meurt, il faut régulièrement insuffler une nouvelle vague d’innovation. https://youtu.be/JZ1J3RkvGOc
Je suis d’accord avec le constat que beaucoup de clients sur-estiment leur connaissance du besoin et sous-estiment l’incertitude. Mais que la majorité des projets soit de cette nature, c’est un problème. Je pense que beaucoup trop de projets n’ont pas les bonnes compétences autour de la table, ce qui oblige à aborder un problème compliqué comme un problème complexe. Je pense que trop souvent on accepte de répondre à des besoins lunaires, au lieu de dire qu’on n’est pas en mesure de répondre à tout ce qui est demandé, mais on se propose d’explorer une petite partie. Et parfois on en rajoute à vouloir aborder un métier méconnu avec une architecture méconnue. Par exemple, pourquoi s’obstiner à créer une application sous forme de microservices déployés dans un cluster Kubernetes avec une BDD NoSQL alors qu’on a trop peu d’expérience dans toutes ces choses ? Je recommande de répondre à un besoin nouveau par une architecture banale (boring architecture).
Enfin, si on explorait un peu plus de pistes en parallèle en amont, chose que l’Agile sait faire difficilement, on allégerait l’incertitude derrière.
2 « J'aime »
tu peux faire une métaphore réaliste dans un monde IT ?
je ne vois pas ce que veut dire Incendie ou Intrusion dans une Squad
je vois bien des cas d’incident majeur sur une app, ou les failles de sécurités mais on fait ça tous les jours, donc tu dois avoir d’autres idées réalistes
Deux exemples :
tes deux exemples, sauf erreur de ma part, sont des Incidents Majeurs de prod
pour la faille, j’en fais tous les jours l’agile ne pose aucun problème et permet de le traiter en fast line si la criticité le demande
je ne vois pas où CMMI te permet de traiter ça
concernant l’incendie OVH, pareil, ça fait partie des choses qu’on traite ou qu’on a à traiter, car on a été concerné. je ne vois pas non plus en quoi CMMI te permet de traiter ça
le fait d’être en DevOps, avec tout ce que demande le manifeste agile, a permis qu’on ait la possibilité de switcher sur un autre provider, autres serveurs, autre localisation sans aucun problème
je ne vois pas où CMMI te permet de traiter ça
Quand est-ce que j’ai parlé de CMMI ?
ok, les méthodes de cycle en V si c’est pas CMMI
Je n’ai pas préconisé le Cycle en V pour les catastrophes.
non mais tu as écrit que l’agile ne s’applique pas à ces contextes
je ne vois pas pourquoi, sur quoi tu te bases pour écrire ça
Il n’y a pas que deux choix : Agile ou Cycle en V.
Je me base sur plusieurs choses pour affirmer que l’Agile ne convient pas à certains contextes :
- L’absurdité des conséquences de la situation. Commencer par rédiger des récits utilisateurs quand il y a un désastre comme les deux que j’ai cité, c’est absurde. Il faut plutôt commencer par stopper l’hémorragie, pas par résoudre le problème de fond.
- Cynefin qui distingue différents types de contexte et les modes opératoires appropriés. Voir le guide pratique de l’UE sur la gestion de la complexité et du chaos co-écrit par Dave Snowden : Managing complexity (and chaos) in times of crisis - Publications Office of the EU
- Discussions avec différents professionnels.
Je plussoie, de mon expérience : dans certains contextes l’Agile ne convient pas.
L’itératif et l’incrémental ne fonctionne pas sur des problématiques de souffrance humaine, par ex la différence entre coaching et thérapie, où les méthodes de coaching sont justement plus du petit pas / Agile, ce qui convient à des systèmes qui fonctionnent déjà, alors que les thérapies brèves sont sur de la rupture totale / faire l’inverse, sur des systèmes qui souffrent.
Sur l’IT, lorsqu’on est sur de l’innovation de rupture, ou sur de l’urgence pure, prendre le temps de faire des hypothèses et de les tester est bien souvent inutile, alors qu’il faut juste agir plutôt que de sonder le problème (act / sense / respond).
Je ne suis pas un expert, c’est ma vision de la chose et mon expérience, je suis sur le chemin de l’étude de la complexité et je vois bien que l’Agile peut être utile sur des problèmes, et sur d’autres non.
Après on a sûrement pas tous et toutes la même définition d’Agile de toute manière
2 « J'aime »
la seule définition que j’accepte de l’Agile étant son manifeste
j’essaie de trouver une valeur ou un principe incompatible, j’essaie encore
mais ok, on peut ne pas être d’accord, pas de soucis
Si tu t’appuies sur le manifeste comme définition de l’Agile, il ne faut pas oublier la première phrase.
Nous sommes en train de découvrir comment mieux développer des logiciels
par la pratique et en aidant les autres à le faire.
priorisation par la valeur, c’est comme ça que tu stoppes l’hémorragie
où il est dit dans le manifeste qu’il faut rédiger des récits utilisateurs quand il y a un désastre ?
=> on parle des logiciels opérationnels plus qu’une documentation exhaustive
je ne connais pas Cynefin, il faut que je m’y penche sérieusement
l’oublier pousserait à écrire une US plutôt que de résoudre un incident ?
je ne vois pas où tu veux en venir