Des besoins particuliers ne peuvent se satisfaire d'une réponse préfabriquée. A chaque problème sa
solution.
Bien qu'appliquer les mêmes recettes à tous les projets serait plus facile, il est primordial de
prendre en compte les spécificité de chaque projet. Les objectifs qui dirigent le projet doivent
être correctement appréhendés pour adopter une stratégie adéquate.
Il faudra prendre le temps de se connaître, de cerner vos contraintes et vos besoins, de faire
émerger les non-dits, et surtout de bien saisir votre vision du projet, voire de vous aider à la
préciser.
Après avoir défini les orientations générales du projet, il faut tracer les plans avant de plonger dans le code. Les cahiers des charges étant souvent peu efficaces, source d’incompréhension et rapidement obsolètes, Providenz adopte une méthodolgie différente en formalisant les exigences selon des méthodes agiles. Les fonctionnalités sont décrites en langage naturel avec précision et concision, puis ordonnées par ordre de priorité dans un backlog.
La phase de production est l'aboutissement des 2 premières. Fonctionalité par fonctionalité, le projet est construit en suivant les priorités définies précédemment. Chaque fonctionalité est assortie de tests logiciels, écrits pour automatiser la vérification de bon fonctionnement du code, pendant toute la vie du projet.
Les méthodes traditionnelles d'ingénierie sont souvent inefficaces dans le développement logiciel et entraînent des désagréments pour le client : coût, conduite du changement difficile, écarts entre le besoin réél et le produit livré...
Il est très difficile et très couteux de spécifier exhaustivement un développement informatique
complexe et d'estimer sa durée et son coût . C'est pourquoi il est courant de constater des
différences très significatives en comparant les propositions issues de mises en concurrence.
Il est également difficile pour des non spécialistes d'exprimer sans ambiguité leur besoin, et
d'avoir une vision claire du produit fini. Le produit livré est parfois bien éloigné du besoin du
client.
Inventés dans les années 90 et popularisées depuis dix ans, les méthodes agiles consistent en un
changement de paradigme.
Plutôt que se placer dans une relation client-prestataire, les protagonistes travaillent et
collaborent pour la réussite du projet.
- Le prestataire met en oeuvre les meilleures pratiques de développement et conseille le client
- Le client s'implique dans le projet, organise ses priorités, effectue les tests à chaque livraison
Ces méthodes, malgré leur manque apparent de formalisme, nécessitent une discipline rigoureuse et un
implication majeure du client.
Le développement se déroule de manière itérative et incrémentale en cycle courts de
de 1 à 2 semaines.
- Un jeu réduit de fonctionalités à développer est formalisé sous la forme de phrases concises, les
user stories
- Le prestataire développe les fonctionalités ciblées et livre au client un logiciel incomplet mais
fonctionnel
- Le client teste le logiciel et fait part de ses remarques qui seront intégrées au prochain cycle.
Un nouveau jeu de focntionalité est élaboré et on démarre un nouveau cycle.
Ainsi, la première version est livrée au bout d'une quinzaine de jours et le client peut à tout
moment infléchir le cours du développement s'il le juge utile.
Une authentique qualité logicielle ne se mesure pas en normes ou certifications. La principale
garantie réside dans la mise en place de tests automatisés.
Chaque fonctionnalité développée est accompagnée de la rédaction d'un test unitaire ou fonctionnel,
un morceau de code informatique qui va vérifier que l'application présente le comportement attendu
et qu'aucun effet de bord pénalisant n'a été généré.
Ainsi, pour un projet mature, des centaines voire des milliers de tests sont lancés avant toute mise
à jour du code. C'est le seul moyen de limiter drastiquement la survenue de régressions.
Typiquement, le volume horaire consacré à l'écriture de tests approche 40%.
Icones sous copyright - le reste CC-by providenz