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.

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

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

[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

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

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

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

[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

[Invité]

Tout est dit dans le sous-titre :

« Agile nécessite l’évolution de la manière d’interagir et de raisonner des développeurs. »

En clair, ce ne sont pas les méthodes qui doivent être agiles mais les développeurs.

En 2012, un agiliste toulousain s’interrogeait : « Faut-il encore parler de méthodes agiles ? Pourquoi garder ce terme restrictif alors que l'on devrait tout simplement parler de méthodes professionnelles de développement logiciel ? »

« 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. »

Développer est un art dont les méthodes fixent les règles. Mais il y a la manière d’exercer cet art et la difficulté, c’est de distinguer l’art de la manière. L’agilité n’est pas une méthode qui fixe les règles du développement mais une attitude qui exprime la manière de développer. On parle d’agile attitude. Et ça, ça ne s’enseigne pas, enfin je ne crois pas.

J’ai abordé ce sujet dans la discussion :

« Doit-on soumettre les vétérans à des tests de programmation avant embauche ? ».

Je vais me répéter :

… Certains comportements, sans rapports avec l’informatique sont étonnamment compatibles avec ma démarche de développement, je distingue aujourd’hui l’art et la manière :

L’art est la partie technique, rationnelle qui a ses règles. Ne dit-on pas d’ailleurs que l’on travaille dans les règles de l’art ? C’est le savoir-faire qui s’acquiert par la formation, l’auto-formation, la recherche personnelle, la pratique. Pour un informaticien, c’est la maitrise des langages, des systèmes, des méthodes de développement, etc.

La manière est la partie comportementale. C’est l’attitude qu’enseigne la vie et qui a ses principes. Je parle de « Véloce attitude ».

La véloce attitude est une attitude à trois facettes :

• La hoshin attitude : s’investir totalement et librement

Les thèmes de travail ou « Hoshin » ("direction" - "boussole" en japonais) des task forces sont principalement : le juste-à-temps, l'excellence, le changement, l'innovation, la prise de risques, la compétitivité fondée sur le temps de réaction, l'esprit d'entreprise, la participation.

La hoshin attitude s’exprime dans le cadre d’une stratégie des équipes ad’hoc, l'adhocratie qualifiant toute forme d'organisation qui va à l'encontre de la bureaucratie pour aborder le changement. Elle traverse les frontières et les clivages habituels, coupe à travers les organigrammes, les départements, les fonctions, les profils de poste, la hiérarchie et la tradition. C'est en fait la capacité pour une entreprise à intégrer le changement.

• La poulpe attitude : utiliser son intuition pour prendre les bonnes décisions

La poulpe attitude consiste :

• à susciter les évènements
• à saisir les opportunités
• à exploiter les coïncidences

Adopter la poulpe attitude, c’est savoir sans savoir, autrement dit c’est l’écoute de soi-même, se fier à son intuition pour agir et réagir plus efficacement au quotidien sans réflexions interminables, raisonnements logiques conscients ou schémas compliqués.

Une personne qui ne sait pas s’écouter est condamnée à obéir aux autres, que ce soient ses parents, ses professeurs ou ses employeurs. C’est pourquoi une personne qui n’écoute pas son intuition est une personne qui n’utilise pas sa liberté. Le problème, c’est qu’on n’apprend pas à l’école à s’écouter soi-même.

L’intuition, c’est se rebrancher sur son moi authentique et sa petite lumière interne. Ce n’est pas une science exacte, c’est une sensibilité artistique qu’on développe, comme le fait d’être mélomane ou cinéphile. Ne pas réfléchir intellectuellement mais instinctivement. Le cerveau aime qu’on le sollicite dans la précipitation, il y a un plaisir beaucoup plus important à écouter son intuition que le plaisir à écouter sa logique analytique.

• La positive attitude : vivre en mode chance et savoir lire la vie

Notre spécialité, pour la plupart d’entre nous serait plutôt la concentration, c’est-à-dire la capacité à nous focaliser sur une idée, un travail ou une action, en faisant justement abstraction de tout ce qui nous entoure et pourrait nous distraire de la tâche entreprise. C’est en tout cas comme cela que nous avons été éduqués pendant nos années de formation, que ce soit à l’école ou à l’université. Et c’est encore souvent ce qui est attendu de nous dans notre vie professionnelle.

Vivre en mode chance, c’est regarder différemment sa propre façon d’être dans le monde, prendre les décisions adéquates, décider de faire ou ne pas faire les choses, anticiper la situation à venir, entrer ou non en relation avec les autres, être plus attentif que d’autres face à l’apparition des occasions favorables, fussent-elles issues du seul hasard ; saisir les occasions et rebondir sur les incidents de parcours…

La chance est bien évidemment totalement irrationnelle et choque à bon droit notre sens commun d’héritiers de la modernité et de l’esprit scientifique. Hasards et coïncidences sont en fait des rencontres accidentelles entre des évènements qui ressemblent furieusement à des rencontres intentionnelles.

Cette chance, comprise comme la capacité à tirer parti des circonstances, est aussi et avant tout une ressource. Sans doute moins maitrisable que d’autres, souvent plus impalpable, mais une ressource quand même, bien réelle et dotée d’une puissance extraordinaire pour qui sait en décrypter les promesses, en respecter les principes et les règles.

Bibliographie :

• LA STRATÉGIE DES ÉQUIPES ad hoc (R. H. Waterman - 1990)
• LA POULPE ATTITUDE (Christophe Haag - 2011)
• ÉLOGE DE LA CHANCE ou l’art de prendre sa vie en main (Philippe Gabilliet - 2012)

« La partie la plus difficile avec agile est la transformation de la perception des principes autour d’agile. »

Les méthodes se labélisent « agiles » parce qu’elles ont introduit dans leurs processus des règles inspirées des principes agiles. La dualité « art-manière » correspond en quelque sorte à la dualité « hard-soft ». Les méthodes dites agiles ont transcrit du soft en hard.

Ainsi, les principes :

• « Notre première priorité est de satisfaire le client en livrant tôt et régulièrement des logiciels utiles »
• « Livrer fréquemment une application fonctionnelle, toutes les deux semaines à deux mois, avec une tendance pour la période la plus courte »

… se sont-ils mués en sprints.

Et les principes :

• « Les gens de l'art et les développeurs doivent collaborer quotidiennement au projet »
• « La méthode la plus efficace pour transmettre l'information est une conversation en face à face »

… se sont-ils mués en scénarios.

Le développeur extrait de ces scénarios les règles de gestion de la problématique à informatiser qu’il interprète avec sa formation, sa technicité, sa rationalité, sa culture d’informaticien. Et c’est ainsi qu’il réinvente le métier de l’utilisateur.

A ce sujet, il est intéressant de citer certains arguments pertinents auxquels j’adhère sans réserve, de la discussion :

« Quelles idées avez-vous de l'utilisateur final lors du développement d'une application ? »

J’en proposerais bien une synthèse dans un prochain post car je trouve qu’il y a de l’esprit agile dans cette argumentation qui a sa place dans cette discussion.

Aparté : Les discussions ont un caractère « consommable » et je trouve dommage de ne pas les exploiter en créant des sortes de synthèses, de cahiers ou d’études dans une rubrique spécifique du site.

L’informaticien ne peut s’empêcher de rationaliser, d’identifier, de classer, de règlementer, d’architecturer, de standardiser, de sécuriser, de chercher des recettes, de se certifier.

« Cycle en V » ou « agiles », ces méthodes sont toutes des méthodes de type « Top-Down », non ? Pour ma part, je n’ai pratiqué professionnellement que du « Bottom-up » mélangé à du RAD, méthode que les développeurs de ma génération pratiquaient sans le savoir.

Aujourd’hui, les méthodes se labellisent « agiles » comme elles se labellisaient « RAD » au siècle dernier.

A propos de RAD, Je propose d’en rappeler les principes. Jean-Pierre Vickoff s’y réfère et les évoque souvent dans son ouvrage mais ne les cite pas explicitement à la façon du Manifeste agile. Une liste de ces principes en annexe aurait été la bienvenue. J’ai extrait de son texte les concepts forts et récurrents qui peuvent faire office de principes et ça donne ce que je vais poster après ce post.

Évidemment, il est tentant de mettre en parallèle les principes RAD et agiles.

Il est même tentant de mettre en parallèle bien d’autres principes issus de mondes très différents (évoqués plus haut) comme le monde de l’entreprise (La hoshin attitude), le monde de la psychologie (La poulpe attitude et La positive attitude), le monde de la philosophie (citations), le monde de la médecine (sophrologie), le monde du sport (challenges)… et mon propre monde de développeur (méthode APL-AML). D’autres développeurs trouvent des réponses à leurs interrogations dans d’autres mondes comme le théâtre par exemple. Il appartient à chacun de chercher sa vérité. Pour ma part, j’ai répondu à peu près à toutes mes interrogations.

A tout de suite pour les principes RAD…

Ce n’est pas vraiment de l’agile, mes bêtises mais si ça vous intéresse, je peux vous proposer quelques autres listes de principes.

[Invité]

Référence :

Le RAD de James Martin (Rapid Application Development - 1991),
actualisé par Jean-Pierre Vickoff (RAD - Développement Rapide d'Applications - 1996)

• « La méthode RAD a pour objectif principal d'améliorer la qualité des développements, tout en réduisant les délais de production et en facilitant la maîtrise des coûts. Elle associe pleinement les utilisateurs dans une recherche de consensus et d'efficacité : il faut faire vite et bien. »
  
  
• « Rien n'oblige à tout réaliser d'un seul tenant. L'amélioration continue et incrémentale est le principe fondamental du RAD, en totale opposition avec les méthodes classiques qui se caractérisent par une approche monolithique des problèmes. »
  
  
• « Les concepts de qualité permanente et de livraison permanente sont rendu possibles par la réalisation dès le début du prototypage d'une application techniquement fiable que l'on incrémente de fonctionnalités tout en préservant cette fiabilité. »
  
  
• « L'informatique décentralisée judicieusement pratiquée, oblige les personnes à travailler plus "proprement" et apporte à tous un surcroît de productivité. Seule voie vers la qualité totale, elle nécessitera de disposer presque instantanément d'applications jetables. »
  
  
• « L’ambition étant de satisfaire totalement les utilisateurs, il faut les impliquer totalement. »
  
  
• « L'utilisateur impose la dynamique applicative et valide la conception. L'informaticien assure la réalisation et intègre la dimension technologique. »
  
  
• « La vraie clé de la productivité est le développeur de haut niveau qui sait intégrer la conception détaillée et la réalisation. »
  
  
• « La spécification détaillée et la réalisation intègrent les fonctions de conception, de développement et de validation dans un processus permanent de collaboration avec l'utilisateur. L'utilisateur s'affirme comme le vrai maître de son application et, par sa participation active, il s'en approprie la réalisation. Le RAD et le prototypage permettent de réaliser en concevant, tout en testant ce qu'on réalise. Le résultat garantit ce que l'on peut qualifier de "Really Approved Design" : une conception réellement approuvée par les utilisateurs. »
  
  
• « La rigueur du passé, sécurisante mais frein à la liberté d'expression, fait place autant à la productivité maximale, avec pour bornes le budget et le temps, qu'à la satisfaction réelle de l'utilisateur en termes de fonctionnalité, de délais et d'ergonomie. »
  
  
• « Au transfert d'informations vertical se substitue une coordination transversale. »
  
  
• « La modélisation des données reste classique et s'appuie sur le modèle entité-relation. Il est néanmoins possible et souvent souhaitable de dé-normaliser le modèle. La simplification de développement ou le confort d'exploitation obtenu justifient largement la perte de pureté intellectuelle. »
  
  
• « Après avoir assimilé le complexe et maîtrisé le détail, la simplification à l'extrême de l'efficacité devient évidente. »
  
  
• « Une charte graphique doit avoir été validée, des normes de programmation employées, un modèle de transaction généralisé à tous les modules, et le cadre d'une méta-application aura si possible été respecté. »
  
  
• « Il faut faire disparaître la notion de dossier de programmation, tout en améliorant réellement les conditions de maintenance. La meilleure documentation est une aide contextuelle. »
  
  
• « Afin d'être efficace dans un contexte de développement, une normalisation sémantique et syntaxique réduit le vocabulaire en adoptant des mots clés courts, mais significatifs et des abréviations significatives et uniques. »

________________________________________