Un corpus méthodologique, tel que celui proposé par Macroscope, est habituellement le fruit de l’accumulation des meilleures pratiques basées sur l’expérience acquise et les leçons apprises d’une multitude de projets. Il propose un vocabulaire commun, une approche structurée, des rôles et des compétences requises et une foule de conseils dans son application.

Souvent appelé « méthode », il permet de faciliter la communication entre les membres de l’équipe et avec les parties prenantes, contribue à réduire le risque par une approche structurée et à livrer le valeur d’affaires attendue.

Les entreprises et organisations souhaitent toutes réduire les coûts de développement. Pour y arriver, elles cherchent à travailler différemment afin d’éliminer leurs pratiques inefficaces. Parmi les pratiques pouvant entrainer des coûts élevés, une approche est régulièrement pointée du doigt : le Big Design Up Front (BDUF) où le travail de conception s'effectue pendant des semaines, voire des mois, avant de pouvoir livrer de la valeur au client.

Avez-vous remarqué que plusieurs projets en technologie de l’information et des communications (TIC) ont de la difficulté avec leurs estimations? Que pensez-vous des écarts entre les estimations initiales et les coûts finaux? Pourtant, des techniques reconnues d’estimation de coût ont été utilisées… Qu’est-ce qui cloche?

L’estimation par point de cas d’utilisation («Use Case Point») est largement utilisée dans les projets en TIC. Cette technique d’estimation développée par Gustav Karner en 1993 a été créée pour estimer le développement logiciel d’applications orientées objet. Cette technique est un bon outil dans la mise en œuvre de solution TIC. Il devrait normalement nous aider.

La perception
Durant le cours d’introduction à Macroscope que je donnais récemment à un client, un des participants, s’étonnant de l’écart entre mon discours et ce qu’il percevait de Macroscope, me demande à peu près ceci : « Depuis ce matin que je vous entends parler de faire les bonnes choses de la bonne façon, d’agilité, d’élimination du gaspillage, etc. Mais lorsque je regarde votre gabarit d’un énoncé de projet, je vois une table des matières indiquant 22 pages, et je n’y ai même pas entré une seule ligne de contenu! Il m’est difficile de combattre cette première impression de lourdeur de la méthodologie! »

Quelques jours plus tard, je donne une autre session d’introduction à une de nos équipes LEAN, tous emballés par la matière. Une participante me fait part de son expérience récente avec un client où on lui a demandé de prendre charge de la réunion de revue d’avancement hebdomadaire du projet. Fidèle à sa nature LEAN, elle se présente avec un rapport d’avancement tenant sur une seule page, ce qui provoque, à sa surprise, des commentaires allant de « Wow, enfin il est temps que l’on soit un peu plus lean ici » à « Oh non, tu ne peux pas faire ça, ce n’est pas conforme à notre cadre normatif! », lequel, parait-il, exigeait un document touffu de plusieurs de pages… chaque semaine!

Plusieurs personnes comparent Agile et Macroscope lors d'une pause, sur le coin d'une table, un café à la main. Il ne m'est pas rare d'entendre «Macroscope ce n'est pas Agile». Un tel énoncé provient parfois d'une analyse en surface, souvent de ouï-dire, ou encore, et c'est de bonne guerre, d'une entreprise concurrente. Un diagnostic sommaire mais qui, malheureusement, compare des pommes avec des oranges.