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.

De mon dernier dialogue, vous vous doutez sans doute de la prochaine question au palmarès qui ressemble à : Dans quel bien livrable je place ça (avec le numéro, s’il vous plaît, comme dans la peinture du même nom)? Question qui s’accompagne le plus souvent de : T’en aurais pas un exemple, par hasard?

Dans un but pédagogique (!) permettez-moi d’être un peu brusque dans mon dialogue. Reprenons la dernière question de Pierre :

Comment pouvons être efficace à réaliser des essais unitaires et d'intégration avec une équipe de développement Agile?

Je n'apprends rien à quiconque en affirmant que les essais sont cruciaux pour toute bonne mise en œuvre de solution. Il est impératif d'effectuer un contrôle qualité sur l'ensemble des composants produits. Afin de garantir la qualité de la solution, une stratégie d'essais est nécessaire.

La notion de points de vue préconisée par Macroscope dans la livraison de solution permet d'intégrer les préoccupations de tous les intervenants et ainsi d'aboutir à une solution d'affaires répondant à leurs besoins. C'est un principe simple et logique.

J’ai bien des choses à dire sur ce sujet. J’en ferai donc le début d’une série sur la notion de « bien livrable » dans Macroscope. N’hésitez pas à faire part de vos commentaires et partager vos opinions.

J’ai pas mal d’années derrière la cravate à utiliser, promouvoir, enseigner, faire du coaching et faire évoluer Macroscope. Au palmarès des interrogations les plus fréquentes figurent plusieurs questions concernant les biens livrables. En voici une : Est-il bien utile pour moi de produire ce bien livrable?