Concevoir : Les besoins changent tout le temps...

Qui n'a pas déjà entendu cela de la part de ses développeurs ?
Personne car la fluctuation des besoins d'un client fait partie intégrante d'un projet de développement.

Une fois ce constat fait, il y a plusieurs façons de réagir :

• Fataliste : on ne peut rien y faire donc on va se protéger. On réalise la conception et on fait signer le client sur cette base. Ensuite on prévoit les mécanismes pour limiter au maximum les changements : avenants, surfacturation, ...
• Arrangeante : on accepte les moindres demandes du client. C'est vrai cela va lui faire plaisir... dans un premier temps ! Le résultat cependant certainement moins car soit vous livrerez en retard (ce qui implique aussi que vous aurez dépassé les charges : qui paie ?), soit vous livrerez une solution qui ne sera pas d'une qualité irréprochable (vos développeurs auront modifiés à la marge, surchargés à la hâte, non documentés, ...)
• Agile : On se met d'accord sur les attentes fonctionnelles et on ajuste au fur et à mesure les besoins.

Vous allez me dire : "C'est bien sûr l'approche Agile qui paraît la plus pertinente !". Et vous avez, à mon sens, tout à fait raison !

Car les besoins ne peuvent être réellement figés...
Les causes de cette incapacité à définir clairement la cible sont multiples :

• méconnaissances du client des possibilités qui lui sont offertes
• difficulté du fournisseur à estimer le coût de la réalisation
• la valeur ajoutée d'une fonctionnalité n'est réellement quantifiée qu'une fois celle-ci utilisée

Mais alors pourquoi les méthodes Agiles ne sont pas (ou peu) mises en oeuvre ?
Pour de nombreuses raisons :

• elles nécessitent une implication "quasi" quotidienne du client, dans l'idéal le client doit être représenté au sein de l'équipe
• elles impliquent une visibilité limitée sur le coût de la solution : même s'il s'avère que, dans 99% des cas, le coût final est moindre pour le client
• elles provoquent une sensation de non maîtrise du résultat final pour le client : alors que l'on va s'adapter tout au long du projet à ces attentes...

La solution que je préconise actuellement, au sein de Logi-Tech Informatique, et mets en oeuvre chez mes clients, est de prendre appui sur les principes fondateurs de l'agilité (voir le Manifeste Agile) et de ménager dans un premier temps les impacts du changement dans leur structure.
Sans parler d'Agilité, je leur présente les avantages inhérents à ces pratiques, notamment l'adéquation optimale aux besoins, et leur propose de réfléchir ensemble aux "efforts" qui leurs semblent envisageables en interne pour aller dans cette voie.

De cette manière, je définis d'un commun accord les principales métriques (fréquences des réunions fonctionnelles, fréquences de livraison, ...) de mon projet Agile et remporte l'adhésion du client à cette démarche.

Amenez calmement vos clients vers l'Agilité, prouvez leurs ses bienfaits et le cycle en V sera vite oublié !