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

Le , par Michael Guilloux, Chroniqueur Actualités
CollabNet, le fournisseur de solutions DevOps vient de publier le 12e 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 5e position.


Il existe toutefois des obstacles à l'adoption et la mise à l'échelle de l'Agile au sein des organisations. La 12e é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 ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse Signaler un problème

Avatar de vayel vayel - Inactif https://www.developpez.com
le 16/04/2018 à 19:54
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)
Avatar de Jamatronic Jamatronic - Membre averti https://www.developpez.com
le 16/04/2018 à 20:11
Chercheur en informatique ? Vraiment ? Et il écrit comme un cancre.
Avatar de codec_abc codec_abc - Membre averti https://www.developpez.com
le 16/04/2018 à 21:01
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.
Avatar de vayel vayel - Inactif https://www.developpez.com
le 16/04/2018 à 21:13
Citation Envoyé par codec_abc Voir le message
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
Avatar de Mingolito Mingolito - Membre extrêmement actif https://www.developpez.com
le 16/04/2018 à 21:14
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 ?
Avatar de 4sStylZ 4sStylZ - Membre éclairé https://www.developpez.com
le 16/04/2018 à 22:25
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.
Avatar de tpericard tpericard - Membre actif https://www.developpez.com
le 16/04/2018 à 23:25
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.
Avatar de Pyramidev Pyramidev - Membre expert https://www.developpez.com
le 16/04/2018 à 23:42
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.
Avatar de tpericard tpericard - Membre actif https://www.developpez.com
le 17/04/2018 à 7:45
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.
Avatar de codec_abc codec_abc - Membre averti https://www.developpez.com
le 17/04/2018 à 12:43
Citation Envoyé par 4sStylZ Voir le message
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.

Contacter le responsable de la rubrique Accueil