Sélectionner une page

Il fut un temps ou le développement agile n’existait pas. Le cycle en V est heureusement derrière nous et la plupart des projets de développement sont désormais guidés d’abord par le besoin et les retours des utilisateurs plutôt que par un cahier des charges sans adaptation possible.

Le mode agile permet de tirer le meilleur des développeurs

En donnant de l’autonomie aux équipes de développement, le logiciel est mieux finalisé car chaque étape est comprise et la meilleure solution est inventée ensemble. La transparence, qui est exigée en développement agile, force aussi à l’humilité : chacun fait des erreurs. Et ce n’est pas grave (à condition de les résoudre et de ne pas recommencer les mêmes).

De plus, comme les métiers à informatiser sont de plus en plus complexes, la phase de compréhension du besoin est plus que nécessaire. Appliquer bêtement un cahier des charges ne permet plus de répondre aux besoins utilisateurs et les retombées sont meilleures à la fois pour le donneur d’ordre que pour le fournisseur.

De simple exécutant, le développeur devient acteur d’un projet dans lequel il apporte ses compétences de développement mais aussi ses idées : le développeur se prend en jeu et à coeur à proposer des solutions efficaces, élégantes et pérennes.

Bénéfice induit : une plus grande implication des équipes de développement et un meilleur logiciel au final.

Le mode agile permet de concevoir de meilleurs logiciels

En développement agile, le coût jour/homme n’est plus le principal indicateur et le prix ne doit plus être systématiquement tiré vers le bas. En effet, dans une démarche agile, on passe d’un mode coût (classique) un mode de production centré autour de la valeur. C’est dur de faire évoluer les mentalités sur ce point. Entre Et c’est cette compréhension du besoin, les échanges permanents avec le client et la proximité qui font la réussite de ce type de développement. Au passage, cela complexifie de façon importante et rend beaucoup moins intéressant le développement off-shore.

Pour le client final, il est capital de bien comprendre qu’il vaut mieux avoir un logiciel bien pensé et efficace au périmètre réduit plutôt qu’une usine à gaz. Sur le papier, tout le monde est d’accord. Dans la vraie vie, c’est moins facile. Faire le choix de la simplicité et de l’efficacité est pourtant ce que veulent les utilisateurs. Il n’y a qu’à regarder les produits que sortent Apple ou Google comparés à ceux que proposent Microsoft ou la plupart des logiciels métiers. Les premiers sont intuitifs et font le job, les seconds proposent des milliers d’options mais obligent à lire des pavés de documentation et à se forcer à « rentrer dedans ».

Créer un logiciel exhaustif est certainement une très bonne idée (quand il s’agit d’un logiciel transverse à l’entreprise, ça s’appele un ERP et ce simple mot fait peur à tout le monde) mais prendre la tangente et se focaliser sur les 10 actions qui satisferont 90% des utilisateurs est au final moins cher et apporte beaucoup moins de complication. La démarche agile permet d’obtenir des logiciels du second type.