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 !

Tout le monde prétend suivre les méthodes agiles dans son travail
Mais en réalité, peu de personnes le font vraiment

Le , par Jonathan

613PARTAGES

9  0 
On entend très régulièrement parler de méthodes agiles et plusieurs personnes d'ailleurs disent les utiliser dans leur travail, mais bien souvent la réalité est toute autre. Il se trouve que ces personnes se servent plutôt de quelque chose de très différent des méthodes agiles conventionnelles. Tout d'abord, il faut savoir qu'une méthode agile est une méthode de gestion et de développement de projets ou programmes informatiques qui vise à satisfaire les besoins du client au terme du contrat de développement.

Lorsqu'elles sont bien appliquées, les méthodes agiles permettent d'organiser le travail de façon à rendre les équipes faisant partie du projet, très productives. Seulement, il a pu être observé que dans bon nombre d'entreprises qui disaient utiliser des méthodes agiles dans leurs projets, il subsiste de graves manquements qui n'existeraient pas si les méthodes agiles étaient correctement adoptées. En fait, malgré l'intention de ces entreprises d'adopter des méthodes agiles, elles sont parfois contraintes en raison de certaines difficultés, de finir par travailler d'une manière qui ne ressemble pas du tout à une méthode de travail agile.


Certaines entreprises, juste pour suivre la tendance, se lancent dans certaines pratiques plus ou moins agiles et qui parfois ne correspondent pas à leurs équipes. C'est le cas de celles qui décident d'organiser le travail en Sprints de 2 semaines au cours desquelles les équipes doivent pouvoir produire des livrables (solutions présentables au client). Cette façon de faire peut ne pas correspondre à toutes les équipes et entraîner des ralentissements dans le travail étant donné que parfois le livrable produit par une équipe ne peut fonctionner sans celui produit par une autre.

Les méthodes agiles impliquent de développer un produit dans sa forme la plus fine et de le mettre le plus rapidement possible entre les mains de véritables utilisateurs, afin que ces derniers le testent et donnent leurs avis. De plus en plus, les clients veulent participer au développement du produit qui leur sera proposé et non plus être des consommateurs passifs. Le fait que certains dirigeants d'entreprises ne s'en rendent pas compte peut aussi constituer une difficulté à la pleine adoption des méthodes agiles.

Bien que les dirigeants d'entreprises aient leur part de responsabilité puisqu'ils sont les décideurs, ils ne sont pas les seuls fautifs dans cette affaire. Les employés eux aussi peuvent constituer un problème dans le sens où ils s'opposent à la culture même des équipes agiles. En effet, pour fonctionner efficacement, les méthodes agiles s'appuient sur des personnes ayant une profonde expertise dans un domaine, un intérêt général et une volonté d'apprendre dans de nombreux autres domaines de compétences. Mais, il peut arriver qu'au sein d'une équipe, se trouvent des personnes qui s'en tiennent uniquement à un seul domaine d'expertise en refusant d'apprendre ou de contribuer dans un autre domaine.

A tout ceci, peuvent encore s'ajouter plusieurs autres éléments qui compromettent la pleine adoption des méthodes agiles dans les entreprises. Pourtant, à la question de savoir s'ils utilisent des méthodes agiles, plusieurs managers répondent par l'affirmative, ne sachant pas vraiment qu'en réalité, en ne respectant pas certains aspects qu'impose Agile, ils ont plutôt adopté quelque chose de très différent.

Source : QZ

Et vous ?

Que pensez-vous des méthodes agiles ? Pensez-vous comme certains qu'elles devraient être abandonnées ?
Que pensez-vous des Sprints ? Sont-ils adaptés à toutes les équipes ?
Pensez-vous que vous ou votre entreprise utilisez réellement les méthodes agiles ?

Voir aussi :

Les développeurs devraient abandonner les méthodes agiles selon Ron Jeffries, l'un des signataires du Manifeste Agile
Agile : entre Scrum et Kanban, laquelle des deux méthodologies est-elle la meilleure ? Le point dans une étude comparative
CollabNet : l'adoption des pratiques agiles augmente en entreprise, mais très peu d'organisations auraient un haut niveau de compétence

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

Avatar de grunk
Modérateur https://www.developpez.com
Le 02/05/2019 à 17:04
A moins de ne pas avoir de client et/ou de boss je vois pas bien comment il est possible d'appliquer à la lettre quelconque méthode (agile ou pas).

Quand un client te dis je veux une version pour dans 3 jours parce que il avait oublié cette échéance hyper importante , tu peux pas vraiment lui répondre
- "ha ba non là du coup en vient de commencer un sprint de 2 semaines , va falloir attendre" , ou encore ,
- "euh ... on à fait qu'une branche du V, va falloir attendre ..."

Tu dis plutôt "Oui monsieur , merci monsieur ce sera prêt " et tu jette par la fenêtre toutes les bonnes pratiques en vigueur dans le but de satisfaire ton client et pas perdre une commande.

Après quand tu es éditeur de soft , avec un planning de release prédéfini c'est déjà beaucoup plus facile de travailler comme ça. Par contre quand ton dév est dirigé par les appel d'offre et le commerce c'est mission impossible.

Chez nous , on applique pas une méthode en particulier , on fait en sorte d'être le plus agile possible , c'est à dire répondre rapidement à des demandes/changements mais on s'impose surtout pas de contrainte du style réunion tt les jours , sprint de X jours tous les Y jours , etc;..
8  0 
Avatar de supergeoffrey
Membre expérimenté https://www.developpez.com
Le 02/05/2019 à 16:10
Pour rappel, il y a 4 règles qui définissent les méthodes agiles.

https://agilemanifesto.org/iso/fr/manifesto.html
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
Ce n'est pas très compliqué à faire des méthodes agiles quand on y pense.
6  0 
Avatar de pboulanger
Membre éprouvé https://www.developpez.com
Le 02/05/2019 à 16:38
Globalement, dans toutes les entreprises, il y a des professionnels TRES agiles: ils sont extrèmement doués pour éviter les patates chaudes...

Dans une startup ou une équipe qui est très autonome, les méthodes agiles peuvent présenter un intérêt... Pour une boîte de 20000 personnes avec des dépendances/adhérences entre les équipes cela devient plus compliqué...
6  0 
Avatar de sergio_is_back
Expert confirmé https://www.developpez.com
Le 02/05/2019 à 17:14
Citation Envoyé par grunk Voir le message
A moins de ne pas avoir de client et/ou de boss je vois pas bien comment il est possible d'appliquer à la lettre quelconque méthode (agile ou pas).

Quand un client te dis je veux une version pour dans 3 jours parce que il avait oublié cette échéance hyper importante , tu peux pas vraiment lui répondre
- "ha ba non là du coup en vient de commencer un sprint de 2 semaines , va falloir attendre" , ou encore ,
- "euh ... on à fait qu'une branche du V, va falloir attendre ..."

Tu dis plutôt "Oui monsieur , merci monsieur ce sera prêt " et tu jette par la fenêtre toutes les bonnes pratiques en vigueur dans le but de satisfaire ton client et pas perdre une commande.

Après quand tu es éditeur de soft , avec un planning de release prédéfini c'est déjà beaucoup plus facile de travailler comme ça. Par contre quand ton dév est dirigé par les appel d'offre et le commerce c'est mission impossible.

Chez nous , on applique pas une méthode en particulier , on fait en sorte d'être le plus agile possible , c'est à dire répondre rapidement à des demandes/changements mais on s'impose surtout pas de contrainte du style réunion tt les jours , sprint de X jours tous les Y jours , etc;..
Je rejoint ton expérience là : Je suis dans une petite boite (seulement 4 dév dans l'équipe) et ce qui prime surtout en fin d'exercice quand il va falloir faire le bilan c'est de livrer tout ce qui est possible de livrer alors on prend des chemins de traverse , plus d'assurance qualité (alors que pendant le reste de l'année c'est : revue de projet, analyse, point d'avancement, etc...) là on jette le tout aux orties pendant les 3 trois derniers mois de l'exercice... Ceci ça m'a toujours fait rire... Quand je vois la tête de notre consultant qualité lorsqu'on lui que pendant les trois prochains mois il peut se carrer ses formulaires qualité dans l'oignon... et le directeur lui dit devant tout le monde que c'est bien beau mais qu'il faut penser au chiffre d'affaire en priorité...

Et puis les méthodes agiles... en vieillissant ça devient de plus en dur (j'ai passé la cinquantaine)....
5  0 
Avatar de pschiit
Membre actif https://www.developpez.com
Le 04/05/2019 à 19:02
Citation Envoyé par Ryu2000 Voir le message
Hein ?
Normalement ce n'est pas censé être un stand-up meeting et durer moins de 5 minutes ? On dit ce qu'on a fait hier, ce qu'on a prévu de faire aujourd'hui et si on a vu un problème qui pourrait empêcher d'attendre les objectifs du sprint ?
Il y a des concepts qui sont mal appliqués.

Moi l'aspect agile que j'aime bien c'est de montrer régulièrement au client la progression du développement et de récupérer ses retours sur la dernière version qu'il lui a été livré.
on en est pas loin,
5-10 min de sprint planning par jour
60 min "sprint planning 1" par sprint pour qualifier les taches (compter 2h d'étude avant le SP2)
60 min "sprint planning 2" par sprint finir la qualification et l'attribution des taches
90 min " sprint review" par sprint
60 min de retrospective par sprint.

Au final l'agilité se transforme en une torture de réunions sans fin
5  0 
Avatar de Pierre Louis Chevalier
Expert éminent sénior https://www.developpez.com
Le 02/05/2019 à 16:17
Cet article est très réaliste. Ce mot est utilisé par pleins de gens pour faire croire qu'ils sont à la mode, mais dans les faits les processus sont rarement respectés.
D'une façon générale dans le secteur du développement il y a un manque flagrant de bons managers, car le management n'est pas tellement dans la culture des geeks qui constituent le plus gros de ceux qui vont dans la filière IT, et quand il y a de bons managers issu des filières de management et pas de l'IT ils sont le plus souvent largués sur la partie technique, donc les deux mondes ont du mal à se rejoindre de façon efficace. Ça peu parfois déboucher vers quelque chose chez un très petit nombre d'individus mais le plus souvent après un très grand nombre d'années d'expérience.
4  0 
Avatar de youtpout978
Expert confirmé https://www.developpez.com
Le 03/05/2019 à 9:07
A chaque fois qu’on m’en parle je dis que je connais mais jamais appliquée complètement, quand on m’a sorti le pipo ici on pratique la méthodologie agile je les vois arriver avec leur gros sabots, au finale le client prend ce qui lui arrange, résultat des réunions de 30-45 min tous les matins, ils veulent qu’on respecte les délais des sprints sans nous en laisser le temps ...
4  0 
Avatar de Marco46
Expert éminent sénior https://www.developpez.com
Le 03/05/2019 à 11:08
Citation Envoyé par blbird Voir le message
La méthode agile a pas mal d'avantages, mais pour moi un gros inconvénient qui en découle : celui d'avoir du mal à définir un budget et une date de livraison globale précise.
J'ai du mal à te suivre. L'agile avec SCRUM c'est justement un budget fixe avec des dates de livraison figées et un scope qui varie. C'est ça le principe. T'as des échéances de livraisons prédéfinies et tu livres ce que tu as terminé (variable) à ces dates.
3  0 
Avatar de Marco46
Expert éminent sénior https://www.developpez.com
Le 03/05/2019 à 11:13
Citation Envoyé par youtpout978 Voir le message
ils veulent qu’on respecte les délais des sprints sans nous en laisser le temps ...
C'est juste que vous faites pas de l'agile. Le principe de base de l'agile c'est que le contenu d'un sprint n'est pas un engagement sur un périmètre. Il y a des dates de livraisons fixes avec un scope variable. Les tâches sont estimées et ensuite on voit le consommé réel. En aucun cas on ne peut exiger une livraisons d'un scope figé à une date figée. C'est justement pour arrêter de faire ça que l'agile a été créé.

La situation que tu décris c'est une organisation qui faisait du waterfall ou du Cycle en V et qui essaie de se mettre à l'agile sans avoir changé fondamentalement sa manière de travailler. C'est un problème très courant du à un manque de compréhension de l'agile à tous les échelons de l'organisation (chef qui veut sa feature à date).
3  0 
Avatar de Marco46
Expert éminent sénior https://www.developpez.com
Le 03/05/2019 à 11:17
Citation Envoyé par grunk Voir le message
A moins de ne pas avoir de client et/ou de boss je vois pas bien comment il est possible d'appliquer à la lettre quelconque méthode (agile ou pas).

Quand un client te dis je veux une version pour dans 3 jours parce que il avait oublié cette échéance hyper importante , tu peux pas vraiment lui répondre
- "ha ba non là du coup en vient de commencer un sprint de 2 semaines , va falloir attendre" , ou encore ,
- "euh ... on à fait qu'une branche du V, va falloir attendre ..."

Tu dis plutôt "Oui monsieur , merci monsieur ce sera prêt " et tu jette par la fenêtre toutes les bonnes pratiques en vigueur dans le but de satisfaire ton client et pas perdre une commande.
Ça c'est du forfait. Ce n'est pas compatible avec de l'agile.
3  0