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