IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Le fondamentalisme sous agile nuit à la santé des entreprises
Selon le PDG d'un éditeur de logiciels adepte des méthodes agiles

Le , par Arsene Newman

48PARTAGES

3  0 
Mars Cyrillo est le PDG de CI&T, entreprise spécialisée dans le développement logiciel pour le compte de quelques grands noms du top 100 des entreprises. Aujourd’hui, il revient sur le développement agile, lequel a été adopté par son entreprise au cours de l’année 2005, après avoir utilisé pendant de longues années une autre approche de développement : RUP (Rational Unified Process).

L’un des premiers constats que fait Cyrillo est : « Nous admettons qu’au début, nous avons pris trop à la lettre le manifeste agile. Nous sommes alors devenus une sorte de fondamentaliste qui veut suivre et implémenter d’une manière stricte la philosophie en l’imposant à ses clients ».

Puis il évoque d’autres constats qui sont venus s’agglutiner au premier, suite au développement de l’entreprise : « Nous avons réalisé que nous nous dupions en pensant que nous pouvions suivre à la lettre le manifeste. Nous étions plus fragiles qu’agiles. » Et « le défi était de savoir comment rendre l'information et les processus de décision effectifs dans un environnement où il est tout simplement impossible d'avoir toutes les parties prenantes dans des réunions quotidiennes. »

Ainsi, pour le CEO de CI&T et sur la base des valeurs agiles qui mettent en avant chacun deux points de vue opposés (un point de vue à gauche et un second à droite), un suivi à la lettre de ces valeurs conduit à une sorte de fondamentalisme où les équipes de développement se concentrent uniquement sur le premier point de vue, délaissant le second. Or, les signataires du manifeste mettent l’accent sur le premier sans oublier l’importance du second.

Cette situation mène par exemple certains fondamentalistes à ne pas documenter leur programme, même si cela est nécessaire dans certaines situations (valeur n° 2) ou encore à ne pas fixer clairement de deadlines, évoquant pour cela la valeur n° 3, où il est question de collaboration avec le client, plus que de négociation contractuelle.

Cyrillo va plus loin encore dans ce constat. Il cite certaines déclarations régulièrement faites par ces fondamentalistes, dont les propos n’ont pas réellement leur place :
  • « Le développement logiciel est une forme d’art qui ne peut être mesurée. » ;
  • « La mesure de la productivité relève du passé et de la production de masse. Les artefacts utilisés par les chefs de projets ne servent qu’à stresser les développeurs. » ;
  • « La mesure de la productivité est un risque parce que les équipes trouveront toujours des solutions pour prouver artificiellement qu’elles sont productives. ».


A titre d’exemple, il explique ce qui suit : « Des métriques peuvent être utilisées pour mesurer les performances du processus utilisé, quant aux équipes de développement, elles doivent pouvoir calculer, mesurer et contrôler leur productivité. Une équipe qui n’en est pas capable ne peut pas comprendre ce qui l’affecte et par conséquent ne sera pas capable de s’améliorer en continue. »

Enfin, le CEO livre quelques détails sur les clés du succès sous agile, tout en garantissant la croissance de l’entreprise comme le suivi des principes lean qui offrent, selon lui, la meilleure approche philosophique, combinée à n’importe quelles méthodes agiles telles que SCRUM, Kanban.

Source : CI&T

Et vous ?

Qu’en pensez-vous ?
Pensez-vous être un fondamentaliste ou plutôt un adepte qui se donne une certaine flexibilité ? Pourquoi ?

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de pmithrandir
Expert éminent https://www.developpez.com
Le 07/04/2014 à 13:00
Pour ma part, je serais intéressé qu'il nous explique comment évaluer une équipe de dev.
Après plusieurs mois a réfléchir a la question, j'en suis arrivé a la conclusion que ce n'était pas faisable sur des critères mesurable et qu'il fallait faire confiance a l'humain, quitte a multiplier les évaluation pour limiter les effets de copinage.
8  1 
Avatar de gangsoleil
Modérateur https://www.developpez.com
Le 07/04/2014 à 10:46
Toute forme de fondamentalisme est a proscrire, bien evidemment.

Maintenant que cette lapalissade est rappelee, je trouve interessant de voir qu'on commence a trouver de plus en plus de "critiques" d'Agile, constructives ou non, en meme temps. Je pense que ca montre surtout qu'on est en train de passer de la phase "on est cool on fait de l'Agile/Scrum" a une phase de prise de recul, d'analyse, au cours de laquelle on se rend compte que oui, il y a des bonnes choses dedans, mais que non, tout n'est pas merveilleux, et il ne faut pas l'appliquer aveuglement.
6  0 
Avatar de Carhiboux
Expert éminent sénior https://www.developpez.com
Le 08/04/2014 à 11:21
Citation Envoyé par Luckyluke34 Voir le message
On parie que dans 5 ans il nous ressort le même article sur Lean ?
Probablement.

D'autant que pour avoir vu des collègues "subir" le lean, je peux vous dire que des fondamentalistes, il y en a de ce coté là aussi...

Bilan, six mois après 4 mois de lean (donc avec des demies journées entières avec un gugusse qui ne connait rien à votre taf au dessus de votre épaule qui note le moindre de vos fait et geste, super agréable...), je crois que quasi aucune "bonne pratique" du lean n'a été conservé. Et à chaque fois que le mot "lean" est prononcé dans ce service, l'ambiance se tend instantanément.

Bref, les méthodologies toutes faites, c'est de la poudre aux yeux. Chaque societé, chaque service, chaque client à ses spécificités. On ne peut pas appliquer une recette toute faite. Si c'était le cas, ça se saurait.
4  0 
Avatar de Luckyluke34
Membre émérite https://www.developpez.com
Le 08/04/2014 à 10:02
L'article repose sur le procédé assez connu de l'homme de paille : on établit une caricature d'agiliste "fondamentaliste" qu'on affuble de tous les maux, pour ne pas avoir à débattre de manière pragmatique sur une approche raisonnée. Les critiques restent assez vagues pour paraitre pleines de bon sens. Certaines seraient intéressantes si elles étaient argumentées, d'autres sont juste des vérités toutes faites. Ex : "Those are all myths that can be proven wrong." => OK, la démonstration SVP ?

La référence à l'article de Dave Thomas, un des signataires du manifeste agile, est utilisée à total contresens : D. Thomas ne critique pas les gens qui prennent trop le manifeste au pied de la lettre, mais ceux qui ne le prennent pas assez. Ceux qui ont marketé l'agilité au point de la vider de tout son sens.

En face de cela, l'auteur ne détaille aucune solution concrète, juste un mot : Lean, qui serait selon lui "la meilleure façon d'implémenter agile" et générateur "d'une qualité et d'une performance de rendement jamais vues avant".

On parie que dans 5 ans il nous ressort le même article sur Lean ?
3  0 
Avatar de Zirak
Inactif https://www.developpez.com
Le 08/04/2014 à 11:51
Citation Envoyé par Carhiboux Voir le message
Probablement.

D'autant que pour avoir vu des collègues "subir" le lean, je peux vous dire que des fondamentalistes, il y en a de ce coté là aussi...

Bilan, six mois après 4 mois de lean (donc avec des demies journées entières avec un gugusse qui ne connait rien à votre taf au dessus de votre épaule qui note le moindre de vos fait et geste, super agréable...), je crois que quasi aucune "bonne pratique" du lean n'a été conservé. Et à chaque fois que le mot "lean" est prononcé dans ce service, l'ambiance se tend instantanément.

Bref, les méthodologies toutes faites, c'est de la poudre aux yeux. Chaque societé, chaque service, chaque client à ses spécificités. On ne peut pas appliquer une recette toute faite. Si c'était le cas, ça se saurait.

Il faut aussi prendre en compte la façon dont a été appliqué le Lean.

Nous avons fait cette démarche dans notre société (mais je ne suis pas dans une SSII qui fournit du service), et nous avons augmenté notre productivité, amélioré un certain nombre de nos processus, etc etc

Mais pour cela, nous avons été somme encore suivi par une société spécialisé dans le domaine depuis plus d'un an, qui a étudié avec nous nos besoins, nos contraintes, et qui a pris le temps de comprendre nos processus dans les grandes lignes afin de pouvoir y appliquer les principes du Lean de la façon la plus adéquate, car comme tu le dis, chaque société à ses spécificités, peut-être n'êtes vous pas tombez sur les bons intervenants.

Et puis comme dans tous changements dans les habitudes, il y a aussi une bonne partie de réfractaires, qui peuvent aussi, freiner voir fausser la mise en application du principe du Lean, car cela demande une certaine remise en cause de soit-même et de notre façon de travailler.
3  0 
Avatar de souviron34
Expert éminent sénior https://www.developpez.com
Le 20/04/2014 à 18:13
Citation Envoyé par marsupial Voir le message
L'origine de la méthode Agile provient d'une double nécessité : produire mieux en évitant de mettre trop de pression aux développeurs dans le rythme infernal mis par l'obsolescence programmée. Obsolescence causée par la pression mise par le monde de la finance et du ROI suite à la "bulle internet".
Citation Envoyé par notia Voir le message
C'est faux. Ceci n'est qu'une conséquence de l'application de la méthode.

L'origine vient de 2 constats simples, constats que tu observeras dans la nature:
1) On résout plus facilement un problème en le découpant
2) On résout plus rapidement un problème en faisant appel à l'intelligence collective
Vous avez tous les 2 faux

L'origine vient tout simplement d'une longue et extensive pratique du cycle en V... sur de gros projets dans de grosses équipes.. ou à avoir eu à développer en parallèle à de grosses équipes en cycle en V.

J'ai déjà mis quelque part - mais je peux le remettre - des stats du milieu des années 90 où 91% des projets échouent, et sur les 9% qui marchent, ils n'ont que 47% des fonctionnalités demandées.. (voir ces stats ici)

C'est partant de ce constat, et en ayant l'habitude d'équipes où la production de documents internes, d'erreurs de traductions, et de réunions à plusieurs niveaux parce que le découpage était taylorien, entraînant des prises de décisions sur plusieurs mois, voire années, que les auteurs ont créé le Manifeste..

Et à peu près n’importe quelle personne sensée ayant travaillé sur ce genre de projet vous le dira..

Quant à l'article, son fond était prévisible dès le départ : je l'ai déjà dit X fois, l'agilité est un état d'esprit, et avec des bons, voire excellents, c'est encore mieux.. voire indispensable..

Donc, ce que je me suis tué à dire sur ces forums depuis maintenant 7 ans, c'est que les méthodologies agiles sont aussi nocives que n'importe quoi d'autre, si on en fait une religion.. Ce qu'on en a fait, par un élan marketing comparable à la mode du tout OO, du C++, ou du Cloud, ou n'importe quel buzz-word..

Mais bon, l'info aime le buzz, et les manuels pour savoir comment faire.....
3  0 
Avatar de _skip
Expert éminent https://www.developpez.com
Le 08/04/2014 à 13:20
Je suis d'accord pour dire que le dogmatisme vis à vis d'une méthodologie est néfaste, surtout qu'autour d'agile il y a aussi un petit versant commercial bien rôdé. Si vous me croyez pas, constatez par vous mêmes que presque tous les sites qui parlent d'agile proposent des services de consulting ou de coaching d'équipe.
Bref dans cet article, ça manque vraiment d'exemples concrets, on y apprend que ce qui marche pour les start-ups de 5 personnes marche pas forcément pour les équipes de 500, merci c'est vrai qu'on s'en douterait pas .

Le seul point où on a droit à un peu plus de précision c'est sur l'implication de l'utilisateur dans le processus. Là il nous dit que ce n'est pas évident d'avoir quelqu'un à disposition en permanence et qu'il y avait souvent des complications à cause du manque d'alignement des différents interlocuteurs (enfin comme je le comprends même si c'est pas dit aussi clairement). C'est aussi un problème connu, qui n'a jamais rencontré plusieurs personnes lors d'une séance, et vu à quel point ça se met à partir live lorsque chacun jette sur la table sa propre idée de ce que le produit devrait être? C'est même pas imputable à une méthodologie, c'est plutôt je sais pas moi... un fait anthropologique?
2  0 
Avatar de el_slapper
Expert éminent sénior https://www.developpez.com
Le 07/04/2014 à 12:49
C'est quand même paradoxal, cette mise en Abyme : le principe de base de l'agile, c'est de ne pas trop s'attacher aux principes, et on s'aperçoit que s'attacher trop à ce principe est nuisible.....
1  0 
Avatar de Carhiboux
Expert éminent sénior https://www.developpez.com
Le 08/04/2014 à 16:33
Citation Envoyé par Zirak Voir le message
Il faut aussi prendre en compte la façon dont a été appliqué le Lean.

Nous avons fait cette démarche dans notre société (mais je ne suis pas dans une SSII qui fournit du service), et nous avons augmenté notre productivité, amélioré un certain nombre de nos processus, etc etc
Peut être que vous aviez plus de "marge de progression" que le service donc je parle alors. C'est possible. Ou alors comme tu le dis, ils sont tombés sur des mauvais accompagnants. Très possible aussi.

Citation Envoyé par Zirak Voir le message
Mais pour cela, nous avons été somme encore suivi [...] Et puis comme dans tous changements dans les habitudes, il y a aussi une bonne partie de réfractaires, qui peuvent aussi, freiner voir fausser la mise en application du principe du Lean, car cela demande une certaine remise en cause de soit-même et de notre façon de travailler.
Oui, il y a clairement cela aussi.

Quand le lean vient "d'en haut" et que cela n'a comme objectif que d'augmenter les marges de la SS2I, c'est vrai que c'est pas trop fédérateur comme projet!
1  0 
Avatar de Zirak
Inactif https://www.developpez.com
Le 08/04/2014 à 16:51
Oui, après comme je le dis, ne faisant pas parti d'une SSII, la démarche n'était pas forcement la même également, mais le côté réfractaire car cela vient d'en-haut, c'est un des premiers trucs dont nous ont parlé les consultants qui nous suivaient, que le changement, cela faisait peur.

Je travaille dans une société qui fabrique quelque chose de concret, avec une chaine de montage plus ou moins automatisée, ce n'est pas que du "service", il y avait donc aussi plus de possibilité de voir réellement le gain.

Mais dans le principe du Lean, de développer son environement de travail de façon à tout avoir à portée de main sans bouger, de chercher les "gâchis" afin d'améliorer les processus, etc etc, Au final, ce n'est pas évident à faire car comme je le disais, chacun a ses petites habitudes, et n'a pas forcement envie de changer son train-train (ni se faire remarqué que c'est à son poste que le processus perds le plus de "gain" car pas optimisé etc etc...).

Sauf que, que cela soit pendant le processus (réflechir sur son poste, ses améliorations possibles, etc etc) ou après (travailler avec des processus plus optimisés, avoir de meilleurs communications au sein des différents services, etc etc), cela rend le travail plus agréable, surtout lors de ce moment où l'on se rend compte que : "tiens je viens de faire ça en 15mn, avant cela me prennait 1h30", on a moins l'impression de travailler dans le vide

Après d'un point de vue SSII, c'est vrai que le principe doit être un peu différent, nous le plus gros du changement s'étant plus déroulé au niveau production que bureaux, je ne vois pas trop comment cela s'adapte à une société de service.
1  0