Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
Le problème c'est la panique.
Quand tout le monde est d'accord en début de projet, on va appliquer une méthode agile (Scrum, X our Y), tout est beau, chacun applique cela comme il faut.
Puis dès que les problèmes se pointent, ce qui fait l'intérêt de l'agilité disparaît. On reprend les mauvaises habitudes, on promet au client une deadline à l'ancienne, on bourre les sprints, on multiplie les points quotidiens, on ne respecte plus l'organisation en place, bref c'est la merde.
Plutôt que de jouer à Jean-Pierre Coffe et de crier : "c'est de la m#$§e;", je m'intéresserai aux 15% de projets qui réussissent pour comprendre ce qu'ils ont en commun et essayer d'en tirer des conclusions intéressantes.
Quel est votre avis sur le sujet ?
Que la "méthode SCRUM" n'est que ça, une méthode parmi tans d'autres et que ce n'est surement pas la "faute" à une méthode si un projet échoue, mais uniquement à ceux qui ont choisie de l'utilisé sur un projet sur laquelle elle n'était pas adapté.
Les principes même de l' "Agilité" consiste avant même le choix de la méthode de dev, à bien choisir nos outils en fonction du contexte.
Inutile de vouloir imposé une méthode à tous les projets, je peut vous garantir que ça ne fonctionnera pas.
Êtes-vous ou pas du même avis que Gene Bond ? Que pensez-vous de ses arguments ?
Plutôt oui et je pense que le monsieur à bien comprit que le problème ne venait pas de la méthode, mais de ça mise en oeuvre à géométrie variable avec des besoins maladif de copie de l'existant (au niveau des projets).
Chaque projet existe dans un contexte unique, partant de là il fait très bien le constat que le cœur de l' "Agilité" réside dans l'adaptation et pas dans le copier collée systématiques.
Malheureusement c'est bien le copier coller qui à cours dans la plupart des projets, après tous si une méthode a bien fonctionné précédemment, pourquoi ne fonctionnerait elle plus ? (Réponse : Le contexte)
Quelle méthode Agile utilisez-vous et quelles sont les difficultés que vous rencontrez souvent ?
Aucune, personnellement, je pense que l' "Agilité" rime avec adaptabilité en conséquence de quoi, je m'adapte au projet ce qui revient à ne pas avoir de méthode puisque non reproductible pour un autre cas.
Après, il ne faut pas confondre méthode et bonne pratique.
Ce n'est pas parce qu'on utilise pas de "méthode Agile" documenté que l'on ne vas pas mettre en place test, CI et CD dans sont projet.
merci je suis plutot d'accord avec ça ! les cllients ont ete bien satisfaits du boulot fourni par les equipes scrum au sein desquelles j'ai bossé les 4 dernieres annees, pourtant chaque fois des défisEnvoyé par palnap
l'article "La méthode Agile Scrum ne marche pas, elle fonctionne dans seulement 15 % des cas, rencontrant donc un échec dans 85 % des cas", que je trouve provocateur, m'invite a chercher des reponses à des interrogations comme : seulement 15% dechefs de projetsscrum masters et PO competents ? seulement 15% d'entreprises dont la culture et les pratiques permettent d'accueillir et utiliser à profit les atouts de l'agilité ? seulement 15% de clients ont des attentes réalistes au regard du prix payé ? etc.
J'estime à 83,48% les chances de se planter de plein fouet dans les biais cognitif quand on fait des analyses qui ne se basent sur aucune données objectives et vérifiables.
Pour ma part, j'ai toujours considéré Scrum comme une escroquerie intellectuelle.
Si me souvenirs sont bons, une des premiers pré-requis qui est annoncé pour un projet organisé en scrum, c'est une équipe autonome et compétente.
Hé bien je vais vous dévoiler un secret : réussir un projet avec une bonne équipe n'est pas une gageure incroyable (toutes choses étant égales par ailleurs, on est bien d'accord que si on vous demande d'envoyer une fusée sur la lune en 3 mois, et qu'au bout que 2 mois on vous dis, non finalement on veut explorer les fonds sous marins, une équipe de cador ne vous sauvera pas).
Mais sur beaucoup de projet vous avez surtout des développeurs juniors, conséquence logique du manque de reconnaissance du métier de développeur en France, de la pression sur les prix exercée par les clients, et de la malhonnêteté de nombreuses ssii. Et quand vous laissez des personnes inexpérimentées en roue libre qui s'auto-organisent, le risque de plantage magistral n'est pas loin.
Nul besoin de tout ce fatras pour mettre en oeuvre les bonnes pratiques :
- cycle itératifs courts pour éviter l'effet tunnel
- proximité du client avec les équipes de dev. pour des ajustements rapides en amont ou en aval du dev.
- implication du client dans les phases de conception / recette
- promouvoir la communication et le travail collaboratif
On n'a pas attendu scrum, ni même le manifeste agile, pour comprendre et appliquer ça.
Il y a 30 ans on faisait déjà du RAD, avec d'excellents résultats par ailleurs. J'ai géré au moins une dizaine de projets de taille importante (disons au moins 1000 j/h), avec des cycles itératifs courts, y compris au forfait, et on a (presque) toujours délivré dans les délais, le respect du planning et budget, à la satisfaction du client, et en ayant fait progresser les juniors au sein d'équipe mixtes. Sans faire d'agile au sens strict du terme.
De ce que j'en vois depuis quelques années, ça occasionne surtout pas mal de dégâts et ça permet à toutes sortes de théoriciens fumeux de facturer à prix d'or des prestations inutiles voire contre-productives. En fait quand l'agile ne fonctionne pas, on fait appel à des gens dont le métier est justement de vendre de l'agilité : ils ne vont certes pas vous dire que la méthode retenue n'est pas adaptée à votre organisation ou à votre contexte projet. Non. Ils vont vous expliquer que vous faîtes mal, pas assez, qu'il faut faire évoluer l'organisation etc. Mais jamais il ne concluront que la méthode agile que vous appliquez sur votre projet n'est pas adaptée (à la maturité de votre équipe, à la culture de l'entreprise ...). En fait c'est le principe même de l'escroquerie, comme vous avez claqué plein de fric en consulting de coach agile et autres scrum master, vous voulez un retour sur investissement et vous remettez au pot, encore et encore : encore un petit effort et ça va fonctionner... jusqu'au moment où vous retrouvez vos esprits, virez tous les consultants inutiles, renforcez l'équipe par des personnels expérimenté et revoyez votre processus projet.
L'esprit même de l'agile a été perverti par les SSII qui surfant sur l'effet de mode en collent partout, quel que soit la nature du projet et de l'entreprise, et facturent à prix d'or des glandus qui n'ont jamais piloté un projet, subitement transformés en experts de la gestion de projet après une formation de 3 jours aboutissant à une magnifique certification scrum master. Mais les SSII ne sont pas seules en cause, il y a probablement un problème culturel bien français, avec la séparation traditionnelle entre maitrise d'ouvrage (le seigneur du chateau qui manifeste son désir) et maîtrise d'oeuvre (les gueux et artisans qualifiés qui se démènent pour satisfaire le seigneur), qui perdure avec des notions bizarres comme les proxy-product-owner et autres variations.
Pour finir sur une note positive, il ne faut pas jeter le bébé avec l'eau du bain. Scrum fonctionne bien sur certaines typologie de projet. Et j'ai connaissance dans mon entourage de projets ambitieux réussis en contexte Scrum (mais malheureusement de bien plus d'échec sanglants, m'enfin l'échec des projets n'est pas exceptionnel dans ce métier, avec ou sans scrum).
Mais vouloir faire rentrer du scrum au chausse pied dans une organisation qui ne s'y prête pas, des représentants du métier qui ne jouent pas le jeu, dans un projet piloté par les coûts (ie : un forfait), avec une équipe de dev inexpérimentée sans encadrement technique adapté, c'est aller au casse pipe.
bonjour damthemad, je suis quasi entierement d'accord avec ton analyse et en particulier ta conclusion que je trouve pertinente (je n'ai que 20 ans de métier mais ça matche bien avec mon expérience)
du coup j'adhere integralement a ton post hormis une seule chose que je ne comprends pas : ta premiere phrase (tu dis "Pour ma part, j'ai toujours considéré Scrum comme une escroquerie intellectuelle.")
Scrum n'est pas un escroc, c'est juste un outil. L'agilité c'est pareil, c'est un ensemble de valeurs. Mieux : les valeurs auxquelles tu déclares être attaché (et moi aussi) appartiennent à celles que l'Agilité défend.
Donc pour moi je crois qu'il est utile de bien faire la distinction entre l'Agilité et Scrum d'un coté, des "outils" qu'on peut utiliser si besoin, et d'un autre coté les personnes malhonnêtes ou simplement incompétentes à leurs postes (les escrocs des SSII ou les mauvais clients qui ne veulent pas comprendre les nécessités du métier, etc.) qui utilisent ou détournent les concepts à des fins peu reluisantes...
Ya une grosse erreur dans tout ça... c'est que Scrum n'est pas une méthode.
Si c'est pris comme une méthode, c'est évident que ça sera un échec dans la majorité des cas.
Scrum est un framework / un cadre de travail, la différence est de taille par rapport à une méthode.
Une méthode est une approche systématique pour atteindre un résultat ou un objectif spécifique. On est sur une approche scientifique, alors qu’en agilité et en Scrum on est sur approche empirique.
Et justement vu que ce n'est pas une méthode, mais un cadre de travail, c'est universel.
Il y a un cadre à respecter, après l'entreprise, l'organisation s'adapte dans ce cadre.
Qu'est ce qui ne fonctionne pas ? Sur quelle base est basée cette affirmation ?
La démarche Scrum, permet de délivrer plus de valeurs aux usagers finaux, plus rapidement. Ca n'assure pas de délivrer à moindre coût, ou un périmètre plus exhaustif etc ...
J'ai vu de nombreux projets déclarer être une réussite, alors que le produit délivré était peu utilisé par les usagers, ou ne leur apportait pas satisfaction.
Donc qu'est ce qui définit la réussite d'un développement de produit numérique pour vous?
Quelques constats et réflexions, pour compléter ce qui a été dit :
Selon moi, une méthode agile comme Scrum n’a pas pour objectif d’améliorer la productivité d’une équipe. Le principal intérêt est de fournir un outil d’organisation, de pilotage et de priorisation qui permet d’éviter l’effet tunnel et donc les dérapages et les mauvaises surprises dans les dernières phases du projet. Elle ne constitue pas une méthode miracle pour réussir les projets.
Scrum (ou une autre méthode agile) ne permet pas réduire les coûts d’un projet, au contraire. Le travail en itérations courtes avec des objectifs de court terme crée de la dette technique, ce qui on peut nécessiter un refactoring de plus en plus important qui s’ajoute à la charge du projet.
Scrum ne permet pas d’être plus rapide. Avec le système d’itérations courtes (sprints), on a des livraisons plus fréquentes, ce qui permet de prendre en compte les retours et changements d’avis. Mais ce fonctionnement allonge les délais au lieu de les réduire.
Bien souvent un projet est fortement contraint au niveau des dates, avec des délais difficilement tenables. Du coup, les sprint sont « optimisés » de manière irréaliste dès le début pour tenir une date de livraison finale. Il n’y a pas de place pour la prise en compte des retours du métier, les changements d’avis, le refactoring, les optimisations… On perd donc l’intérêt de l’agile. De plus si on travaille avec une documentation inexistante ou très réduite, on multiple les incompréhensions, les interprétations erronées, et le livrable a toutes les chances de ne pas correspondre au besoin, d’où insatisfaction du métier, décalage et surcoûts.
Ensuite l’agile ne fonctionne que si tous les intervenants du projet (chef de projet, interlocuteur métier, fonctionnels/MOA/business analyst, développeurs, personnes en charge de l’infrastructure, du déploiement et de l’Exploitation…) travaillent réellement ensemble, idéalement dans un même bureau, pour faciliter les échanges. C'est rarement le cas.
Il y a une idée fausse (qui ne fait d'ailleurs pas partie des 12 principes du manifeste agile) mais très répandue: dans un projet en mode agile il n’y a pas de spécifications précises. Celles-ci seraient remplacées par les récits utilisateurs (user stories). Or la user story n’est nullement un moyen de spécifier au développeur la fonctionnalité attendue. C’est avant tout un outil d’organisation et de gestion du projet*: le backlog produit est un outil de priorisation des fonctionnalités attendues. Si on travaille sans spécifications et sans documentation précise, on va perdre du temps en multipliant les échanges, et aboutir à des incompréhensions et des erreurs de conception, surtout si on travaille avec un prestataire.
L'agile repose sur la capacité à définir les fonctionnalités du produit sous forme de récits utilisateurs précis, indépendants, cohérents, inter-changeables et de petite taille (correspondant à un développement pouvant être réalisé au cours d’un sprint). Or cela n’a rien d’évident.
Les méthodes agiles fonctionnent très mal dans une organisation rigide (hiérarchique). Pour pouvoir fonctionner, elles doivent s'appuyer sur une organisation coopérative.
Autre problème : le travail en agile avec un prestataire. Généralement la contractualisation n’est pas agile. Le prestatatire vend une organisation agile (projet est organisé en sprints, daily meeting, scrum master…) mais attend des spécifications détaillées pour démarrer les développements et refuse de prendre en compte les modifications.
Enfin l’agile est lié à l’idée d’apprentissage et d’amélioration continue. Ce sont des aspects qui sont généralement oubliés dans les projets. En cas d’échec on est plutôt dans la recherche des coupables.
Bonjour,
Un billet de blog éloquent par rapport au thème du forum La méthode Agile Scrum ne marche pas, elle fonctionne dans seulement 15 % des cas, selon Gene Bond, posté initialement et récemment par Derek Corgan ici dans la rubrique Emploi ci-après :
Développeur, en entreprise, vous aussi vous êtes au bout du rouleau ?
«
Avant-propos
Le texte qui suit est la version française d’un billet de blog à thèse publié en 2015 par le programmeur américain Michael O’Church.
Je l’ai contacté pour le traduire et faire connaître ses arguments en France, où les méthodes Agile, et plus particulièrement Scrum, n’ont de cesse d’envahir les entreprises privées.
L’agilité est sans nul doute une bonne chose, et l’Agile Manifesto n’est pas forcément déraisonnable. Si on la compare à l’imposture logique qu’est Waterfall, la méthode Agile s’avère notablement supérieure. Pourtant, Agile telle qu’elle est pratiquée dans les faits et dans la majorité des cas est profondément nocive ; et dans un premier temps, il ne me semble pas qu’une dichotomie Agile/Waterfall ait jamais été nécessaire à quelque projet que ce soit.
Il existe une variante d’Agile, nommée Scrum, que j’ai vu détruire des entreprises, littéralement. Par « détruire », je ne veux pas dire «par la suite, la culture n’était plus si bonne que ça» ; je veux dire que l’action s’est effondrée de près de 90%, en moins de deux ans.
»
Source: Pourquoi Agile et Scrum sont catastrophiques | by binnie | Medium
- Qu’est-ce qu’Agile ?
- Transparence ultra-violente
- Problèmes spécifiques à “Agile” et Scrum
1. L’ingénierie business-driven (ou dirigée par les affaires)
2. Juniorité terminale
3. C’est bêtement, dramatiquement “court terme”
4. Agile n’a aucun respect pour la cohérence professionnelle
5. Le but est d’identifier les mauvais éléments, mais le taux de faux positifs est bien trop élevé
6. Un changement de perception malheureux
7. C’est vendu de façon malhonnête- Ce pourquoi Scrum fonctionne
- Deux problèmes
- Perspectives d’avenir
[Edit au 7 mai 2021]
Grâce à vous tous, je m'aperçois que nos chroniqueur.e.s ont passé entre-temps le sujet en une sur https://www.developpez.com/
Développeur en entreprise, vous aussi vous êtes au bout du rouleau ? méthodes agiles mal appliquées ? management irresponsable ? Scrum une vaste blague ? Développeur en entreprise pour beaucoup serait très loin d'être un long fleuve tranquille, au point que certains ne recommandent pas cette profession. Projets mal définis qui finissent en usines à gaz, organisation déficiente, managers incompétents qui ne font que brasser du vent, réunions interminables et inutiles, méthodes mal appliquées, voire contre-productives, quelles sont les horreurs que doivent subir au quotidien les développeurs ?
43 commentaires
« Developpez.com est un groupe international de bénévoles dont la motivation est l'entraide au sens large » (incl. forums developpez.net)
Club des professionnels en informatique
L'actualité va à la vitesse d'un cheval au galop, vous pouvez (re)trouvez cette information qui nous concerne tous et la commenter en cliquant sur «nnn commentaires», en une grâce à nos rédacteurs - rédactrices (désolé je me perds parfois avec l'écriture inclusive) sur les liens spécialisés ci-après (à la date du post):
Développeur en entreprise, vous aussi vous êtes au bout du rouleau ? méthodes agiles mal appliquées ? management irresponsable ? Scrum une vaste blague ? Développeur en entreprise pour beaucoup serait très loin d'être un long fleuve tranquille, au point que certains ne recommandent pas cette profession. Projets mal définis qui finissent en usines à gaz, organisation déficiente, managers incompétents qui ne font que brasser du vent, réunions interminables et inutiles, méthodes mal appliquées voir contre productives, quelles sont les horreurs que doivent subir au quotidien les développeurs ?
100 commentaires
In fine
Accueil => Forum => Emploi et Etudes en Informatique => Emploi
« Developpez.com est un groupe international de bénévoles dont la motivation est l'entraide au sens large » (incl. forums developpez.net)
Club des professionnels en informatique
Pipotage
La méthode Scrum, comme beaucoup de méthodes dites "agiles" n'est que du pipotage et du marketing pour les béotiens qui ont besoin d'être strictement encadrés sinon ils ne font que des bêtises.
Il faut lire ou relire les standards de développement de l'ISO/IEC/IEEE : https://www.nbn.be/shop/fr/norme/nbn...207-2021_1833/
La méthode agile Scrum serait un cancer, selon un enseignant en intelligence artificielle
La méthode agile Scrum serait un cancer, selon un enseignant en intelligence artificielle.
Scrum est un cancer. Santiago, un enseignant en intelligence artificielle, écrit des logiciels depuis 25 ans, et selon lui, rien ne rend une équipe logicielle inutile comme le fait Scrum. Voici ce qu'il rapporte :
Quelques anecdotes :
- Ils ont essayé de me convaincre que le poker est un outil de planification, pas un jeu ;
- Si vous voulez être plus efficace, vous devez ajouter des processus, et non les supprimer. Ils nous ont fait assister aux "cérémonies", un nom fantaisiste pour un tas de réunions : stand-ups, groomings, planification, rétrospectives, et Scrum de Scrums. Nous avons passé plus de temps à parler qu'à agir ;
- Les ordinateurs portables sont interdits en réunion. Nous devions rester debout. Nous faisions circuler un ballon pour que tout le monde reste attentif ;
- Nous avons passé plus de temps à estimer les story points qu'à écrire des logiciels. Les story points mesurent la complexité, pas le temps, mais nous devions décider combien de story points correspondaient à un sprint ;
- J'ai dû utiliser la taille des t-shirts pour estimer les logiciels ;
- Nous avons mesuré le coût de livraison d'un story point, puis nous avons rédigé des contrats dans lesquels les clients payaient pour un lot de "500 story points" ;
- La direction a perdu la tête lorsqu'elle a découvert que les 500 story points d'un projet n'étaient pas les mêmes que les 500 story points d'un autre projet. Nous avons tenu de nombreuses réunions pour régler ce problème ;
- Imaginez que vous ayez un manager, un scrum master, un product owner et un tech lead. Vous deviez répondre à chacun d'entre eux et à aucun simultanément ;
- Nous avons payé des personnes qui nous ont dit si nous "brûlions des points" assez rapidement. Les story points n'étaient-ils pas une question de complexité plutôt que de temps ? Peu importe.
Je crois en la méthode Agile, mais ce n'est pas le cas.
Nous avons fait appel à des formateurs Scrum professionnels. Nous avons payé des membres de notre équipe pour qu'ils soient certifiés. Nous avons essayé Scrum de cette façon et de cette autre façon. Nous avons passé des années à le faire.
Le résultat était toujours le même : cela ne fonctionnait pas.
Scrum est un cancer qui va dévorer votre équipe de développement. Scrum n'est pas fait pour les développeurs. C'est un outil de plus pour que les managers aient l'impression de contrôler la situation.
Mais les meilleurs de Scrum sont ceux qui vous regardent dans les yeux et vous disent : "Si cela ne fonctionne pas pour vous, c'est que vous vous y prenez mal. Scrum, c'est tout ce qui fonctionne pour votre équipe."
Bien sûr que c'est le cas.
Source : Santiago
Et vous ?
Voir aussi :
Publication de communiqués de presse en informatique. Contribuez au club : corrections, suggestions, critiques, ... Contactez le service news et Rédigez des actualités
Le Guide Scrum ne mentionne pas le planning poker.
Il y a pas mal de réunions de la fin d'un sprint au début du suivant. Le reste du temps, il y a une réunion de 15 minutes par jour.
Le Guide Scrum ne dit pas que la réunion soit se faire debout. Beaucoup de personnes appellent stand-up meeting le Daily Scrum, mais cela ne vient pas du Guide Scrum. Le ballon non plus.
Le Guide Scrum ne dit pas d'utiliser des story points. Mais, en effet, le guide Scrum incite à faire pas mal de planification lors du Sprint planning, ce qui peut être du temps perdu. Extrait du Guide Scrum :
« For each selected Product Backlog item, the Developers plan the work necessary to create an Increment that meets the Definition of Done. This is often done by decomposing Product Backlog items into smaller work items of one day or less. »
Le Guide Scrum utilise les mots size et sizing pour les estimations, mais ne dit pas si les estimations sont en heures, en jours, en tailles de T-shirt, etc.
LOL.
Des gens qui n'ont pas de compétences en gestion de projet de développement de logiciels se retrouvent à des postes de gestion de projet de développement de logiciels. Ce n'est pas nouveau. Mais, là, aucune méthode ne peut marcher.
En Scrum, dans une Scrum Team, il n'y a pas de hiérarchie, donc pas de tech lead. Extrait du Guide Scrum :
« Within a Scrum Team, there are no sub-teams or hierarchies. »
Le Guide Scrum ne dit pas d'utiliser des story points.
Vouloir mettre du Scrum partout serait une hérésie. Mais, de toute façon, personne ne fait du Scrum, même si beaucoup de gestionnaires prétendent en faire.
Rappel préliminaire : je ne suis pas développeur et ne travaille pas dans une entreprise ou le développement logiciel est le coeur de métier.
Ca fait 6 mois/1 an qu'on me vend pas mal la "méthode agile", ce qui me laissais quelque peu dubitatif parce qu'on nous l'avais présentée peu de temps après le covid et le présentateur se présentait plus comme un gourou qui veut tout agiliser sans écouter nos demandes et notre contexte. Mais il s'avère que certaines équipes opérationnelles s'y sont mis et que ça semble bien fonctionner.
Ce que je trouve rassurrant chez nous est que les équipes qui encadrent les lancements de projets agiles préfèrent faire peu de projet concluants que beaucoup de projet avec une "couche de peinture" agile. Certains projets agiles ont été lancés et la méthode a été abandonnée parce que inefficace (je ne sais pas pourquoi). Bref tout ça me rend oprimiste sur l'arrivée de l'agile chez nous.
Il n'en reste pas moins que ça semble très dépendant des encadrants et/ou des formateurs. Parce que ça semble bien prendre mais la première présentation qu'on avait eu avait convaincu tout le monde de fuir la méthode comme la peste.
Pour ma part, j'essaie d'adapter la méthode en fonction du contexte (entreprise, collaborateurs, nature du projet). Actuellement dans mon entreprise on va faire en fonction de la situation.
Par exemple, Dans le cas d'une période où l'essentiel des tickets va être des bugs isolés, on va travailler en Kanban. Pas de planification, juste une priorisation des tickets faite par les PO et les devs piochent dedans. Daily meetings classiques et on livre régulièrement des releases. Ça s'arrête là
Dans un cas où il y a plutôt des nouveaux développements, on fonctionne sur un sprint backlog préparé à l'avance par les PM et PO avec une priorisation au sein de celui-ci. Lors du premier jour du sprint, on va faire une estimation (en temps) et déjà une affectation à un développeur qui aura une capacité en temps déterminé (en fonction de son contrat, de ses congés sur la periode et de ses potentielles autres activités, typiquement un dev au 35h sans rien de particulier, ça va être 4h30 ou 5h par jour environ).
Quand plus aucun développeur n'a de capacité, le sprint est considéré comme rempli et toutes les autres tâches non affectées sont reléguées dans le backlog.
Chaque jour, on fait le daily meeting assez classiquement, ce qui permet de réajuster, de communiquer sur les difficultés ou au contraire d'aider les autres si l'un est plus en peine et à la fin du sprint, démonstration faite par un membre de l'équipe à l'équipe (devs, testeurs, po, PM, direction et toutes personnes intéressées) et échange rétrospectif après. Je trouve que dans mon contexte, cette méthode (pas forcément scrum) fonctionne assez bien.
J'ai pas de mal avec les méthodes mais j'ai beaucoup de mal avec les gens qui cherchent à les refourguer comme des charlatans revendent leurs remèdes anti-calvitie.
Chaque problème son approche, et qu'on ne me fasse surtout pas croire cet immonde mensonge comme quoi la hiérarchie est mise de côté pour le Scrum. Sur le papier, peut-être. Concrètement, ca n'a jamais été le cas pour moi.
C'est vrai que ça fait beaucoup de types de réunions différentes.
C'est vrai que ça fait beaucoup de rôles.
L'agilité c'est hyper important, rien que pour un truc :
Méthode agile
Il y a forcément de l'agilité dans tous les projets, sinon ce serait n'importe quoi, il n'y aurait pas de dialogues entre le client et le développeur pendant tout le développement.En ingénierie logicielle, les pratiques agiles mettent en avant la collaboration entre des équipes auto-organisées et pluridisciplinaires et leurs clients. Elles s'appuient sur l'utilisation d'un cadre méthodologique léger mais suffisant centré sur l'humain et la communication. Elles préconisent une planification adaptative, un développement évolutif, une livraison précoce et une amélioration continue, et elles encouragent des réponses flexibles au changement.
Bon après la seule méthode qui n'est pas agile que je connaisse c'est le cycle en V, donc c'est pour ça que j'aime beaucoup l'agile.
D'après moi, avoir des réunions régulières avec le client, livrer des versions intermédiaires afin d'avoir des retours des clients, c'est de l'agilité et c'est top.
L'alternative à l'agilité ce serait de livrer le logiciel final, qui correspondrait exactement au cahier des charges, du coup le logiciel ne répondrait pas aux nouveaux besoins du client.
Parce qu'entre le moment où le cahier des charges a été établi et le moment de la livraison des choses ont changées, en plus le client avait mal exprimé ses besoins, il a demandé des fonctions dont il n'a pas besoin et il n'a pas demandé des fonctions dont il a besoin.
Avec l'agilité ont répond mieux aux besoins du client, parce qu'il est là pendant le développement.
Keith Flint 1969 - 2019
D'accord avec Bond
Je ne suis pas très bien placé pour discuter de la méthode agile Scrum car j'étais (je suis retraité) dans le domaine des systèmes complexes à logiciel prépondérant : avionique, spatial, systèmes militaires, énergie, centrales nucléaires, etc. où l'utilisation de ce genre de méthode est totalement exclue car inadéquate. Cependant j'ai eu de nombreuse occasions de discuter avec des développeurs de tous horizons en donnant des cours de langages de programmation (principalement C++ et Java mais aussi C, ADA, Lisp). L'immense majorité m'ont en effet affirmé que ce genre de méthode ne fonctionnait pas ou alors seulement pour de très petits projets (5 à 10 KLS) et un nombre restreint de développeurs.
Ces méthodes agiles (et pas seulement Scrum) sont totalement inapplicables pour des projets comme les robots martiens ou le transport d'énergie (RTE) par exemple.
Je pense qu'effectivement ces méthodes ne marchent pas dans au moins 85% des cas.
Pour tous ceux qui voudraient s'instruire avec de vraies méthodes de développement logiciel, je conseille la lecture de https://www.nasa.gov/sites/default/f...handbook_0.pdf (gratuit) et les normes IEEE (dont je suis membre) telles que https://innovate.ieee.org/ieee-softw...ing-standards/ (payant)
Retour sur scrum dans des structures de différentes tailles
Ce n'est pas la faute de scrum mais la responsabilité d'un management incompétent (pléonasme). Celui-ci imagine s'en servir pour reprendre la main avec l'aide de "consultants" qui tiennent plus du gourou que de l'expert. De l'agilité tout est tordu. Exemples classiques : rajouter des tâches au sprint en cours sans en retirer, isoler complètement les devs du client et les obliger à passer par des intermédiaires dépassés etc... 😅
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager