Macroscope versus Agiles, combat à finir

Pour beaucoup de gens, dont les puristes des 2 côtés, affirme haut et fort que ces 2 méthodologies s’opposent.

Mais, est-ce vraiment le cas ?

D’abord, posons un regard sur Macroscope de DMR.

Voici le texte d’introduction trouvé le site de DMR. http://tinyurl.com/Macrosope

« Grâce à ses méthodes, processus et outils, Macroscope aide les entreprises à planifier, à mettre en œuvre et à gérer leur transformation organisationnelle par des initiatives clés :

• planification stratégique
• architecture de l'entreprise et de ses technologies de l'information
• développement, déploiement et maintenance de systèmes d'information et d'autres solutions technologiques
• gestion de projet
• gestion de la valeur et de la réalisation des bénéfices

À la manière d'une feuille de route, Macroscope guide les acteurs dans la réalisation de leurs activités, et ce, à toutes les étapes d'un changement organisationnel. »

Regardons de l’autre côté le manifeste agile : http://tinyurl.com/AgileManifesto

• Les individus et les interactions doivent primer sur les processus et les outils
• Le développement logiciel doit primer sur la documentation exhaustive
• La collaboration avec le client doit primer sur la négociation contractuelle
• L’ouverture au changement doit primer sur le suivi d’un plan rigide

Allez affirmer que Macroscope implémente les méthodologies agiles. Quand même, affirmer ceci serait une stupidité.

À la lumière de ces 2 courts textes, je crois que me permet par contre dire qu’il ne s’oppose pas. Macroscope est une méthodologie qui décrit et définit les processus qu’on devrait faire pour le changement organisationnel, y compris ceux qui touchent le développement d’applications. Pour se faire, il fournit une série de gabarits qui permet de documenter les processus de développement logiciels. Beaucoup d’excellents exemples de référence comme base pour les construire.

Vous pensez sans que j’aille citer le 2e principe, celui de la documentation exhaustive pour m’attaquer de front à Macroscope pour la tuer. Eh bien non, détromper vous trompez, c’est tout le contraire.

Oui, je m’en sers de ce principe. Mais, je ne me s’en pas partir en guerre rangée contre DMR et sa méthodologie. Je reconnais certaines applications de son approche de gestion et surtout quand les gens font de la sur documente ce n’est pas très agile.

Ce n’est pas une grande nouvelle. Mais, je pense qu’on devait réfléchir le problème différemment. Tout le monde qui me connaisse, et encore plus, ceux qui ont lu mes articles précédents savent que je prône la documentation, lorsque nécessaire bien sûr.

Il faut documenter ce qui doit être documenté. C’est ce que dit ce principe. Et de l’autre coté, Macroscope nous explique comment le faire cette documentation, comment documenter les différentes choses avec l’aide de ses gabarits

Donc, si nous voulons être agiles tout en utilisant Macroscope. C’est possible. Il suffit de gérer le projet en utilisant une approche agile. Et pourquoi pas SCRUM. SCRUM était une méthode du coté agile aussi structurée et structurante. Elle est très rassurante pour les clients.

Et utilisez Macroscope pour documenter les processus. Je travaille dans le marché de Québec, essentiellement gouvernementale et grosse compagnie d’assurances, pour savoir qu’elles sont habituées de lire ces documents.

Ce n’est pas un vrai passage à agile. Mais, une belle transition qui pourra aider à mieux faire l’informatique. Et surtout d’aider à démocratiser l’utilisation des méthodologies agiles dans notre belle région de Québec.

S.V.P. par contre, ARRÊTEZ de sur documenter et de faire du copier-coller de chose qui est déjà documentée. Combien de fois, j’ai vu qu’on a répété le texte, parfois écrit différemment, pour expliquer la même chose dans une même série de documents.

Il n’est pas nécessaire de réécrire un algorithme de validation générique dans tous les dossiers fonctionnels qui l’utilise. Documentez-la dans un seul document et fais-y référence, dans les autres.

Un document utilisant des références aurait du faire de 20-25 pages, mais parce qu’on n’avait pas recopié le texte. Il pourrait en contenir plus de 100 pages sinon. Qui aime lire des documents de 100 pages. Pas moi en tout cas.

Et en plus, pensons eu un peu à l’environnement.. ! Utilisons une documentation électronique, wiki, blogue et compagnie.

En utilisant, les bons côtés de chacune de ces méthodologies, nous serons agiles dans notre gestion de projets.

Et si vous croyez que cela ne peut pas fonctionner. Oui, j’en suis sur ça fonctionne. C’est d’ailleurs la technique, j’ai suggéré à une amie, une spécialiste Macroscope et ancienne membre de l’équipe de rédaction de Québec. Car, elle voulait passer à agile, mais sans pour autant délaisser ses bases.

A ce que je sais et selon que j’ai discuté avec elle, la dernière fois qu’on s’est vue. Elle l’a appliqué avec succès dans un de ses mandats dans un ministère.
Être agile, ce n’est pas tout changé, c’est aussi savoir manier l’ancien avec le nouveau. C’est de réfléchir le problème, pour trouver ou retrouver des solutions.

Et ceux, qui ne me croient pas .. Communiquer avec moi, on le fera ensemble, cette implémentation d’Agile et Macroscope dans votre organisation. generationagile@gmail.com

123 Go je me lance en agile.. !

Un nouveau courant d’idées méthodologiques qui commence à émerger, c’est bien les méthodologies agiles. C’est bien beau, mais par où commencer! Voici notre réponse à cette question importante que nous allons essayer de vous donner des pistes des solutions durant cet article.

Nous aimerions bien vous proposer une recette magique. Une recette que vous pourriez, appliquer sans qui crainte de l’échec et qui va réussir à tous les coups. Mais, l’expérience de plusieurs années en informatique et en méthodologies de développement. Dont, avec les méthodologies agiles, nous a permis de comprendre qu’il faut faire attention avec ces soit disent « recette toute faite ».

Il faut repartir à la base des méthodologies agiles, les quatre principes :

• Les individus et les interactions doivent primer sur les processus et les outils
• Le développement logiciel doit primer sur la documentation exhaustive
• La collaboration avec le client doit primer sur la négociation contractuelle
• L’ouverture au changement doit primer sur le suivi d’un plan rigide

Si une organisation, (une compagnie, une équipe de développement, etc.) décide de se tourner ou du moins regarde la possibilité de le faire. C’est qu’elle a identifié qu’elle a un problème quelque part. Et potentiellement, l’un qui touche c’est quatre grands principes.

Bravo, vous avez fait le premier pas. Car, en se lançant en agile, ou toutes autres nouvelles méthodes. Il faut gérer le changement. Il faut faire un constat.
Agile ne signifie qu’il faut tout changer dans votre organisation. Encore moins, que tout ce que vous faites déjà est en erreur. Agile chercher simplement à améliorer vos processus en apportant une nouvelle vision, une nouvelle approche dans la manière d’aborder un problème.

Lorsque nous implémentons agiles dans une organisation, il ne faut pas arriver avec un bulldozer qui détruira tout sur son passage. Il faut arriver avec de la minutie, du doigté, de la sagesse et surtout beaucoup de respect.
Nous disons toujours regardons ce que vous faites de biens, ce qui peut être amélioré, ce qui doit être changé et ce qui ne doit pas l’être.

Il y a une école de pensée dans les méthodologies agiles, qui veulent la mort des méthodes « wather falls » ou des approches mérisiennes (Mérise, P+, Macroscope). Nous pensons le contraire. Si certains éléments de ces méthodes en cascade fonctionnent chez vous. Continuez à les utiliser (ne changeons pas ce qui fonctionne.) Ajustons seulement la manière de les utiliser dans un contexte agile. Exemple, si vos clients sont confortable avec un dossier fonctionnel selon les la définition de P+. Continuer à les écrire sur cette base. L’adaptation agile qu’on peut faire, c’est de réduire son volume (le nombre de pages) et le média de production. Au lieu de l’écrire sur beau document imprimé sur 8 ½ - 11. Utiliser une version électronique qui contient des références web (pointeurs) vers des processus déjà documentés ou pourquoi pas un Wiki.

A l’inverse, si aucun de vos clients ne lit le plus petit dossier fonctionnel, à quoi sert donc à s’acharner des les produire. Utiliser peut-être un « cas d’utilisation UML » ou les « Story de Scrum ».

Il apporter des solutions aux problèmes, et surtout ne pas en créer de nouveau.
Après avoir fait le constat dans votre organisation, vous nous poserez sans doute les questions suivantes :

• Il doit exister une ou plusieurs méthodes structurées qui implémentent ces principes ?
• La quelle de ses méthodes, dois-je choisir ?

Il existe plusieurs méthodes, certaines plus structurées que d’autre.
• Scrum
• Extrême programming
• Lean
• RAD (Rapid Application Developpement)
• Et plusieurs autres.

Laquelle prendre dans cette liste, en prendre une ou toutes les prendre, me diriez-vous. Nous répondons toujours, la même chose. Un bon mélange de tout ça. Un petit soupçon de SCRUM pour sa structure et sa gestion d’équipe. La gestion des story pour documenter les processus d’affaires. Le « SCRUM matinal » pour assurer un bon suivi. Et le plus important, le cycle d’itération très court avec son fameux backlog.

Quelque graine d’extrême programming, avec son « pair programming » adapté à la bonne saveur de votre organisation. Peut-être pas 2 personnes assises devant l’écran. Mais, une redondance des expertises par exemple. Par l’approche, spécialiste et son assistant. Une personne possède une personne précise. Et en cas de son absence (ou non-disponibilité), le second peut intervenir à la place du principale.

Lean la gestion de la qualité des processus et des livrables. On veut livrer quelque chose, mais surtout quelque chose de qualité. Ainsi que son principe de juste d’attends.

N’oubliez pas, ce n’est pas une recette de cuisine. Une recette générique qu’on peut appliquer tous les organisations. Si on veut respecter les valeurs mêmes d’agrile, il faut trouver le moyen d’adapter cette recette, d’ajuster les saveurs pour réponse à notre besoin. Une méthode qui nous (nous et vous) à produire de meilleurs logiciels tant qualité du produit, en coût de développement qu’en temps de développement.

En conclusion, se lancer en agile, ce n’est pas une chose simple sans pour autant être complexe. Il faut prendre le temps de bien poser l’analyse. Ne pas avoir peur de se remettre en questions et surtout avec l’agilité de s’adapter en cours de routes.

Mais, surtout trouver une personne d’expériences (en méthodologie agile) avec la chimie passera .. ! et avec laquelle vous n’aurez pas peur de tout remettre en question. Y compris de ne rien changer .. !

Je sais, il semble que nous vous laissons sur votre faim, sans avoir bien répondu à la question. Et pourtant, oui nous y avons répondu .. ! Car, la seule solution à savoir comment on se lance en agile, c’est avec vous .. que seulement nous pouvons la trouver.. !

Agile c’est de pensée différemment, et parfois de donner des réponses qui ne semblent pas en être une.

L’expérience et la compétence

Ces deux termes sont souvent confondus. Pour ma part, elles sont différentes sans pour autant s’opposer.

L’expérience s’acquière aux files des années, aucune formation, pilule magique peut données l’expérience. Comme disait mon défunt père, l’expérience s’acquiert : « au pic et la pioche » .

Quant à la compétence, elle peut s’acquérir par de la formation, par le travail, l’étude. Mais, à la base il faut avoir la structure d’esprit, de pensée, nécessaire pour arriver acquérir cette compétence.

Par exemple, j’ai un profond respect pour les programmeurs Cobol. J’ai eu de très bons professeurs, mais malgré cela je reste profondément incompétent dans ce langage. Par contre, fais-te moi parler d’architecture orientée objet et orientée Service, la je crois que je sais de quoi je parle.

Suis-je plus incompétent pour autant, non, c’est juste que mon cerveau est construit d’une certaine manière, qui m’aide dans mon travail. Et j’aurais beau travailler 10 ans, (j’espère que non) en Cobol, je resterai toujours un mauvais programmeur Cobol. Dieu merci, il y a des gens qui l’ont.

Combien de fois, j’ai entendu quelqu’un, et souvent des patrons pour justifier une promotion d’une personne. Il a acquis assez d’années expériences pour ce poste, sans pour autant regarder si la personne avait la compétence nécessaire pour ce poste.

Aux files des années, j’ai connu beaucoup de personnes qui avaient gravi les échelons par expérience sans pour autant en avoir les compétences. Un peu à l’image de principe de Peters.

À l’inverse, j’ai aussi connu beaucoup de gens, qui avaient toutes les compétences pour occuper un poste supérieur. Mais, qui n’avait pas toute « L’EXPÉRIENCE » pour l’obtenir.

Je ne veux pas dire qu’il faut donner à des gens sans expérience, des postes qui en demande. Mais, en plus de regarder l’expérience, qu’il faut regarder d’autre chose. Donc, les compétences, mais aussi l’intérêt. Je n’ai pas les compétences pour le Cobol, mais surtout aucun intérêt pour ce genre de langage.

Il faut donc, arrêter de voir l’informatique comme étant hiérarchique, mais étant compartimenté. Un bon programmeur ne fait pas automatiquement un bon architecte. C’est peut-être notre programmeur moyen qui sera notre meilleur architecte ou analyste. Je pense à coéquipier d’université, l’un pour des meilleurs programmeurs que j’ai connu. Ferais un mauvais architecte ou même pire, un analyste pitoyable. Car, il a de la difficulté à interagir et communiquer avec les autres. Mais, il écrit du code plus vite que sont ombre. Et surtout du code d’une très grande qualité.

Aujourd’hui, il doit cumuler près de 20 ans d’expérience, et aux dernières nouvelles que j’en ai eues, il est toujours programmeur. Et j’en suis sur, un programmeur redoutable. Il aurait l’expérience pour devenir Architecte ou Analyste. Mais, il n’a pas les compétences pour le devenir. Et je ne pense pas l’intérêt non plus.

Beaucoup trop, d’architecte, d’analyste ou chargé de projet qui pense, encore comme quand il était programmeur. Comme, j’ai connu beaucoup de monde, j’ai connu aussi un analyste fonctionnel, qui écrivait des dossiers fonctionnels, de vrai roman, excessivement facile à lire et comprendre. Par contre, il n’était incapable de le programmer ce dossier. A chacun son métier et les vaches seront bien gardé.

Avec les méthodologies agiles, nous offre un environnement assez sur les compétences et l’intérêt des individus plus tôt que par la reconnaissance de l’expérience. Un programmeur de 20 ans d’expérience, au lieu de lui donner un poste d’architecte dans laquelle, il n’aura pas l’expertise nécessaire. Lui donner la chance de continuer à faire ce qui fait de mieux, c'est-à-dire programmer, mais aussi transmettre toutes ces expériences (pas les années, mais la somme des projets et des lignes de codes) qu’il a fait aux autres.

Un bon programmeur, nous permet d’augmenter la qualité de notre logiciel. On veut un logiciel qui fonctionne, mais surtout un logiciel de qualité.

Mettons les bonnes aux bons endroits, tant d’un point de vue des compétences, de l’expérience que des intérêts. On est venu en informatique pour se faire du fun.. ! Pour avoir du Fun ! Donc, c’est en passant, en repassant ce modèle que nous pour arriver à cet objectif ultime, de livrer une application de qualité et surtout qui corresponds aux différents besoins de notre client.

Associons compétence, expérience et intérêt, et je crois sincèrement que nous de meilleurs ressources pour tous nos projets.

Si tout le monde change un seul individu, que cet individu en fait autant. La terre informatique se portera mieux !

Qu’est-ce que sait d’être Agile .. ! Partie 4 (L’ouverture au changement .. !)

Qu’est-ce que sait d’être Agile .. ! Partie 4 (L’ouverture au changement .. !)
Une petite phrase qui décrit bien les méthodologies Agiles, c’est l’ouverture au changement !

Beaucoup de projet, la première étape est de définir un plan de travail. Le fameux « chemin critique ». Il y a donc des gens qui ont de très bonnes boules de Crystal. Ils sont capables de définir tous les étapes, surtout en sans en oublié une seule d’un projet.
Moi, j’y arrive pour un projet « Hello world », plus gros que cela, j’en suis incapable.

Un instant, je ne dis pas de ne pas faire de plan de travail, d’y aller « free for all ». Oui, il faut faire un plan de travail. Il faut organiser la structure du projet

Ce que dit l’expression « L’ouverture au changement doit primer sur le suivi d’un plan rigide. » c’est qu’avoir fait le plan de travail, il ne faut pas le figer dans le béton.

Si on prend par exemple, la construction d’une maison, il est intéressant de savoir qu’il faut construire les fondations avant de construire les murs.
Mais, à l’étape de construire de les fondations, on n’a pas besoin de savoir la couleur des rideaux, jusqu’il faudra prévoir les services d’un décorateur à certain moment du projet.

Il faut avoir la capacité de s’adapter, le plan de travail est notre cadre, c’est lui qui nous donne les grandes directions qu’on doit prendre ou qu’on devra prendre
La planification devrait mettre en place les grandes actions du projet. Et de chacune de ses grandes actions, redéfinir les différentes sous-étapes.

Si on reprend notre maison, si on avait prévu dans notre grande planification de faire venir notre décorateur à la 8e semaine. Mais, il pourrait arriver que lorsqu’on appelle notre décorateur, qu’il n’est pas de disponibilité pour la 8e semaine. Dès qu’il nous propose de venir la 6e pour première rencontre et une seconde à la 9e semaine.

Si nous avons plan trop rigide, il sera difficile de s’adapter aux nouvelles
contraintes. C’est vrai que si nous n’avons pas les couleurs qu’il faut mettre sur les murs, il sera difficile de commandes la peinture.

Ou encore, un autre exemple, le client quand on construit la chambre des maitres, nous demande d’ajouter une porte communicante avec la chambre voisine. Il est vrai que cette demande n’était pas prévue initialement. Mais, si on reste ouvert, il sera facile de s’adapter.

En informatique, ça pourrait dire de changer le comportement d’une fonction en cours de développement, et ce, même si on s’était entendu sur un traitement différent.
Il ne faut pas oublier, ce que notre travail c’est une fournir une application fonctionnelle et surtout, qui correspond aux besoins de notre client.

Mais, c’est aussi de faire comprendre que si le besoin original était une Renaud 5 (petite voiture économique des années 1980) et qu’en cours de projets, il s’aperçoit qu’en fin de compte, c’est un camion F150 qu’il va avoir besoin qu’il aura conséquemment un changement de coups.

L’ouverture aux changements, doit venir tant de nous l’équipe de projet que de la part du client. Vous avez surement vécu des projets, qu’il avait été entendu avec le client qu’on implémenterait une fonction de telles manières. Mais d’en-cours de travaux, on s’apercevait que c’était beaucoup plus compliqué de ce qu’on aurait pu penser. Et c’est normal Je ne dit pas de réduire la fonctionnalité, mais d’essayer en collaboration avec de trouver une nouvelle manière de résoudre le problème.

Travaillons ensemble et nous pourrons changer le monde, trouvé des solutions nouvelles à divers problèmes qu’on peut vivre dans le projet. Et très souvent, on trouve la solution ou on ne pensait jamais la trouver. Il faut simplement rester ouvert et accepter de se remettre en question.

Il ne faut chercher à changer les choses pour changer les choses. Il faut prendre le temps d’apprendre à découvrir les choses qu’on doit et qu’on peut changer, et celles qu’on ne peut pas. C’est aussi ça d’être agile .!

Qu’est-ce que sait d’être Agile .. ! Partie 3 (La collaboration avec le client..!)

On vu dans les précédentes publications, le développement d’application et les interactions entre les individus.

Mais comme vous le savez tous, on peut avoir de millions de projets, mais si on a aucun client pour payer le développement, on ne fera pas longtemps du développement.

Comme il faut un client, il faut donc communiquer avec.. ! et les puristes.. Diront qu’on va aussi avoir besoin de contrat pour définir les limites du projet.
Vous avez tous raison, mais tout comme précédemment, je vais ressortir ma phrase fétiche, il faut repenser les concepts différemment.

Le contrat doit est un cadre de fonctionnement pas seulement un carcan immuable. Ce que tout client veut, c’est avoir un logiciel fonctionnel et surtout un logiciel qui résout son problème.

Mais comme personne d’entre vous n’a de véritable habileté de devins, est-ce qu’on peut croire qu’on peut écrire toutes les limites d’un projet informatique. Pour ma part, je ne le crois pas .. !

A l’inverse, il ne faut pas travailler sans contrat non plus, sans carde qui régit le projet. Mais à défaut de le fixé dans le béton, il faut peut-être trouver une approche qui nous permettra de faire évolué, lorsque nécessaire l’enveloppe budgétaire.

Ce que beaucoup de gens-conseil, et que je recommande aussi, c’est de définir un cadre d’évaluation (du genre "Planning Poker") les taches en mode unité, des unités très petites. Chacune de ses unités correspondra à une valeur monétaire. Par conséquent, il sera plus facile d’évaluer la complexité.

En structurant ce cadre, il ne faut pas oublier de dire un gros merci à notre client en lui disant que n’on allait pas que le revoir qu’en fin du projet. Tout comme pour les interactions entre les membres du projet, le client doit aussi faire partie de l’équipe.

Il doit dans la mesure du possible être accessible, ou la limite son représentant. Tous les membres de l’équipe doivent pouvoir y avoir accès. Une réponse rapide et efficace du client est un avantage.

Une organisation que j’ai connue, avait choisi d’impliquer le client en l’installer dans les mêmes locaux que l’équipe de développement. Le client avait son bureau dans la même salle, ce qui permettait aux membres d’y avoir accès rapidement et inversement.

Je dirais bravo, c’est une bonne idée, mais il faut trouver dans votre contexte la meilleure manière de l’impliqué le client, c’est de la trouver. Ce n’est pas tout les clients et les organisations qui peuvent se permettre de libérer le client pour l’installer au sein de l’équipe de développement.

Les méthodologies agiles, ce n’est pas une liste de recette magique, seulement des moyens pour résoudre tous les problèmes, mais aussi une manière de réfléchir différemment.

La solution que moi, je propose toujours à mes clients, c’est simplement de leurs dirent. Quand tu as 2 minutes, et que tu as le gout de voir où en est rendu. « Passe me voir, et je te promets que je vais essayer de prendre le temps de te le montrer. Mais, tout comme vous (le client), il pourrait arriver momentanément que j’ai une urgence à répondre, et dans ce cas-si, que je ne puisse pas répondre immédiatement à votre besoin. »

Généralement, mes clients étaient toujours heureux d’avoir la possibilité de venir me voir sans avoir peur de me déranger. Car, il le savait, que si je ne pouvais pas leur répond dans l’instant, je leur reviendrais rapidement.

Reporter une petite rencontre à l’improviste, il ne faut le faire avec discernement et intelligence. Mettez-vous dans la peau du client, si à chaque fois qu’il vient vous voir, vous lui répondez que vous n’avez pas de temps. Il ne reviendra plus !
Il est aussi permis, de gentiment demander à un client de vous laisser le temps pour travailler, lorsque celui-ci utilise un peu trop ce privilège.

En impliquant le client, en lui donnant l’importance qu’il mérite, nous aurons l’information, cette information tant recherchée.

De plus, en effectuant le développement en par petite phase comme expliqué dans un autre article. Le client sera beaucoup plus ouvert. Il faut bien sur lui expliquer que nous ne voulons pas un bar ouvert sur le budget de sa part. Et aussi, qu’il n’a pas non plus le bar ouvert sur les fonctionnalités incluses dans son logiciel.
Un client qui comprend qu’il y a un cout, un temps et un effort nécessaire pour tous tâches, et surtout que le tout régit dans notre cadre.

S’acharner dans discussion contractuelle avec un client, ce n’est pas profitable à personne. N’oublions pas notre but, tant celui de l’équipe de développement que celui du client, c’est de produire un logiciel qui fonctionne et surtout, qui correspond au besoin du client.

Travailler en agile, en méthodologie agile, c’est aussi faire un peut d’évangélisation. Il faut prendre le temps, d’expliquer pourquoi et comment on fait les choses, avec le temps, il y aura plus de gens qui seront convaincus.
Je crois que tout client avec qui on aura réussi, sera le premier à promouvoir cette nouvelle approche.

Être, agile ce n’est pas de changer les choses, c’est de penser différemment !

Qu’est-ce que sait d’être Agile .. ! Partie 2 (Développement Logiciels)

Dans ce second article sur qu’est-ce que sait d’être agile, nous allons-nous intéressé sur le deuxième grand principe des méthodologies Agiles. « Le développement logiciel doit primer sur la documentation exhaustive. »

On voit beaucoup de gens qui se disent « Agile » parce qu’il n’aime pas produire de la documentation. Mais, les méthodologies Agiles, ne disent justement pas qu’il ne faut faire de la documentation. Il faut faire de la documentation lorsque c’est nécessaire, et surtout utilisé une organisation de cette documentation pour qu’elle soit simple et facile à comprendre.

Ce principe est survenu par l’expérience de projets qui ont eu à produire d’énormes documents pour encadrer le développement de leur application. La production d’un document volumineux, de 100 pages et plus, que personne, à part son auteur ne lit vraiment, est-ce utile à produire ? Laissons la question ouverte pour le moment.

Tout comme, produire un document de plusieurs pages, quand les contraintes et les limites des fonctions pourraient s’expliquer en quelques liges ou avec l’aide de quelque digramme UML ou présentation PowerPoint.

Beaucoup de projets, passent des semaines, des mois à documenter les différentes fonctionnalités. Durant cette période, le client, ne se voie que passer devant lui que des piles de papier, et souvent qu’il ne va lire qu’en diagonale en se disant intérieurement qu’il a hâte voir fonctionner l’application.

Il suffit de faire l’exercice une fois, de montrer un prototype, même à moitié fonctionnel, à un client. Pour savoir, ce qu’il veut le faire avec.. c’est de l’essayer comme un nouveau jouait pour un enfant. N’importe quel client veut pour le voir, le toucher, ce logiciel le plus rapidement possible. Lui servir des beaux documents, se n’est que le faire languir, et ce, même la qualité du rédacteur ou du document.

De plus, qui n’a pas vécu, ou même entendu parler d’un projet, que le jour de la livraison, ou encore quelque temps après, que la documentation fonctionnelle ne correspondait plus vraiment à ce que le logiciel effectuait ! Je me souviens d’un projet de conversion d’application, sur laquelle je devais travailler sur une fonctionnalité particulière. La documentation de la version courante avait disparu, quelque chose qui n’arrive jamais ! Mais, un jour en passant dans un couloir, j’ai vue une série de cahiers anneaux, portant le nom du système.

En les voyants, c’est avec empressement, que je suis allé voir l’architecte fonctionnel et propriétaire du système, pour lui demander sa documentation en question était à jour. Devinez la réponse de l’architecte, je vous la donne en mille… « Ha oui.. c’était la version de la documentation livrée avec le système… » Ce n’a pas pris longtemps pour comprendre qu’il m’était inutile de dépoussiérer ces cahiers à anneaux. Elles étaient depuis longtemps plus à jour.

De plus, soyons francs, connaissez-vous un programmeur qui aime lire un document de plus qu’une demi-page. Moi, je n’en connais pas .. ! Donc, pourquoi s’astreinte à produire une documentation que personne ne va pas la lire.. !

Aujourd’hui, il existe tant d’outils, pour faire des prototypes, pour montrer l’interaction des écrans. Des outils qui permettent de découper étapes par étapes des algorithmes complexes. D’expliquer ce qu’on veut que fasse une fonction dans un système donné.

La production de la documentation, doit être au service du développement du logiciel, et non pas un frein. Ce que veut tout client, c’est un logiciel qui correspond à ses besoins. Et plus rapidement, qu’il y aura accès à son application, plus il pourra valider et corriger le tire. Produire de la documentation à outrance, pendant des moins, il y a risques, que lorsqu’on livre au client un système qui soit complètement dans le champ. Il est plus facile d’ajouter une pièce à une maison, quand les séparations ne sont pas construites, que quand tous les meubles sont à l’intérieur.

En livrant rapidement de petits morceaux de logiciels, à qui le client aura accès rapidement. Livrez 200 moreaux d’une application que client n’a pas accès, qui ne peut pas faire des essaies avec, cela ne sert à rien. Par exemple, un système de 100 fonctions, si on lui livre en quatre coups de 25, le client risque de ne pas avoir le temps de tout vérifier dans un délai très court.

A l’inverse, si lui régulièrement un très petit groupe de fonction de 4 ou 5 fonctions à la fois, il pourra rapidement nous informer de toute erreur ou incompréhension. On pourra ajouter la correction, ou amiloration, d’une ou deux fonctions, dans le cycle de développement c’est facile. Mais, en corrigé 15-20, partez à la recherche d’un chargé de projet de 150k et plus, au plus vite ! Et surtout avertissez, vos équipes de développement qu’elles vont faire beaucoup de temps supplémentaires.

L’agilité de livrer de petit morceau rapidement aux clients, c’est aussi de pouvoir les corriger et les ajuster rapidement.

Aussi en livrant de petites fonctions, il est plus facile d’appliquer au processus le contrôle de qualités sur celles-ci. N’importe quel programmeur va avoir faire à la mémoire du code qu’il y a fait, il y a 2 jours. Il aura beaucoup de facilité à le corriger.

Une autre chose qui aide à livrer rapidement des logiciels de qualités, s’est l’automatisation des tests. J’entends déjà crier quelqu’un dans le fonds de la salle, automatisé les tests unitaires. Oui, il faut automatiser les tests unitaires, on devrait le faire dans tout type de projet, qu’il soit en agile ou non.

J’entends par l’automatisation des tests, pas seulement les tests unitaires. Mais, aussi, les tests fonctionnels, les tests intégrés.. Toutes formes de tests qu’un ordinateur peut faire aussi bien, peut-être mieux qu’un humain. La raison est fort simple, parfois en changeant une virgule dans programme, cela peut faire changer son comportement.

C’est aussi d’utiliser des moyens qui permettent de reproduire simplement et efficacement la série de tests qui doivent être appliqués avant la livraison au client, qu’il soit fait avec l’aide l’ordinateur ou non.
Il ne faut pas oublier que de livraison en livraison, le client peut s’amuser à retester une ancienne fonctionnalité, et il ne doit pas voir de différences (si aucun changement n’a pas été demandé). En passant toujours par la même moulinette de tests, on s’assure d’une non-régression généralement.

Le but de cet article n’était pas de parler l’automatisation des tests, tant son importance que des outils pour y arriver. Je dirais simplement que l’automatisation des tests, est l’un de moyens pour livrer, rapidement des morceaux d’une application fonctionnelle.

En livrant rapidement de petits morceaux d’application, cela nous aide à mieux comprendre le besoin du client. Il arrive parfois, que le besoin et la manière de le combler, ne soient pas clairs pour les parties impliquées.
Le client peut très bien exprimer quelque chose que lui est tout à fait simple, mais pour son auditoire, est très complexe. En donnant accès rapidement, étape par étape, aux fonctions de l’application, tant le client que les professions qui les construisent, ils arrivent à une meilleure compréhension de part et d'autre, sur les moyens nécessaires à combler le besoin.

Le but ultime de tout projet informatique, est de livrer un logiciel qui couvre toutes les fonctionnalités d’un client pour l’excursion d’un travail donné.

Un client peut demander un marteau pneumatique pour construire une cabane à oiseaux. Mais, parfois en lui faisant essayer un petit marteau avec manche en bois, il pourra s’apercevoir qu’il comble parfaitement son besoin.

Nombreux projets, tant les clients que les professionnels informatiques ont voulu en faire ce que j’appelle « un trip technologique », faire une voiture qui vole, qui roule et qui peut plonger dans l’océan pour aller voir le Titanic.

Les « trip technologiques » , c’est bien joli dans les laboratoires de recherche et mais pas dans la vraie vie. Notre premier travail, en plus de développer le logiciel, s’est d’abord d’accompagner le client dans sa compréhension de son besoin et surtout dans son expression.
Je me rappelle d’une étude de cas, que j’avais fait à l’université (ça remonte à plus 13-14 ans maintenant). La solution que mes confrères d’étude préconisaient coutait à l’œil plus de 100 000 $, pour petit système de facturation. A l’inverse d’eux, moi et un vieux sénior aux cheveux gris, on a proposé un bon vieux « pad de facture » et un petit système informatique (genre fortune1000 (logiciel comptable vendu en boite)) au bureau mère de l’entreprise.

L’entreprise en question était une petite compagnie d’aviation qui travaillait (transport de marchandises et de personnes) dans le Nord du Québec (donc pas d’électricité dans le nord). A l’époque le cout de portable était exorbitant (5000 $ et +) et en plus il aurait fallu une génératrice dans le nord. Vous comprenez que les couts s’approchaient du 100 000$.

Pourtant, ce que le client avait demandé, c’était un système « informatique » dans lequel il pourrait tout faire le suivi des transports de marchandises et de personnes.

Par contre, deux autre étudiants, moi (un jeune fou aux idées révolutionnaires) et une éminence grise (un vieux sénior en informatique qui faisait son baccalauréat pour s’amuser), préconisait était une solution beaucoup plus simpliste. Un logiciel de comptabilité en boite, genre Forturne 1000 (Logiciel comptable très respecter par les professionnels de la comptabilité) pour le bureau principal, et bon vieux pad de facture (Papier) et bon de livraison pour gérer les transports dans le nord.

Tout informatiser l’ensemble des processus, mettre le tout sous ordinateur auraient été un maudit beau « trip technologique ». Mais, est-ce que ça aurait répondu aux besoins, honnêtement je ne crois pas.
Devinez, c’est quoi la solution que le professeur accepta, et qui jugeait la meilleure, était bien celles du Pad de facture. Le plus drôle de l’histoire, c’était un cas réel que lui avait exécuté par le professeur lui-même. Il avait suggéré la seconde alternative, à quelque détail prêt et elle fut acceptée par le client.

L’approche des petites livraisons, aurait surement aidé plusieurs confrères à mieux comprendre le besoin. Et surtout, à livrer au client ce dont il avait vraiment besoin.

Donc, ce dire agile, ce n’est pas, en ne faisant pas de documentation. Mais, c’est en produisant celle qui est nécessaire pour la compréhension de la fonctionnalité et d’assurer la qualité du logiciel. C’est aussi de garder en tête, que la documentation sert à la production d’un logiciel fonctionnel, et ce, le plus rapidement possible.

C’est aussi de livrer une solution simple et efficace pour résoudre le besoin exprimé par le client. Afin, de lui permettre une utilisation efficace de l’outil produit.

Bien entendu, en impliquant rapidement le client, et ce, rapidement dans le processus, cela va demander une approche différente avec le client. Mais, il ne faut pas oublier que le client reste le personnage le plus important dans tout projet informatique. Pas clients, pas de logiciel à produire.

Avant, le client s’investissait au début et à la fin du processus. Au début pour expliquer ce qu’il voulait. Et la fin, on lui demandé une période instance pour tout valider, soit plusieurs jours, plusieurs semaines prisent dans un bloc pour tout valider.

En agile, on ne lui en demande pas moins d’effort, mais on va la répartir différemment, quelques heures par cycles pour valider rapidement ce qui a été fait. (Un prochain article, traitera de la gestion des cycles et de leurs durées)

Je ne sais pas ce que vous en pensez, manger une banane par semaine, est beaucoup facile qu’un régime d’un seul coup.

Être agile, ce n’est pas de changer les choses, c’est simplement pensé différemment. Gardons ce qu’on fait de bien, et améliorons ce qui doit être amélioré.

L’équipe de Génération Agile.

Qu’est-ce que sait d’être Agile .. ! Partie 1 (Les individus)

Beaucoup de gens se disent Agile.. Mais qu’est-ce que sait d’être Agile.
Être Agile s’est d’abord avant tout, quatre grands principes :

1. Les individus et les interactions doivent primer sur les processus et les outils.
2. Le développement logiciel doit primer sur la documentation exhaustive.
3. La collaboration avec le client doit primer sur la négociation contractuelle.
4. L’ouverture au changement doit primer sur le suivi d’un plan rigide.
   

Dans ce premier article, nous regarderons l’aspect des individus et les interactions dans un projet en méthodologie Agile.

« Les individus et les interactions doivent primer sur les processus et les outils. » Beaucoup de méthodes, processus ont toujours cherché à créer la recette miracle qu’on pourrait appliquer à tous les projets pour garantir la rentabilité et le succès (livré à temps et selon le budget du contrat.).

L’expérience, et il semble que je ne suis pas seule, m’a démontré que cette recette miracle n’existe pas.. ! L’un des principaux problèmes est classement des individus par « type de profile » mais sur tout dire comment chacun des profiles va communiquer avec l’autre. Régir les communications par des documents structures.

Les grands mérisiens de se monde ont oublié que les individus, ont une capacité extra ordinaire, c'est-à-dire « SE PARLER » . Il suffit de mettre un groupe de personne ensemble avec intérêt en commun dans une salle, et en quelques minutes ! Il y aura la majorité des gens qui discuteront ensemble.

Ce que dit les principes de la méthodologie agile, laissons les gens parler, communiquer ensemble. Ils trouveront la meilleure méthode de communiquer. Il n’est pas interdit de mettre en place des processus et des outils qui faciliteront cette communication. Mais, il ne faut pas chercher à les structurer de manière telle que les individus refusent de communiquer.

Il faut leurs données des outils simples, des wikis, des post-its, une adresse de courriel..

Une machine à café.. ! Qui n’a pas réglé un problème majeur en allant chercher un café à la machine à café. Tout ceux qui ont travaillé avec moi savent que veut dire « Coffee Time’s ».Une petite expression.. ! pour dire OK.. Les amis, on prend une pause.. Pour se changer les idées.. ! Discuter autrement une problématique qu’on cherche à résoudre. Briser la forme, de voir autrement le problème.. mais surtout de prendre une petite pause.. Pour se changer les idées.. ! Ça fait du bien.

L’autre point important pour se dire agile.. c’est de tout mettre en œuvre pour éviter le temps supplémentaire… ! Un moyen que j’ai appliqué et que je sais beaucoup applique, c’est la règle du pouce 3-6.

La règle du pouce 3-6, est simple. C’est de découper en petite tâche de 3 et 6 heures. Vous me direz pourquoi 3 et 6 heures. C’est simple, 3 heures auxquelles on ajoute une heure, donc 4 heures au total, c’est une demi-journée et même chose pour 6 heures, représente une journée lorsqu’on lui additionne une heure (7 heures).

Une tâche de 3 heures, normalement au bout d’une heure, la ressource attitrée aura une bonne idée du travail faire. Elle aura identifié toutes les problématiques qu’elle devra résoudre. Et l’heure d’étalonnage au besoin permettra de finir le travail.

Le cas échéant qu’une ressource, identifie un problème majeur, récupéré une heure de travail, sur un projet normal de développement, c’est très facile.

A l’inverse, une tâche d’une durée de 30-40 heures, le temps normal d’évaluation de la complexité et des différentes problématiques qui pourraient survenir, c’est au moins une dizaine d’heures. Ce qui rend la récupération des heures perdues, encore plus difficiles. Donc, qui provoque souvent du temps supplémentaire.

Mais cette règle du pouce 3-6 demande aussi une grande responsabilisation des ressources et prise de confiance de demander rapidement de l’aide. Plus rapidement qu’on sait qu’il y a problème quelque part, et quelque nature que se soit, plus vite on peut réagir, chercher des solutions.

L’implication de chacune des ressources, l’implication en contexte Agile sont très importantes. C’est l’une des clés du succès. Le premier projet que les gens vivront en Agile, vos gens risquent d’être un peu perdu..

Parce la responsabilité ne repose plus sur les épaules d’une seule personne, mais sur tous les membres de l’équipe, sur eux en particulier. Les anciens principes chacun avaient sa responsabilité, et on ne devaient pas franchir la frontière de la responsabilité de l’autre. En Agile, chacun à un rôle principal et un rôle secondaire. Ex un développeur en plus de sa responsabilité de développer l’application, pourrait être l’assistant à l’administrateur de données.

L’avantage de cette double responsabilité, si le principal est trop occupé ou encore absent, son second peut prendre en charge momentanément effectuée le travail que l’autre aurait fait normalement.

Il est conseillé d’attribuer les rôles selon les intérêts des individus. Car, un individu qui a de l’intérêt pour une tâche, une expertise.. il s’y investira naturellement davantage que pour une qu’il n’en a pas.

Faisons confiance aux ressources, donnons les outils pour faciliter leur travail. Le climat de travail sera agréable pour tous, donc productif.
L’autre chose qu’il ne faut pas oubliée. L’être humain n’est pas fait pour travailler 20 h par jour. En partant de se principe, il faut se rappeler quand on peut éviter le temps supplémentaire, il nécessaire de le faire.

Dans un projet plus traditionnel, le temps supplémentaire est un moyen de récupérer le retard que la vie du projet à occasionné. Mais, la règle du 3-6 cherche justement à minimiser les retards.

Les méthodologies Agiles ne disent pas qu’il ne faut pas faire du temps supplémentaire. Mais qu’il faut prendre tous les moyens pour l’éviter. Et si, le besoin survient, la période de temps supplémentaire ne devait pas dépasser 4-5 jours par mois ou par cycle.

Le temps moyen d’un cycle, que j’ai connue qui généralement utilisé est entre 5 et 20 jours, mais si vous me permettez, la durée des cycles et leur fonctionnement, se sera le sujet d’un autre article.

En terminant, des ressources reposées et heureuses vont s’impliquer et mettre tout en œuvre pour le succès du projet. Car, tant le succès que l’échec, leur sera attribué individuellement que collectivement.
Soyez Agile, restez ouvert d’esprit et essayez de penser différemment.

L'équipe de GénérationAgile.