Discussion :

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

________________________________________

[souviron34]

Moi aussi je vais me répéter

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

Ben relisez le Manifeste....

J'ai jamais vu une boite où tous les développeurs ont 15 ans de métier...

Non, mais, ce que je me tue à dire, c'est que, quand on lit le Manifeste, et que comme moi on a pratiqué comme les auteurs du Manifeste, c'est PARCE QUE on a de l'expérience....


Le fond du Manifste es que c'est à utiliser (ou à diriger) par des gens expérimentés....

Et que c'est absolument tout SAUF une méthodologie.... Que ce soit SCRUM, XP, ou n'importe quelle méthodologie qui se décrit comme "Agile" est contraire à l'esprit du Manifeste....

L'agilité est effectivement un état d'esprit, une manière de gérer les rapports humains, et un projet, au "feeling", pas comme on veut le faire croire en suivant des "règles", c'est tout le fond du Manifeste....

Sauf que pour que ça ne soit pas le bordel, ça prend des gens qui savent de quoi ils parlent (qui possèdent parfaitement un cycle en V traditionnel,et en plus qui ont une vue "architecture" autant que programmeur), ET qui ont une excellente qualité de rapport humain...


Il est absolument évident pour un vieux comme moi que TOUTE équipe qui suit "aveuglément" une "norme", quelle qu'elle soit, va dans le mur... et que il faut que les postes-clés soient remplis par des gens expérimentés...

Mais, c'est évidemment pas ni ce qu'enseignent les facs, ni ce qui est pratiqué, car on s'en est servi d'un buzz-word (regardez les carrières des auteurs du Manifeste au moment où ils l'ont écrit et vous verrez que ce sont des gens ayant déjà fait de gros projets en V)... On m'a déjà dit sur ce forum que j'étais "élitiste" en disant ça.. Mais comme le dit CodeurPlusPlus plus bas, un orfèvre c'est pas le mec qui va acheter 3 perles au marché et fait un collier dans sa salle à manger....

Tout le sens du Manifeste est simplement de prôner une approche artisanale, faite d'un regroupement d'experts.... C'est bien évidemment tout le contraire de ce qu'on fait, dans l'enseignement comme dans la pratique.. Pourquoi alors s'étonner des échecs ??? Ils sont totalement prévisibles, et "inclus" dans le fait de se réclamer d'une approche en lui attribuant des valeurs de méthodologies...

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.

[Saverok]

@souviron34
Je suis parfaitement d'accord avec toi sur le principe (tout comme avec CodeurPlusPlus)
Par contre, tu décris un monde parfait qui n'est pas la réalité de 99,9% des projets

Les développeurs expérimentés sont rares et coûtent cher (c'est parfaitement normal, je ne remets pas ça en cause, l’expérience ça se paye) et tous les projets n'ont pas le budget et la criticité suffisante pour se composer exclusivement d'une équipe de cadors
En plus des développeurs, l'implication du client est primordiale et cela implique un niveau de maturité IT que très peu de clients possèdent

Doit-on réserver l'agile uniquement aux projets coûteux, composés uniquement de dev aguerris le tout avec des clients matures dans l'IT ?
C'est bien beau d'avoir des principes mais s'ils ne peuvent jamais être appliqués...

Surtout que l'Agile est particulièrement bien adapté aux projets innovants où on ne sait pas exactement comment il sera accueilli par les utilisateurs.
Autrement dit, même si le projet est super bien développé, il est possible que ce soit un flop car il ne rencontre pas de succès public
En gros, ce sont des projets à risques et si en plus, on y ajoute un risque budgétaire...

Il faut adapter le Manifeste.
Il faut l'assouplir et lui donner un cadre au travers d'une méthodologie.
Une méthodologie donne un cadre essentiel pour les développeurs débutants : s'ils sont trop libre, ils sont perdus et paniquent par manque de confiance et d'organisation.
De même pour le client.
Les méthodologies qui s'inspirent du Manifeste permettent de rendre l'Agile accessibles.
Oui, ce n'est pas de l'Agile pure mais cela permet d'assouplir un peu la rigidité du cycle en V.
Je pense qu'il faut plus voir ces méthodes comme des étapes intermédiaires mais nécessaires à l'acquisition de l'Agile.
On ne peut pas passer du cycle V au Manifeste d'un bond. Il faut y mettre un escalier.


[HS]
Je vais sans doute choquer certaines personnes, mais je ne vois pas le dev comme un art.
Ca reste de la technique.
Certes de haut niveau et qui demande beaucoup d'analyse et d’abstraction mais cela n'est en rien comparable à la sculpture, la musique, la peinture, l'orfèvrerie, etc.
Le dev pour le dev ne sert à rien. Ca ne se suffit pas à lui même contrairement aux arts ci-dessus.
Ca peut se comparer à l'architecture : le bâtiment peut être beau et original mais il doit avoir une utilité et respecter tout un tas de contraintes
C'est de l'ingénierie, pas de l'art et la différence est de taille
Nous devons également rendre notre travail accessible et ne pas réserver cela à une "élite"
Les décideurs doivent comprendre ce que l'on fait et ça ne doit plus être une boîte noire
Autrement dit, être de bons communicants et de bons pédagogue (un projet a besoin de dev expérimentés mais aussi de "jeunes" qui vont prendre le relais et qui doivent être formés. Car un dev senior a mieux à faire que de la TMA)
Autrement dit, un projet réalisé avec 100% de développeurs seniors est également un projet voué à l'échec s'il n'y a personne pour le maintenir et le faire évoluer.
[/HS]

[Invité]

Je ne vois pas le développement comme un art... C'est de l'ingénierie, pas de l'art.

Lorsque je parle d’art, il ne s’agit pas bien sûr de l’art au sens artistique mais au sens des usages en vigueur dans un corps de métier.

Travailler dans les règles de l'art, se dit d'un travail ou d'une action que l’on accomplie conformément aux usages en vigueur, de la meilleure manière possible.