Discussion :

[Arsene Newman]

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, pour un expert en gestion de projets

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" ?

[23JFK]

Agile... cette chimère management à la peau dure.

[super_navide]

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.

[Invité]

...

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.

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?

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" + ... )

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é!

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.

[Patriarch24]

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.

[Traroth2]

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.

[Saverok]

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

[noirbizarre]

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.

[drcd]

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.

[Orwel]

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).

[23JFK]

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.

[super_navide]

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.

Ca fait 15ans que je bosse et tous les projets qui marche pas c'est souvent du a manque d’expérience des développeurs , il faut la bonne expérience pour réussir un projet.

Et puis un projet n'est pas que sa phase de développement, il y a aussi sa mise en production et pendant des années éventuellement des correctifs et des rattrapage de données...
J'ai fait 6 ans de maintenance et j'ai vu plein de projet bien passer en RE7 et la MOA contente et générer plein de bug en prod et plein de rattrapage de données.

Avec toute mon expérience j'en déduit qu'on peut mettre toute les méthode a la con , si les développeurs n'ont pas assez d’expérience le projet pourra bien se passer , mais au prix d'un coup important de maintenance en production et des coup important pour le faire juste évolué car pas prévu pour tel ou tel fonctionnalité.

Mais cette vision n'est possible que lorsque qu'on a au moins 15 ans d’expérience en dev et pas en management ou pilotage.

Souvent aussi ce qui marche bien c le lotissement , faire un projet de 10 000 fonctionnalité ensuite un plan de test de 100 000 cas de test et mettre le tous en prod c souvent un désastre.
Il faut souvent divisé pour mieux régner donc faire de petit projet.
Il y a aussi une chose qui a faire réussir les projet documenter l'existant,comment faire évoluer un logiciel si on sais pas comment il fonctionne..........

[Invité]

Mais cette vision n'est possible que lorsque qu'on a au moins 15 ans d’expérience en dev et pas en management ou pilotage.

J'ai jamais vu une boite où tous les développeurs ont 15 ans de métier...
Il faudra bien gérer les nouveaux.

Souvent aussi ce qui marche bien c le lotissement , faire un projet de 10 000 fonctionnalité ensuite un plan de test de 100 000 cas de test et mettre le tous en prod c souvent un désastre.
Il faut souvent divisé pour mieux régner donc faire de petit projet.
Il y a aussi une chose qui a faire réussir les projet documenter l'existant,comment faire évoluer un logiciel si on sais pas comment il fonctionne..........

C'est un peu le but des méthodes agiles il me semble.

Merci d'écrire "c'est" au lieu de "c" ça pique les yeux.

[super_navide]

J'ai jamais vu une boite où tous les développeurs ont 15 ans de métier...
Il faudra bien gérer les nouveaux.



C'est un peu le but des méthodes agiles il me semble.

Merci d'écrire "c'est" au lieu de "c" ça pique les yeux.

j'ai pas dit uniquement des développeurs avec 15ans d’expérience mais un mélange entre jeunes et plus vieux
ben c c un condensé de c'est

[Carhiboux]

Les méthodes agiles...

C'est rigolo. Parce que selon le role de la personne, chacun y voit un truc différent.

Quand on est client, on y voit une manière d'améliorer la qualité, et d'éviter l'effet tunnel. Par contre, le client voit rarement que cela va lui demander PLUS de temps au quotidien, et BEAUCOUP plus de travail préalable, là ou dans les projets non agiles, il livre un premier jet de specs fonctionnelles très vagues à j+3 de la date de début de dev, et qu'il l'améliore doucement au fur et à mesure du temps.

Le commercial, bon, lui au moins c'est facile, c'est un bon gros buzzword pour lui, derrière... ben derrière de toutes façons il s'en fout c'est plus son problème!

Le manager de l'équipe de développement, il espère que ça lui apportera moins d'effet tunnel, donc moins de réunions de crises lorsque le client se rendra compte que ce qu'il a écrit dans la spec ne corresponds pas à son besoin réel (oui, c'est lui qui l'a écrit, mais bon, vous comprennez, il fallait pas le comprendre comme ça ni le prendre au pied de la lettre...).

Le chef de projet agile... Lui il y a deux cas : Le premier cas, c'est qu'il a les dents qui rayent le parquet, et qu'il a choisi agile comme il aurait pu choisir n'importe quel autre buzzword pour servir de tremplin à sa carrière. Dans ce cas... il va être bête et méchant, et va appliquer à la lettre le manuel. Sauf que Agile, comme le souligne l'article, c'est au moins autant des concepts que des pratiques figées dans le marbre. Dans le deuxième cas, on ne lui à pas demandé son avis, et il fait ce qu'il peut avec les moyens du bord (pas de plateforme d'intégration continue, résistance des équipes à qui on n'a pas demandé leur avis, manque de réactivité du client, ...).

Pour le développeur agile, je dirais que c'est le même combat que pour le chef de projet, d'un coté ceux qui ont les dents longues, donc qui vont essayer d'utiliser les méthodes agiles pour se faire mousser (au détriment de la qualité du produit final, of course), et ceux sur qui c'est tombé dessus par hasard parce qu'ils étaient dans le mauvais couloir au mauvais moment et à qui on demande de faire de l'agile sans leur donner les billes pour le faire...

[guillaume07]

Agile est simple et facile, trouver ça difficile me parait grotesque

[Drawingrom]

Agile est simple et facile, trouver ça difficile me parait grotesque

Joli.

Sérieusement, c'est les situation de projet qui sont plus ou moins difficiles. Pour les gérer, il n'y a pas de méthode magique, juste des bonnes occasions de vendre des prestations de consulting.

[CodeurPlusPlus]

Concevoir, développer ou maintenir des applications, c'est du travail de précision et de très longue haleine (personne ici ne l'ignore).

C'est du travail d'orfèvre.

Je me demande comment les orfèvres que nous sommes peuvent perdre du temps en discussions aussi superficielles : et l'approche machin-bidule est obsolète ; et telle idée est bonne mais bizarrement personne ne sait bien l'appliquer, et l'objet ça ringardise le procédural, etc.

Alors que nous savons tous que le travail d'une équipe de développement est bien trop complexe pour que sa réussite tienne à de grosses ficelles quelles qu'elles soient.

[jean_kevin_musclor]

La méthode agile c'est pour les gentils garçons qui ne piquent pas une crise d'hystérie de sale merdeux vexé à chaque fois qu'un collègue en sait plus qu'eux.

C'est bien ça fait le tri, c'est pas pour les antisociaux.

[Invité]

La méthode agile c'est pour les gentils garçons qui ne piquent pas une crise d'hystérie de sale merdeux vexé à chaque fois qu'un collègue en sait plus qu'eux.

Je la mets de coté celle là.

C'est bien ça fait le tri, c'est pas pour les antisociaux.

Il y a du vrai