Accueil > Attitudes et bonne valeur, Expérience utilisateur, Gestion d'entreprises, Méthodologie Agile, xp > Et si les méthodologies Agiles étaient une arnaque !

Et si les méthodologies Agiles étaient une arnaque !

1. L’introduction

L’autre jour en faisant de la veille, je suis tombé sur la question « Les méthodes agiles sont-elles une arnaque ? »  Sur un des forums du site de http://www.developpez.com. J’ai aimé l’idée et dans les prochaines lignes. Je vais poser, avec vous, la réflexion pourquoi ou comment ces méthodologies Agiles ne sont pas une arnaque. Mais, qu’elle pourrait l’être ou semble l’être avec une mauvaise utilisation.

Je sais, je vous préviens ! Je vais prôner pour ma paroisse, après tout, c’est normal. J’aide et j’accompagne les  organisations dans leur bonne utilisation des mêmes méthodologies Agiles. Cependant, à l’opposée, je suis aussi quelqu’un de pragmatique. En conséquence, j’essaie toujours de regarder les deux côtés de la médaille. Tant le bon que le mauvais.

Mon objectif est simple. Je veux vous aider à apporter quelque lumières pour mieux les comprendre ces méthodologies Agiles et justement de vous éviter certains pièges biens emballés

2. D’abord qu’est que c’est ça les méthodologies Agiles

2.1.  Le manifeste

D’abord, à  la base de méthodologie agile, c’est un manifeste de principes et de valeurs qui doivent découler l’ensemble des méthodologies. Je vous réfère à ce lien qui explique correctement ce qu’est le Manifeste Agile.

2.2.  Pourquoi on dit, « Les méthodes agiles » au pluriel.

On appelle les méthodologies Agiles toujours au pluriel. Car, il existe plusieurs méthodes qui découlent des valeurs. C’est quelque part le contrant qui se sont donné plusieurs signataires de ce manifeste  et qui étaient aussi les auteurs de plusieurs de ce méthode dite « Agiles »

2.3.  Les méthodes qui en découlent de ce manifeste.

Il existe plusieurs méthodes, il suffit d’effectuer petite recherche sur Internet, avec les noms des premiers signataires. Vous trouverez rapidement des noms de méthodes comme Scrum, Extrem Programming (XP), Lean Software, etc.. !

3. Ça vient d’où tout ça !

3.1.  Un peu d’histoire.. !

Comme nous le raconte cette petite histoire (en anglais) : http://agilemanifesto.org/history.html, c’est durant une fin de semaine de ski .. ! (Oui, les programmeurs font aussi parfois du sport)  que 17 personnes (expert en informatique et en méthodologies) ont posé la réflexion sur comment on pourrait résoudre les problèmes fréquents en informatique. Surtout en développement de logiciels.

Donc, parfois, sortir du quotidien, on peut arriver à faire de belles réflexions.

Ils ne sont pas arrivés sur une seule méthode. Mais sur des valeurs et des principes nécessaires pour qu’une méthode puisse aider l’équipe de développement à produire un logiciel de qualités et surtout qui correspond aux vrais besoins de l’utilisateur payeur.

Comme beaucoup d’entre nous, ces experts avaient vécu plusieurs projets qui n’avaient pas atteint l’un ou l’autre de ces objectifs. Ils voulaient avoir des  outils pour y arriver. Personne d’entre nous ne veut qu’après des mois, voir des années de labeurs soit travail sont mis sur une tablette. Nous faisons de l’informatique pour voir le « Wow » dans les yeux des utilisateurs finaux.

3.2.  Développer un logiciel, c’est notre travail

Pour un programmeur, faire le développement d’un logiciel, c’est son pain quotidien.  C’est donc normal pour lui d’identifier certain héritant ou choses qui ne fonctionnent pas. C’est aussi que plusieurs grands passeurs, surtout provenant du monde l’ingénierie (ceux qui bâtissent des ponts, des grands bâtiments) ont tous voulu créer une méthode qui serait idéalement infaillible pour arriver à livrer un projet en informatique en temps et argent. La fameuse équation!

Après tout, c’est le but de tout projet, informatique ou pas ..! Mais, avec l’expérience, on s’est vite aperçu que certains approchent de nos amis constructeurs de ponts. Ne fonctionnaient pas toujours dans notre contexte.

La science de l’ingénierie civile est une science qui date des lunes, les Romains construisaient des points! Mais, l’informatique, c’est encore tou jeune. Et parfois, certaines comparaisons. Ne fonctionne pas !

Donc, c’était tout à fait normal que des gens qui c’est leur métier de construire des logiciels sont mis à réfléchir sur l’art et le comment on pourrait le faire justement pour améliorer ce qui à nos yeux ne fonctionnait pas.

3.3.  La quête de l’impossible.

Car, pour la plupart (on le  souhaite tous), nous voulons construire un logiciel qui sera utilisé par le plus grand nombre possible d’utilisateurs. Mais, pour ce faire, il doit correspondre  aux besoins du plus grand nombre possible d’utilisateurs.

Mais, comment arriver à faire cette quête de l’impossible. Plusieurs y avaient réfléchi avant nous. Néanmoins, ils l’ont fait en apportant des processus parfois trop complexes, et qui parfois font dévirer de notre objectif simple de livrer un logiciel fonction et qui correspond aux besoins du client.

Les programmeurs, en général, on aime les choses simples et efficaces… À la limite, on est un peu tartinait paresseux. Donc, les processus complexes et compliqués. Ce n’est pas pour nous. Nous voulons faire les choses simplement et efficacement. Et pourquoi pas, dans la joie et le bonheur ..!

4. Si ça serait une vraie arnaque

4.1.  Définition

J’aime bien la définition (surtout la note) de l’Office québécois de la langue française d’une arnaque :

Définition

Technique de violation de la sécurité informatique, qui consiste à amener une entité autorisée à se livrer, à son insu, à un acte préjudiciable pour elle-même ou pour son organisation, en lui laissant croire, à tort, qu’elle est en communication avec le système informatique.

Notes

La mystification vise, le plus souvent, à obtenir de l’information pour laquelle aucun accès n’a été accordé, en amenant l’utilisateur légitime détenant cet accès privilégié à fournir son mot de passe.

La mystification vise, le plus souvent, à obtenir de l’information pour laquelle aucun accès n’a été accordé, en amenant l’utilisateur légitime détenant cet accès privilégié à fournir son mot de passe.

4.2.  Ramenons-nous dans un contexte de développement logiciel.

Une arnaque serait un processus ou procédé qui permettrait de charger inutilement du temps où des efforts à un client pour en fin de compte pour lui livrent un logiciel complètement inutile ou encore qui ne correspond pas du tout à son besoin.

Donc, un travail qui irait complètement à l’inverse du principe 1 des méthodologies agiles :

« Notre plus haute priorité est de satisfaire le client
en livrant rapidement et régulièrement des fonctionnalités
à grande valeur ajoutée. »

Ou encore plus simple, faire des travaux qui n’aident en rien à l’objectif premier  qui est de produire un logiciel de qualités. Exemple ne pas faire de la documentation. Car en Agile on n’en fait pas. Pourtant, c’est faux, j’ai d’ailleurs répondu à cette question dans cet article « On documente, quoi, quand et comment ? »

5. Cette invention vient des programmeurs, mais… !

5.1.  Tout le monde le sait

Les programmeurs on vient tous de mars ou a peut-être tout près. J’en ai vu aussi quelques Vulcains.  C’est magique voir bizarre notre travail. On veut faire penser une machine qui ne connait que zéro et des uns. Et qui ne sait que faire des additions, soustractions et multiplications.

C’est fou, je le sais. Mais, nous avons choisi de travailler pour vous aider à bien utiliser ce petit monstre en vous créant d’outils pour mieux interagir avec lui. Donc, c’est normal que parfois, traduite de 0 et 1 en français c’est aussi un travail fou. C’est donc normal parfois d’avoir de la difficulté d’arriver aux buts. Donc, parfois entre 2 lignes de codes, on réfléchit aussi à trouver la meilleure manière de faire les choses.

5.2.  C’est vrai aussi !

L’ensemble pour ne pas dire tous, les cosignataires du manifeste et aussi auteurs de méthodologies de développement, ont été programmeur expert sur des grands projets informatiques. Et de manière sur avant d’autant certain, on mise en œuvre à plus d’une reprise aussi les approches qu’ils préconisent. Ce n’est pas que de belles théories, c’est aussi des années de pratiques en seins de grandes organisations.

Avoir une méthode  pour un projet de 2 personnes d’une durée d’une semaine. Ça ne veut rien dire. Mais, en avoir une qui a fait ses preuves sur des projets majeurs avec de grandes équipes.

5.3.  Ils ont signé le manifeste, mais leurs méthodes existaient avant.

L’ensemble de ces programmeurs était de plusieurs grandes méthodes qui existaient de plusieurs années. À titre d’exemple, la fameuse méthode Scrum, les premiers travaux qui ont commencé dès 1991.

Je vous ne ferais pas l’historique de toutes les méthodes des signataires du manifeste.  Mais, disons simplement qu’ils n’avaient pas écrit la fin de semaine d’avant.

6. Pourquoi les gens pensent que c’est une arnaque

Lorsqu’on n’est pas un spécialiste de l’informatique. Certains travaux nécessaires à la production d’un logiciel, sont d’une nature très complexe voir impossible à comprendre pour les non initier. Ouvrir un fichier de code, ce n’est pas à la porter de tout le monde.

C’est pour cela que les processus classiques ont voulu offrir des outils de communications ..! Parfois, tellement contraignant qu’il en devenait de carcan plutôt que la facilité.

6.1.  Les programmeurs sont leurs coins.

C’est vrai ! Mais, si vous voulez faire quelque chose d’important, voire parfois complexe. Vous allez avoir besoin de toute votre concentration. En étant dans notre coin, c’est en plein ce que vous recherchons d’avoir notre pleine concentration.

C’est aussi un travail qui se fait en individuelle qu’en équipe. Donc, parfois, être ensemble, c’est utile.

6.2.  L’absence de documentation. est-ce vraiment « VRAI »

J’aurais aimé qu’on me donne 100$ à chaque fois qu’une personne m’affirmait qu’en Agile on ne fait pas de documentation, je serais surement riche ..! Mais, j’ai toujours répondu, pensez-vous vraiment que quelque part sur terre, on peut faire un projet d’informatique d’entreprise sans faire une ligne de documentation ?

C’est vrai que le manifeste dit « Des logiciels opérationnels plus qu’une documentation exhaustive ». Cependant, il ne dit pas, « Pas de documentation ». Il faut parfois savoir lire au-delà des mots. Car, en Agile, on fait de la documentation lorsque c’est nécessaire et que cela nous aide à atteindre l’objectif de livrer le meilleur logiciel pour notre client.

6.3.  Des mauvaises pratiques qui amènent des arguments pour l’arnaque

6.3.1.     De faux praticiens Agiles qui affirment.  « Pas de documentation.. »

Malheureusement, l’une de ces pires mauvaises pratiques, c’est justement d’affirmer qu’on ne fait pas de documentation. J’en ai rencontré malheureusement beaucoup trop, des informaticiens, un peu mal intentionnés, qui se servaient des « Approches Agiles » pour esquiver certains travaux, dont la documentation et le suivi, pour pouvoir livrer le projet comme eux voulaient le faire.

Dire qu’ils sont praticiens agiles, c’est gens là, s’en est presque un crime. Car avec les méthodologies Agiles, on ne cherche pas à dire ce qu’il ne faut pas faire. Mais, ce qu’il serait recommandé de faire. On cherche le meilleur moyen d’y arriver.

En conséquence, faire de la documentation, de la bonne documentation à temps et avec le format ou médias, là c’est de respecter les principes agiles.

6.3.2.     Ils sont enfermés dans un coin.

Oui, l’équipe doit être dédiée au travail, et même parfois, être regroupée dans un même secteur. Mais, ce n’est surtout pas un vase clos. Ils doivent avoir des outils pour communiquer leur avancement comme le product backulog et le product burndown.

De plus, vous avez une personne, « product Owner » qui doit être aussi votre représentant dans cette belle équipe. Son rôle aussi est de communiquer avec vous, de vous mettre en relation avec ce qui se fait.

Et n’oubliez pas, construire un logiciel, ça demande un grand nombre d’heures de travail. Donc, s’ils sont acharnés à leur travail. Ils pourront y arriver plus facilement.

7. Le but dans tout ça

Le but se résume facilement en citant le premier principe du manifeste : « Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée. »

7.1.  D’abord et avant tout mieux servir vous le client !

Oui, nous sommes de passionner, parfois même des bidouilleurs. Mais, détrompez-vous, on veut vous servir au mieux. C’est notre but ultime. Parfois, certaines autres méthodes oubliaient ce dernier détail.

Parfois, servir un client, ce n’est pas toujours facile. Nous parlons souvent 2 langages qui ne se ressemblent pas.  Donc, c’est pourquoi il faut se ramener aux valeurs de bases de la communication et surtout se rappeler pourquoi qu’il faut prendre le temps de communiquer.

C’est si facile de partir dans les grandes élocutions, de grands écrits.. Si tout ce qu’on fait ne vous aide pas à mieux vous servir. Tout ça ne sert à rien. C’est vous qui payez en bout de course. Vous devez en avoir pour argent.

Toutefois, cette quête de bons services ne sert à rien, si tout le monde, vous aussi, vous ne faites pas d’effort dans ce processus de communication pour nous aider aussi à bien vous servir.

7.2.  Deuxième, mettre les meilleures pratiques logicielles à votre service

Ils existent plus d’une pratique logicielle. Mais, parfois, il faut savoir utiliser la bonne et surtout ne pas avoir de changer en cours de route si on se rencontre qu’elles ne convient pas.

De plus,  d’un autre côté en utilisant la ou les meilleures pratiques vont nous aider à vous construire le meilleur logiciel.

C’est aussi simple que choisir de prendre un tournevis pour enlever une vis. Au lieu du marteau. On y arrivé avec le marteau. Mais, avec certains dommages.

7.3.  Et bien sûr vous livrez le meilleur logiciel pour répondre à votre besoin

C’est promis on va faire les efforts pour répondre à votre besoin. Mais, en échange vous devez-nous-l’exprimé au mieux possible. C’est donc une responsabilité partagée avec vous aussi.à

8. En terminant, l’arnaque ?

8.1.  Oui, et si les programmeurs se servent de ce chapeau pour ne pas respecter les règles de l’art

Dans le meilleur des mondes, il y a aussi des gens qui veulent profiter du beurre, de l’argent du beurre et le sourire de la fermière. C’est triste, c’est aussi la vie.

Donc, ce n’est pas parce que vos ressources ou vos consultants utilisent les méthodologies agiles. Que vous devez fermer complètement les yeux. C’est aussi votre devoir.

8.2.  Oui, et si vous ne vous impliquer pas dans le projet !

C’est votre logiciel, c’est pour vous qu’on nous allons le construire. C’est donc normal que vous impliquer selon vos capacités.

Si vous décidez de donner un chèque en blanc, je suis sûr que vous en aurez pour votre argent.. Ironie!

8.3.  Oui, et si vous engagé n’importe qui pour faire n’importe quoi !

Mon père m’a dit tant qu’il a vécu, chacun son métier, et les vaches seront bien gardés. C’est la même chose en informatique. Il faut engager les bonnes personnes pour faire le bon travail.  Ce n’est pas vrai qu’un informaticien peut tout faire. La plupart d’entre nous sont spécialistes.

C’est bête de vouloir prendre un mécanicien automobile pour lui faire réparer un moteur d’une machine dans une usine. Il pourra peut-être y arriver. Mais, si vous avez engagé un mécanicien de machine fixe pour réparer votre machine fixe. Le travail en saura d’autant meilleur.

C’est exactement la même chose en développement logiciel.

8.4.  Mais surtout, ce n’est pas pour tout le monde et tous les projets !

Les méthodologies agiles fonctionnent pour beaucoup de projets et d’organisations. Mais, ce n’est pas fait pour tout le monde.

Ça va vous demander une certaine ouverture d’esprit, une implication que voudrez être prêt faire. Voir changer complètement vos processus et encore plus.

Donc, si vous n’êtes pas prêts. Prenez donc 2 secondes pour y réfléchir.

D’autant, si vos méthodes fonctionnent bien dans votre organisation. Vous n’en avez peut-être pas besoin. Parfois, le super marteau pneumatique et automatique pour clouer des super clous. C’est peut-être inutile dans une usine qui fabrique des cabanes oiseaux donc la productivité est pleinement efficace.

9. En conclusion

Par fois, la meilleure pratique avec les meilleures intentions du monde dans de mauvaises mains. Donne parfois n’importe quand.  Soyez avertis. Les méthodes agiles entre de mauvaises mains peuvent devenir une arnaque, c’est sûr!

Mais, bien utilise et comprise, par vous et vos équipes de développement, elles pourront surement vous aider à atteindre  le fameux objectif de livrer le meilleur logiciel en temps, en argent et surtout en respect de vos besoins.

L’arnaque, je ne pense pas si c’est utilisé dans de bonnes conditions.

  1. Aucun commentaire pour l’instant.
  1. No trackbacks yet.

Répondre

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google

Vous commentez à l'aide de votre compte Google. Déconnexion /  Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s

%d blogueurs aiment cette page :