Discussion :

[Michael Guilloux]

CollabNet : l'adoption des pratiques agiles augmente en entreprise
mais très peu d'organisations auraient un haut niveau de compétence

CollabNet, le fournisseur de solutions DevOps vient de publier le 12^e rapport annuel de State of Agile, qu'il considère comme la plus large enquête au monde sur l'Agile. L'entreprise a interrogé plus de 1400 professionnels du logiciel dans différents rôles et secteurs au cours des quatre derniers mois de l'année 2017.

L'enquête fournit des indicateurs qui montrent que l'adoption de l'Agile est en croissance parmi et au sein des organisations. En effet, « 25 % des personnes interrogées déclarent que toutes ou presque toutes leurs équipes sont agiles, alors que seulement 8 % l'avaient déclaré en 2016. » Notons encore que 27 % des répondants estiment que plus de la moitié de leurs équipes sont agiles, alors que seulement 2 % des répondants ont affirmé qu'aucune de leurs équipes n'est agile.

CollabNet fait remarquer que, par rapport à l'année dernière, il n'y a aucun changement dans le classement des raisons de l'adoption de l'Agile. Toutefois, le pourcentage de personnes citant la réduction des délais de livraison des logiciels comme raison pour adopter l'Agile a nettement augmenté en passant à 75 % contre 69 % l'année dernière. C'est également le cas pour les raisons suivantes : améliorer la prévisibilité des livraisons (46 % contre 30 % l'année dernière), améliorer l'alignement IT/Business (49 % contre 42 % l'année dernière), et réduire le coût du projet (24 % contre 18 % l'année dernière).

En termes de maturité dans l'utilisation des méthodologies agiles, il y a encore du chemin à parcourir dans de nombreuses organisations. La plupart des répondants (84 %) ont déclaré que leurs organisations n'ont pas encore entamé d'initiatives agiles ou utilisent des pratiques agiles, éventuellement de manière expérimentale, mais doivent encore arriver à maturité. Seulement 16 % des professionnels interrogés estiment que leurs entreprises ont maintenant un haut niveau de compétences avec les pratiques agiles, ou que l'Agile leur permet actuellement de mieux s'adapter aux conditions du marché. « La nouvelle encourageante est que 59 % reconnaissent qu'ils arrivent à maturité », peut-on lire dans le rapport. « Ce qui indique qu'ils n'ont pas l'intention de rester là où ils se trouvent », souligne CollabNet.

En ce qui concerne les avantages de l'adoption de l'Agile, le plus récurrent est que les pratiques agiles permettent de gérer les priorités changeantes de l'entreprise (71 %). Ensuite viennent la visibilité des projets (66 %), l'alignement Business/IT (65 %), la vitesse de livraison et les délais de mise sur le marché (62 %) et la productivité de l'équipe (61 %) en 5^e position.

Il existe toutefois des obstacles à l'adoption et la mise à l'échelle de l'Agile au sein des organisations. La 12^e édition du rapport de CollabNet révèle que les principaux freins à l'adoption des méthodologies agiles sont les cultures organisationnelles en contradiction avec les valeurs agiles (53 %), la résistance générale au changement (46 %) et le soutien inadéquat de la direction (42 %). « L'enquête de cette année est cohérente avec celles de ces dernières années en ce sens que la culture organisationnelle s'impose comme un facteur critique du succès de l'adoption et de la mise à l'échelle de l'agilité », explique CollabNet dans un communiqué. Le rapport indique toutefois que par rapport à l'édition précédente, il y a une diminution du pourcentage de répondants citant la culture organisationnelle comme un obstacle à l'adoption de l'Agile.

Parmi les méthodologies agiles les plus utilisées, Scrum reste largement en tête avec 56 %.

« Année après année, le rapport annuel State of Agile a aidé notre industrie à évaluer l'adoption et l'efficacité de l'agilité dans les entreprises de logiciels », a déclaré Lee Cunningham, directeur, Enterprise Agile Strategy, chez CollabNet. « Le rapport de cette année affirme l'efficacité de l'Agile dans l'accélération de la livraison de logiciels et aide les équipes à gérer les priorités changeantes au sein de leurs organisations. Nous voyons aussi dans le rapport de cette année que l'adoption de l’Agile a encore beaucoup de chemin à faire », dit-il.

Sources : Communiqué de CollabNet, Rapport de l'étude

Et vous ?

Que pensez-vous des résultats de l'étude ?
Qu'en est-il de l'adoption de l'Agile dans votre entreprise ?
Quelle est votre expérience des pratiques agiles ?
Quelles méthodologies préférez-vous ? Pourquoi ?

Voir aussi :

Un développeur estime qu'Agile est un « loup déguisé en agneau », le Waterfall 2.0, qu'en pensez-vous ?
Quels sont les différents moyens pour augmenter la productivité dans une équipe agile ? Retour de discussion avec un Microsoft User Group
Agile : un blogueur estime que le but n'est pas de réduire le temps de développement des logiciels, qu'en pensez-vous ?

[vayel]

les méthodes agile c'est juste du bullshit

moi je fais du code mcdo sa vas plus vite
Je paye des roumains a pas cher pour pisser du code et tous fouttre dans un fichier, sns doc ni test

on a des programme rapidement et a pas cher c'est l'avenir, c'est peut etre sa finalement l'agilité que nous recherchons. pour info j'ai breveté ctte méthode si vous voulez l'utiliser il me faudra verser des royaties (de l'argent sa veut dire si conaissez pas ce mots apres tous certains ici sont encore inexpérimenté mais sont la our apprendre)

[Jamatronic]

Chercheur en informatique ? Vraiment ? Et il écrit comme un cancre.

[codec_abc]

Ceci dit il a raison, l'agile c'est globalement du "snake oil" comme dit les anglais. Y'a jamais eu de preuves que ça marche mieux que le waterfall ou autre. Souvent ça sert juste d'excuse pour justifier le bronx au niveau de l'organisation.

Accessoirement, c'est bien pour mettre la pression sur les employés de manière constante en 3 étapes:
1. On leur demande des estimations de charge au rabais. De manière déguisé et en les infantilisant si possible (poker planning). Aussi on prend pas en compte qu'une estimation c'est souvent une gaussienne et que la largeur du "pic" peut-être très variable suivant les tâches.
2. On les forces a les diminuer.
3. On attend 2-3 jours en début de sprint afin d'être certain qu'ils ne tiennent pas la vitesse requise pour leur rappeler que la fin du sprint est dans X jours et que c'est eux qui se sont engagés sur les estimations.

Aussi, ce qui me fait rire c'est que certaines grosses boitent veulent se mettre à l'agile et notamment a scrum. Sauf que la plupart ont oubliés que scrum veut dire mêlée en anglais et que c'est une phase transitoire au rugby pour recadrer les choses avant de reprendre un jeu normal. Et que donc que la phase de mêlée n'est pas faite pour durée.

Quant à l'article, j'aimerai bien savoir comment des gens pensent que l'agile ça augmente la productivité et la qualité du code. C'est pas en faisant un daily meeting, du poker planning, du sprint review et j'en passe qu'on va avoir une meilleur productivité. Et pour la qualité c'est pas en revenant en arrière sur des features toutes les 2-3 sprints (ce qui se passe assez souvent d'après mon experience) que le code va s'améliorer, plutôt le contraire même.

Et finalement, quant on voit le cycle de release de projet à succès (kernel Linux, Debian, Qt, etc...) ça donne plutôt l'impression qu'un produit dont la durée de vie est un minimum sérieux à plutôt intérêt a faire des livrables régulier mais suffisamment espacés dans le temps.

[vayel]

Ceci dit il a raison, l'agile c'est globalement du "snake oil" comme dit les anglais. Y'a jamais eu de preuves que ça marche mieux que le waterfall ou autre. Souvent ça sert juste d'excuse pour justifier le bronx au niveau de l'organisation.

Accessoirement, c'est bien pour mettre la pression sur les employés de manière constante en 3 étapes:
1. On leur demande des estimations de charge au rabais. De manière déguisé et en les infantilisant si possible (poker planning). Aussi on prend pas en compte qu'une estimation c'est souvent une gaussienne et que la largeur du "pic" peut-être très variable suivant les tâches.
2. On les forces a les diminuer.
3. On attend 2-3 jours en début de sprint afin d'être certain qu'ils ne tiennent pas la vitesse requise pour leur rappeler que la fin du sprint est dans X jours et que c'est eux qui se sont engagés sur les estimations.

Aussi, ce qui me fait rire c'est que certaines grosses boitent veulent se mettre à l'agile et notamment a scrum. Sauf que la plupart ont oubliés que scrum veut dire mêlée en anglais et que c'est une phase transitoire au rugby pour recadrer les choses avant de reprendre un jeu normal. Et que donc que la phase de mêlée n'est pas faite pour durée.

Quant à l'article, j'aimerai bien savoir comment des gens pensent que l'agile ça augmente la productivité et la qualité du code. C'est pas en faisant un daily meeting, du poker planning, du sprint review et j'en passe qu'on va avoir une meilleur productivité. Et pour la qualité c'est pas en revenant en arrière sur des features toutes les 2-3 sprints (ce qui se passe assez souvent d'après mon experience) que le code va s'améliorer, plutôt le contraire même.

Et finalement, quant on voit le cycle de release de projet à succès (kernel Linux, Debian, Qt, etc...) ça donne plutôt l'impression qu'un produit dont la durée de vie est un minimum sérieux à plutôt intérêt a faire des livrables régulier mais suffisamment espacés dans le temps.

l'agile c'est surtout donner le pouvoir aux petites équipes, le grand manager doit faire confiance. et les petits chef n'existent plus (je veut dire les chefs des petites équipes pas les petits chef dans le sens dictateur incompétent) puisque en agile y'a pas de chef en théorie, il y'a un scrum master (qui doit changer a chaque sprint) charger de la cohésion du groupe.

Mais cela n'existe pas.

Et l'agile globalement fait perdre du temps, faut entretenir des outils abominable (Jira, genkins, ...) faire des statistiques (burdonw chart...).

j'en reviens donc au ville méthodes : on code et on test a la main, pas de test unitaire rien nada

[Mingolito]

Donc agile ou Scrum c'est des mots à la mode pour s'autoriser à coder avec des pieds et à faire de la merde n'importe comment ? Sauf que au lieu de dire "je code n'importe quoi n'importe comment suivant mon inspiration", tu dis "j'utilise la méthode agile" c'est plus Hype ?

Donc moi quand je programmais en amateur du code sans cahier des charges, sans analyse, sans modélisation et sans méthodes, sans tests, sans recette, je faisait en fait de la méthode agile ?

[4sStylZ]

Et ben. Il y en a de la belle moisissure argumentative ici.
C’est rempli de fausse croyances, de points de vue très personnels mais pire, beaucoup de ce qui est dit censé critiquer agile ne reflète pas agile.
Le must have c’est « Ça s’appelle scrum donc c’est la melee donc ça doit pas durer ». Et waterfall, c’est une chute d’eau donc ça s’arrête jamais de pleuvoir ?

Bref. Je suis PO, ancien dev, je me suis épanouis grâce à cette méthode.

[tpericard]

Ben justement, en tant que Product Owner tu pourrais nous expliquer en quoi l'approche Agile t'a si bien épanoui, en quoi est ce différent de l'approche Waterfall (cycle en V) ? En quoi cela peut être + bénéfique pour le produit ?

Au passage, j'aime bien le terme WaterFall qui illustre bien le danger potentiel de cette approche (l'effet tunnel). Une fois sorti de la cascade, on constate qu'il y a eu des changements etc ... du coup l'approche Agile semble plus intéressante pour éviter cet effet, pour "coller" aux besoins du client.

[Pyramidev]

Avant de complimenter ou de blâmer le développement agile, il faut en connaître la définition.

Celle-ci est donnée par le manifeste agile :

Ces expériences nous ont amenés à valoriser :

Les individus et leurs interactions plus que les processus et les outils
Des logiciels opérationnels plus qu’une documentation exhaustive
La collaboration avec les clients plus que la négociation contractuelle
L’adaptation au changement plus que le suivi d’un plan

Nous reconnaissons la valeur des seconds éléments, mais privilégions les premiers.

Plus de précisions sont données dans les 12 principes sous-jacents au manifeste :

Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée.

Accueillez positivement les changements de besoins, même tard dans le projet. Les processus Agiles exploitent le changement pour donner un avantage compétitif au client.

Livrez fréquemment un logiciel opérationnel avec des cycles de quelques semaines à quelques mois et une préférence pour les plus courts.

Les utilisateurs ou leurs représentants et les développeurs doivent travailler ensemble quotidiennement tout au long du projet.

Réalisez les projets avec des personnes motivées. Fournissez-leur l’environnement et le soutien dont ils ont besoin et faites-leur confiance pour atteindre les objectifs fixés.

La méthode la plus simple et la plus efficace pour transmettre de l’information à l'équipe de développement et à l’intérieur de celle-ci est le dialogue en face à face.

Un logiciel opérationnel est la principale mesure d’avancement.

Les processus Agiles encouragent un rythme de développement soutenable. Ensemble, les commanditaires, les développeurs et les utilisateurs devraient être capables de maintenir indéfiniment un rythme constant.

Une attention continue à l'excellence technique et à une bonne conception renforce l’Agilité.

La simplicité – c’est-à-dire l’art de minimiser la quantité de travail inutile – est essentielle.

Les meilleures architectures, spécifications et conceptions émergent d'équipes autoorganisées.

À intervalles réguliers, l'équipe réfléchit aux moyens de devenir plus efficace, puis règle et modifie son comportement en conséquence.

Personnellement, ce qui me gêne le plus dans le développement agile, c'est le fait de négliger la communication écrite (dont la documentation). Quand on privilégie trop l'oral sur l'écrit, on perd des informations importantes, surtout quand un développeur quitte la boîte.

[tpericard]

C'est clair que de nombreux projets Agile tombent dans le piège "oh, je suis en Agile, je me simplifie le quotidien. Je fais juste l'essentiel (le code) et pas le temps pour la doc.... ".
Cependant, pour avoir vu et être intégré dans un certain nombre de projets Agile (en tant que Dev ou testeur), j'ai vu aussi des équipes qui intégraient dans leur résultat d'itération les notions de tests et de documentations. Sans parler non plus des bienfaits (si, si) des tests automatisés qui permettent d'évaluer la non régression tout au long des itérations.

En fait, la documentation doit être continue, mais se limiter au strict nécessaire pour assurer une maintenance future.

[codec_abc]

Et ben. Il y en a de la belle moisissure argumentative ici.
C’est rempli de fausse croyances, de points de vue très personnels mais pire, beaucoup de ce qui est dit censé critiquer agile ne reflète pas agile.
Le must have c’est « Ça s’appelle scrum donc c’est la melee donc ça doit pas durer ». Et waterfall, c’est une chute d’eau donc ça s’arrête jamais de pleuvoir ?

Bref. Je suis PO, ancien dev, je me suis épanouis grâce à cette méthode.

Ca c'est vraiment l'argument de mauvaise fois que j'entends a chaque fois. Un convaincu de l'agile présente la méthodologie, certaines personnes vont dires qu'ils l'ont appliqués et que c'est un échec total et la réponse c'est "a mais c'est pas de l'agile ce que vous faites sinon ca marcherai bien". Bref ca sous entend la définition de l'agile c'est d'avoir un projet réussi.

Et pour quelqu'un qui se plaint de moisissure argumentative je cherche toujours les arguments dans ta réponse.

PS: Je recommande aux pro agile de regarder la vidéo d'Erik Meijer sur le sujet surtout le début. Le bonhomme ayant un certain bagage technique (il a aidé a crée LINQ notamment) et étant passé dans des grosses boites (Microsoft, Facebook) il a un certain bagage qui lui permet de prendre du recul sur le sujet.

[Pyramidev]

Je viens de visionner la vidéo. Erik Meijer dit blâmer l'agile. Il blâme les stand-up meetings spécifiques à Scrum ainsi que d'autres aspects organisationnels présents en entreprise. Mais, en réalité, dans la vidéo, ce qu'il blâme n'est pas le développement agile défini par le manifeste agile.

Pendant une grosse partie de la vidéo, Erik Meijer insiste sur l'importance du feedback en général. Quand il critique Microsoft, il évoque l'importance du feedback des utilisateurs. Or, dans le développement agile, les cycles de développement courts ont pour but d'avoir un feedback rapide.

À un autre moment, il vante les équipes auto-organisées : les gestionnaires fixent des buts et les développeurs s'auto-organisent. Or, c'est justement ce que soutient le développement agile : Les meilleures architectures, spécifications et conceptions émergent d'équipes autoorganisées.

Hors-sujet : Erik Meijer s'oppose aux tests, même automatisés, et dit qu'il faudrait pousser directement en production. Je pense que cette position est aberrante, mais on s'écarte du sujet car le manifeste agile ne dit rien sur les tests.

Avant d'être pour ou contre l'agile, il faut se mettre d'accord sur ce qui est agile et ce qui ne l'est pas. Je propose les critères suivants :

• Analyse du besoin :
  
  • Pro-agile : on commence à coder d'abord et l'utilisateur expliquera plus précisément son besoin ensuite, car l'utilisateur n'est pas capable d'exprimer précisément son besoin avant d'avoir quelque chose de concret sous la main. Ensuite, on modifiera le code.
  • Anti-agile : on maximise les efforts sur l'analyse du besoin avant de commencer à coder. On présume que l'expression du besoin ne changera alors pas trop en cours de route.
• Durée des cycles de développement :
  
  • Pro-agile : les cycles doivent être courts. Cela permet d'avoir un feedback plus rapide.
  • Anti-agile : les cycles doivent être longs. À la fin de chaque cycle, on livre plein de fonctionnalités d'un coup. Cela permet aux développeurs de glisser plus facilement des investissements sans que le client et la hiérarchie aient l'impression que ça arrête d'avancer.
• Contrôles :
  
  • Pro-agile : pas de contrôles. Les meilleures architectures, spécifications et conceptions émergent d'équipes autoorganisées.
  • Anti-agile : il faut contrôler la qualité du travail pour vérifier que l'équipe ne mette pas en place une dette technique excessive que l'on découvrira trop tard.
• Mode de communication :
  
  • Pro-agile : il faut privilégier la communication orale. C'est plus interactif et plus rapide.
  • Anti-agile : il faut privilégier la communication écrite. Cela permet de perdre moins d'informations.

J'ai volontairement enlevé les phrases de propagande comme :

• Une attention continue à l'excellence technique et à une bonne conception renforce l’Agilité.
• La simplicité – c’est-à-dire l’art de minimiser la quantité de travail inutile – est essentielle.

En effet, aucune méthode de développement ne va explicitement promouvoir la médiocrité technique, la mauvaise conception et l'art de maximiser la quantité de travail inutile.

[codec_abc]

Tu as fait l'effort de faire un post construit contrairement aux autres qui défendent l'agile sans argument. C'est très appréciable, merci.

Concernant la vidéo, je ne suis pas non plus d'accord en intégralité avec ce que dit Meijer mais il soulève notamment des points intéressants. Son point concernant le stand up est que ça prend du temps et qu'il est probablement inutile ou du moins que son impact n'est pas mesurable.

Et en parlant de mesure c'est la l'argument le plus intéressant. Comme il 'adit, il n'existe aucune preuve statistique (hormis les études bidon financées par des cabinet de conseil en développement agile) à ce jour qui prouve que les méthodes agiles ont un quelconque avantage sur les autres méthodes. Donc de ce point de vue là, les méthodes agiles sont comme l'acupuncture, une pseudo-science (on peut sans doute parler d'effet placebo). Le soucis sur les débats du bien fondé de l'agile c'est que beaucoup de personnes ont un intérêt économique à les défendre car elles (cabinent de conseil en agile, Scrum master, Product Owner, etc..) en ont fait leurs gagne pain et remettre en question l'agile serait remettre en question leurs travail. Ce phénomène est d'autant plus accentué en France car passé un certain age on évolue plus en faisant de la technique et si on veut continuer sa carrière sans finir au placard on doit migrer sur ce genre de postes.

Aussi, Ce qui n'aide pas c'est la définition des méthodes agiles qui est tellement vague que chacun va avoir son interprétation. Le seul élément que l'on retrouve semble être le cycle de développement assez court. Elle ne parle jamais de test, de documentation, d'intégration continue, de code review, de bugs, de dette technique, etc..

[el_slapper]

(.../...)Hors-sujet : Erik Meijer s'oppose aux tests, même automatisés, et dit qu'il faudrait pousser directement en production. Je pense que cette position est aberrante, mais on s'écarte du sujet car le manifeste agile ne dit rien sur les tests.(.../...)

Sur que là je ne suis pas d'accord avec lui. Mes tests automatiques on permis de détecter, avant mise en production, un bug sur les dosages d'intraveineuses qui auraient tué des bébés, dans tous les pays clients qui utilisent notre produit avec une virgule décimale au lieu du point(en gros, la France et le Chili, ces roublards d'italiens ont convaincu leurs clients d'utiliser le point comme séparateur décimal...). Oui, tuer des bébés hospitalisés. Dont le mien il n'y a pas deux mois. Un bête bug invisible en test unitaire pour les programmeurs qui travaillent uniquement en point décimal.

C'est le genre de mode de pensée qui marchouille dans des domaines ou le bug n'est pas grave, mais bon, il y a aussi des domaines sérieux, ou ce genre de bullshit n'a pas sa place. D'ont l'intérêt, encore une fois, de ressortir ce vieux classique de Joel Splosky : il y a plein de mondes différents en informatique. Ce qui est vrai en web n'est pas vrai dans les banques. Ce qui est vrai dans les banques n'est pas vrai en hospitalier. Ce qui est vrai en hospitalier n'est pas vrai en aérospatial. Etc.....