Choisir sa méthode de développement : forfait classique ou agilité.

Il y a deux grandes méthodes pour planifier, budgétiser, réaliser… un développement. Ces deux méthodes ne sont pas propres à FileMaker, mais s’y appliquent parfaitement.

Que vous soyez développeur (interne ou indépendant), ou que vous soyez décideur voulant faire faire un développement par un expert, il est important de réfléchir à cet aspect méthodologique.

Je n’entends pas ici faire un cours complet sur l’agilité. Ce sont des heures qu’il faudrait prévoir. Peut-être un jour ferons-nous une formation sur le thème, appliqué à FileMaker, mais aujourd’hui, je veux juste attirer votre attention.

Comme souvent, après un aspect théorique, je vais illustrer cela par un exemple volontairement simple. Puis vous trouverez de quoi poursuivre si vous le souhaitez…

Deux méthodes

Méthode classique : forfait

Ici on commence par une analyse, très détaillée, présentée par écrit, et validée par les deux parties. C’est donc un gros travail et déjà une partie non négligeable du budget. Si je prends l’image de la maison des données, on ne fait pas seulement le plan des grandes masses, mais on précise où sont les prises électriques, quelle tapisserie dans chaque pièce, le pourcentage de pente pour l’accès en fauteuil roulant que vous avez demandé, etc. On parle de tout, sans rien laisser dans l’ombre ! On en sort un budget fixe, et un planning précis.

Puis le développeur fait le travail et le livre. Et là, dans la grande majorité des cas, il y a des problèmes. Certains points ont quand même été oubliés, d’autres ne sont pas comme vous, vous les imaginiez, etc. Et c’est le conflit…

Méthode agile

Pour répondre à de tels problèmes, la méthode agile a été mise en place depuis de nombreuses années. Ici, on fait une analyse beaucoup plus légère, plus courte. Il s’agit de pouvoir organiser le travail en modules, qui seront livrés petit à petit (on parle d’itérations). On est donc là en train de définir les modules, et de poser une indication budgétaire (et non un engagement ferme et définitif). L’analyse plus approfondie sera faire au cours du développement de chaque module. Le maitre d’ouvrage (celui qui commande le travail) aura un rôle fort, constant, pour réagir aux itérations, à ce que fait le développeur, etc. Le but est, in fine, d’avoir un résultat correspondant au besoin réel, et non à ce qui pouvait être imaginé au début. Cela veut dire que l’on peut changer d’idée. Cela veut dire aussi que le planning et le budget peuvent évoluer dans un sens ou dans l’autre.

L’expérience montre que pour une demande identique, et une implication réelle du demandeur, le budget est pratiquement le même dans les deux méthodes, mais que le résultat final correspond mieux au besoin réel avec la méthode agile.

Illustration : développer une facturation

Prenons un exemple simple.

Voilà un sujet que l’on rencontre assez souvent dans un projet de type gestion commerciale. J’imagine ici que vous êtes le décideur (le maître d’ouvrage) qui veut se faire développer un outil de facturation.

Vous voulez donc émettre des factures et le développeur vous a logiquement demandé de lui fournir un modèle. Vous lui donnez donc une de vos factures émises. Il étudie, et vous propose de faire cela, disons pour simplifier, en 1 journée. Vous lui donnez votre accord.

Il fait le travail et vous soumet le résultat. Vous convenez que cela respecte votre modèle.

Mais voilà que votre comptable vous annonce que cela ne va pas. En effet, pour une nouvelle activité que vous prévoyez, il faudra poser un second taux de tva, inexistant sur le modèle actuel.
Puis c’est votre responsable marketing qui déclare que cela ne respecte pas la charte graphique qui est justement en remaniement.
De plus, votre avocat rappelle qu’il réclame depuis un certain temps qu’il y ait les CGV (Conditions Générales de Vente) au verso…

Patratas ! Rien ne va plus !

Là, il y a deux possibilités.

1) En méthode agile, le développeur fait les changements, au fur et à mesure qu’ils sont indiqués. In fine, vous validez avec vos différents services internes, et le développeur vous facture 2 jours (temps devisé et complément pour modifications).
Résultat : vous avez des factures justes, légales… C’est le but de l’agilité.

2) Vous aviez opté pour la méthode forfaitaire, le développeur vous livre ce qu’il a fait, suivant le modèle, et vous payez LA journée prévue.
Vous obtenez des factures, mais fausses pour la TVA, plus ou moins légales (pas de CGV) et mal présentées.
Ce qui, à mon avis, est toujours trop cher, quel que soit le prix.
Il faut alors renégocier, faire un avenant au contrat, et payer au moins une journée supplémentaire. Mais vous y ajoutez le stress, les délais…
Et si vous n’avez pas envisagé cet ajout, vous n’avez que vos yeux pour pleurer…

Conclusion provisoire

On pourrait retenir de cet exemple que la méthode agile coûte 2 fois plus cher. En réalité le surcoût ne vient pas de la méthode, mais de votre manque de préparation. Si vous aviez consulté vos collègues avant de fournir le modèle, le travail aurait bien été fait en une journée.

Quelle que soit la méthode choisie, il faut réfléchir au maximum au départ. Si vous ne savez pas comment doit être votre modèle de facture, cela vous coûtera cher de le faire développer.
Et c’est vrai pour chaque partie de votre activité.

Citons Bill Gates :
« La première règle de l’intégration de toute technologie utilisée dans une entreprise est que l’automatisation appliquée à un processus efficient magnifiera l’efficience. La seconde règle est que l’automatisation appliquée à un processus inefficient magnifiera l’inefficience.”

Pour aller plus loin

Je reviendrai sur certains aspects, et certains d’entre vous auront même peut-être des expériences ou des réactions à partager via la zone de commentaire en dessous de ce billet. Mais voici quelques lieux pour vous aider…

http://fr.wikipedia.org/wiki/Méthode_agile

http://www.agiliste.fr

Et même un cours en ligne : https://www.capitainespoc.com/index.php/spoc/initiation-a-l-approche-agile-et-scrum

Bonne agilité 😉

Michel Lansard

Tags: développement, forfait, méthode agile