Agile est simple, mais n'est pas facile,
Car il nécessite l'évolution de la manière d'interagir et de raisonner des développeurs

Le , par Arsene Newman, Expert éminent sénior
Même si le développement agile est de plus en plus utilisé au sein de la communauté des développeurs, force est de constater que cela n’empêche pas l’échec cuisant de certaines équipes de développement. La faute à qui ? À Agile ou aux développeurs ?

Pour Dwight Kingdon, expert en gestion de projets IT et adepte d’agile depuis 9 ans, la réponse est claire : agile nécessite la transformation des développeurs et l’évolution de leur état d’esprit.

Kingdon souligne un fait important : « les équipes de développement qui échouent lors de l’adoption d’Agile mettent trop l’accent sur les parties les plus faciles, mais ne consacrent pas assez de temps et d’efforts aux parties les plus difficiles ». D’ailleurs, au sein de la communauté agile une phrase récurrente illustre ce constat : « Agile est simple, mais n’est pas facile ». Alors, que faut-il en déduire ?

Tout d’abord, il faut noter qu’agile relève plus d’un état d’esprit, d’une culture et de principes, plutôt que de méthodes et de pratiques. De ce fait, la partie la plus difficile avec agile est la transformation de la perception des principes autour d’agile. Le succès passe par la consécration du temps et de l’énergie pour que les équipes de développement évoluent dans leur manière d’interagir, de travailler et de raisonner.

Ainsi, parmi les principes agiles les plus intéressants figure : « les parties prenantes (le client et les développeurs) doivent collaborer régulièrement et de préférence quotidiennement au projet ». Son application est l’une des plus difficiles à mettre en place. Toutefois, ce principe fait la différence entre une équipe qui réussit et une autre qui échoue, principalement à cause des divergences qui peuvent naitre entre l’attente du client et le travail du développeur.

L’esprit agile impose aussi la nécessité de l’analyse continue, de l’introspection et de la réadaptation. Malheureusement, cet état d’esprit si cher à agile est souvent délaissé par les équipes de développement, car entrevu comme une perte de temps et d’énergie.

Bien que les principes agiles priment sur les pratiques agiles, l’expert souligne l’importance de certaines d’entre elles qui tendent à améliorer les performances et à offrir une certaine maturité aux équipes qui les adoptent. Il note comme exemple l’intégration continue qui s’inscrit dans le cadre du développement incrémental et les tests automatiques qui permettent de s’assurer de la qualité du produit, de son bon fonctionnement.

Au final, même si les pratiques agiles sont importantes et fournissent des directives qui peuvent aider à la réussite du projet, les principes qui demeurent la partie la plus difficile à entrevoir et à adopter dans agile sont ce qui rend agile durable sur le long terme et permettent de maximiser ses avantages.

Source : article de Dwight Kingdon

Et vous ?

Êtes-vous d’accord avec le constat suivant : "agile est simple, mais n’est pas facile" ?


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


 Poster une réponse

Avatar de 23JFK 23JFK - Membre éclairé http://www.developpez.com
le 21/07/2014 à 8:37
Agile... cette chimère management à la peau dure.
Avatar de super_navide super_navide - Provisoirement toléré http://www.developpez.com
le 21/07/2014 à 8:47
Agile encore un terme marketing pour créer des job d'expert qui ne veulent plus développer et qui servent rien.
Pour qu'un projet fonctionne c simple , une spécification claire , une expression de besoins claire , des développeurs avec de expériences , un plan de test bien détaillé (apres automatique ou manuel c une question de coup ) et voilà ça fonctionne...........

Pour qu'un projet informatique fonctionne il faut avant tout de pas dévaloriser le boulot de concepteur-développeur , et arrété avec les titre de pilote de projet, architecte , chef de projet etc ...
Un projet fonctionne avec de bon concepteur développeur.
Avatar de valkirys valkirys - Membre expérimenté http://www.developpez.com
le 21/07/2014 à 9:04
Citation Envoyé par Arsene Newman  Voir le message
...

Encore un expert!! Je me fais cette réflexion à chaque fois dommage car ce sont les gens normaux qui codent
Je commente la news, c'est trop tôt pour lire l'article en anglais.

Citation Envoyé par Arsene Newman
Même si le développement agile est de plus en plus utilisé au sein de la communauté de développeurs, force est de constater que cela n’empêche pas l’échec cuisant de certaines équipes de développement. La faute à qui ? À Agile ou aux développeurs?

C'est toujours la faute aux "dev" qui comprennent rien ! Sinon on a quelque part un comparatif des taux d'échec de chaque méthode?

Citation Envoyé par Arsene Newman
Pour Dwight Kingdon, expert en gestion de projets IT et adepte d’agile depuis 9 ans, la réponse est claire : agile nécessite la transformation des développeurs et l’évolution de leur état d’esprit.

Kingdon souligne un fait important : « les équipes de développement qui échouent lors de l’adoption d’Agile mettent trop d’accents sur les parties les plus faciles, mais ne consacrent pas assez de temps et d’efforts aux parties les plus difficiles ». D’ailleurs, au sein de la communauté agile une phrase récurrente illustre ce constat : « Agile est simple, mais n’est pas facile ». Alors, que faut-il en déduire ?

C'est assez évident, les gens ne changent pas en deux semaines, si ils faisaient en priorité les parties faciles c'était à "Mr expert en gestion de projets IT" de les contraindre dès le début à faire une meilleur conception et les pousser vers un choix de sprint plus efficace! ( efficace = raisonnable + mesurable + "ne laisse pas les gens sur le bord de la route" + ... )

Citation Envoyé par Arsene Newman
Tout d’abord, il faut noter qu’agile relève plus d’un état d’esprit, d’une culture et de principes, plutôt que de méthodes et de pratiques. De ce fait, la partie la plus difficile avec agile est la transformation de la perception des principes autour d’agile. Le succès passe par la consécration du temps et de l’énergie pour que les équipes de développement évoluent dans leur manière d’interagir, de travailler et de raisonner.

L’esprit agile impose aussi la nécessité de l’analyse continue, de l’introspection et de la réadaptation. Malheureusement, cet état d’esprit si cher à agile est souvent délaissé par les équipes de développement, car entrevue comme une perte de temps et d’énergie.

Bref le contraire de l'enseignement et de beaucoup de poste dans l'IT, c'est pas gagné!

Citation Envoyé par Arsene Newman
Ainsi, parmi les principes agiles les plus intéressants figure : « les parties prenantes (le client et les développeurs) doivent collaborer régulièrement et de préférence quotidiennement au projet ». Son application est l’une des plus difficiles à mettre en place. Toutefois, ce principe fait la différence entre une équipe qui réussit et une autre qui échoue, principalement à cause des divergences qui peuvent naitre entre l’attente du client et le travail du développeur.

Il note comme exemple l’intégration continue qui s’inscrit dans le cadre du développement incrémental et les tests automatiques qui permettent de s’assurer de la qualité du produit, de son bon fonctionnement.

Super ! Deux points primordiaux mais parmi les plus difficile à concrétiser et ce n'est pas les deux choses à faire en premier, pour passer à l'agile il faut :
- le conditionnement : arriver à l'heure aux réunions le matin , utiliser un tableau, faire des réunions pour apprendre à répartir le travail dans la durée et ne pas se précipiter...
- calibrer les sprints donc accepter les retards, erreurs, "mauvaise" organisation pendant une certaine période.
En gros le début c'est l'humain, la citation parle de réunions clients et de technique cela est visible donc apprécié de la direction mais s'éloigne des priorités du passage à l'agile.
Avatar de Patriarch24 Patriarch24 - Membre expérimenté http://www.developpez.com
le 21/07/2014 à 9:17
Pour qu'un projet fonctionne c simple , une spécification claire , une expression de besoins claire , des développeurs avec de expériences , un plan de test bien détaillé (apres automatique ou manuel c une question de coup ) et voilà ça fonctionne...........

Mais c'est bien sûr !!! Pourquoi donc personne n'y a pensé ?!

cette chimère management à la peau dure.

Les méthodes agiles ne sont en aucun cas des méthodes de management... Faut se renseigner un minimum

Le plus difficile dans ces méthodes, c'est effectivement faire changer les mentalités et la manière de travailler, sans aucun doute. La plupart des gens n'y sont certainement pas prêt, et sont déstabilisés. D'expérience, l'obstacle le plus rencontré est le manque de communication entre le client et l'équipe de développement, qui est (juste !) la fondation de ces méthodes.
Avatar de Traroth2 Traroth2 - Expert éminent http://www.developpez.com
le 21/07/2014 à 10:59
Le constat qu'il est nécessaire de faire mais que bizarrement personne ne fait, c'est que dans un nombre important de projets qui se plantent, l'échec n'est pas dû aux développeurs, mais à ce qui les entoure. Le manifeste agile dit "embrasser le changement", manière de dire que la demande doit pouvoir changer dès que le client le veut. Moi, je n'ai jamais eu aucun problème avec ça. Mais si on me dit que le délai et le budget ne changent pas, eux, là ça me pose un vrai putain de problème ! Et je ne suis pas près de changer d'avis sur le sujet.
Avatar de Saverok Saverok - Expert éminent http://www.developpez.com
le 21/07/2014 à 11:33
Le changement de mentalité avec la méthode Agile est surtout à opérer côté client.
Cette méthode implique énormément d'implication du client et beaucoup ne joue pas le jeu ou ne le comprennent pas.

Par expérience, beaucoup de clients "payent pour être tranquille" ou "si je paye, c'est pour que d'autres fassent à ma place"

Hors, avec la méthode Agile, le client devient en quelque sorte le "CP"
Il se doit d'être présent aux côtés des équipes presque tous les jours pour ajuster les spécifications, les priorités, etc.

Le changement de mentalité du côté des équipes techniques n'est pas si violent que ça.
Bien au contraire, avec la méthode Agile, il y a un rapprochement entre le technique et le client et les techos rendent compte directement au client.
Le rôle des techos est nettement plus mis en valeur avec l'Agile.

Avec l'Agile, ce n'est plus forfait avec le duo de choc intangible budget /planning
Là, on est dans du développement continue.
Les spécifications changent, des évolutions/ajustement interviennent et c'est normal et je dirai même, c'est la raison même de cette méthode de permettre cela
Avatar de noirbizarre noirbizarre - Membre régulier http://www.developpez.com
le 21/07/2014 à 12:16
Agile, Devops, fullstack... ah tout ces buzzwords transformés au fil du temps par les SSII et autres cabinets de recrutement.

Concernant l'agile spécifiquement, c'est un état d'esprit et non une méthode (A différencier de Scrum qui est une méthode agile, mais pas la seule)
Tout le monde dans l'entreprise doit être dans cet état d'esprit pour que cela fonctionne.
Une équipe seule qui fonctionne en "mode agile" dans une entreprise qui n'a pas du tout ce fonctionnement et cet état d'esprit, ça ne fonctionne pas.
Et arrêtez de croire qu'une certification Scrum Master transforme un chef de projet cycle en V en parfait petit soldat agile, ça ne fonctionne malheureusement pas comme ça.

De croire que seuls les développeurs se doivent d'être agile est l'erreur la plus courante, erreur que commet Dwight Kingdon apparemment.

Quelques éléments simples pour détecter l'Agile-Bullshit que l'on retrouve un peu partout aujourd'hui:
  • Une seule équipe agile au milieu d'une entreprise ou tout est en cycle en V
  • Une multiplication des rôles masquant un simple renommage des anciens métiers (AMOA, MOE...)
  • Amalgame agile/scrum (incompréhension complète de ce qu'est l'agile)
  • Réduction de l'agile à quelques rituels (souvent issus de scrum, encore) (daily meeting + poker planning != Agile)
  • Refus total de prise de risque et/ou d'innovation
  • Pas de pouvoir ou d'autonomie donné aux développeurs (le jour où on les considérera autrement que comme des ressources dans un Gant, ça sera déjà un vrai pas vers l'agile)
  • Pas d'interaction réelles entres les intervenants (l'éternel schéma tueur à la française du marketing qui décide sans consulter et du développeur qui doit exécuter sans discuter)
  • Aucun contact réel avec l'utilisateur final (donc pas de vrai feedback)
  • Des livraisons une fois l'an (là où l'agile préconiserai des itérations et des micro-livraisons)
  • Une stack technique ancestrale (souvent incompatible avec les livraisons incrémentales)
  • Une planification à 10 ans avec un diagramme de Gant
  • Des dates et périmètres de livraison tous les deux fixes souvent traduis par des reports perpétuels...
  • ...


Le manifeste agile tient en 4 concepts d'une ligne chacun donc quand j'entend parler de "LA méthode agile" ça commence mal (pas dans cet article mais dans les différents entretiens que je peux avoir).

L'agile est simple effectivement si les personnes qui l'applique restent sur des concepts simples.
Aujourd'hui ce n'est pas le cas et on se retrouve avec des processus parfois plus lourds que dans du cycle en V (ou autre processus issu du BTP ou de l'administration).

L'agile c'est avant tous des processus simples, peu nombreux, adaptés à la structure et adopté par tous, le tout avec un maximum d'interactions et un minimum de paperasse (cf. manifeste agile).

Malheureusement l'agile est trop souvent utilisé comme un prétexte pour augmenter la pression sur les équipes de dev alors que ce n'est pas le but du tout.
Je pourrai épiloguer pendant des heures sur ce sujet mais ça ne servira à rien, le mal est déjà fait.
Avatar de drcd drcd - Membre averti http://www.developpez.com
le 21/07/2014 à 13:00
Citation Envoyé par super_navide  Voir le message
Agile encore un terme marketing pour créer des job d'expert qui ne veulent plus développer et qui servent rien.
Pour qu'un projet fonctionne c simple , une spécification claire , une expression de besoins claire , des développeurs avec de expériences , un plan de test bien détaillé (apres automatique ou manuel c une question de coup ) et voilà ça fonctionne...........

Pour qu'un projet informatique il faut avant tout de pas dévaloriser le boulot de concepteur-développeur , et arrété avec les titre de pilote de projet, architecte , chef de projet etc ...
Un projet fonctionne avec de bon concepteur développeur.

Aie aie aie...Efface ce post tout de suite.

Pour que tu dises ça, il faut soit que n'aie jamais travaillé sur un projet soit que tu refusais de t'adapter. Dans les 2 cas, c'est pas bon pour toi.

Je suis assez d'accord avec le contenu de l'article. Je suis dans une équipe qui est passé d'un mode cycle en V à scrum. Ca n'a pas été facile surtout au début car on faisait pile poil ce qu'il ne fallait pas faire et qui est décrit ici. Mais avec le temps on s'est amélioré et maintenant ca marche du tonnerre. Tout le monde développe de facon détendu et il n'y a presque jamais de coup de rush. C'est pas encore le paradis mais la qualité de travail est bien meilleure.
Avatar de Orwel Orwel - Membre du Club http://www.developpez.com
le 21/07/2014 à 13:21
L'article original est intéressant.

Agile practices are important, but it’s the agile principles that make the practices work well and make them sustainable in the long run.

Agile is about people, interactions and culture, not processes, practices and tools

Il est facile d'appliquer une suite d'étape, même pour un débutant. La vraie difficulté est changée la culture de l'entreprise, car agile est avant tout le respect et la valorisation des gens qui collaborent. Difficile d'intégrer cela dans une entreprise très hiérarchisée, où une erreur doit avoir un coupable (dans agile, on ne codanne pas, on apprend).

We all know that documenting software usually ends up not being done because it is seen as a low priority compared to moving on to the next coding assignment. Similarly, some agile teams forego Sprint Retrospectives due to lack of time or perceived lack of value.

calibrer les sprints donc accepter les retards, erreurs, "mauvaise" organisation pendant une certaine période.

Si les principes sont pas saisies, mais en plus on ne respecte pas la méthode

Même si agile est innée en nous, je pense qu'il s'agit d'une terrible erreur de créer une équipe agile sans membre expérimenté sur la méthode choisie. Car tout au long de notre parcours scolaire et professionnel on apprend des méthodes contraires à ces principes.

Une bonne métaphore d'agile qui explique les échecs, est d'imaginer l'équipe (partie cliente du projet intégré), devant courir nue jusqu'à un lac. Il est certain que dans les premiers essaies, tous arriverons à des endroits éloignés et à des instants différents. Gêne poussant les membres a s'éloignés (culture surfaite du vêtement alors que l'on nait nue, ce qui revient au principe innée d'agile), gens à l'aise dans l'activité avançant plus vite en laissant des obstacles dans leur sillage, client ne comprenant pas ce qu'il fait là. Mais au bout de plusieurs essaies, l'équipe courra main dans la main et ils arriveront en même temps, au même endroit.

Donc valorisation de l'ensemble des collaborateurs, ramener la technique à un niveau abordable pour l'ensemble (donc ne pas faire le kéké avec un truc que nous seul connaissons), investissement du client (et non juste une participation passive).
Avatar de 23JFK 23JFK - Membre éclairé http://www.developpez.com
le 21/07/2014 à 14:23
Citation Envoyé par Patriarch24  Voir le message
Mais c'est bien sûr !!! Pourquoi donc personne n'y a pensé ?!

Les méthodes agiles ne sont en aucun cas des méthodes de management... Faut se renseigner un minimum

Le plus difficile dans ces méthodes, c'est effectivement faire changer les mentalités et la manière de travailler, sans aucun doute. La plupart des gens n'y sont certainement pas prêt, et sont déstabilisés. D'expérience, l'obstacle le plus rencontré est le manque de communication entre le client et l'équipe de développement, qui est (juste !) la fondation de ces méthodes.

)

Vous m'excuserez, mais expliquer à des gens comment ils doivent s'organiser pour "mieux" travailler, c'est du management.
Offres d'emploi IT
Développeur fan de scala / spark
Urban Linker - Ile de France - Paris (75011)
Software Development Engineer Mobile
People Centric - Provence Alpes Côte d'Azur - Gémenos (13420)
Analyste développeur junior java (H/F)
Atos - Provence Alpes Côte d'Azur - Aix-en-Provence (13100)

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique Accueil