Logo de providenz

Démarche

Des besoins particuliers ne peuvent se satisfaire d'une réponse préfabriquée. A chaque problème sa solution.

Ampoule

Comprendre

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.

Concevoir

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.

Développer

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.

Des méthodes pragmatiques

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é...

L'échec du cahier des charges

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.

Méthodes agiles

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.

Concrètement

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.

Qualité

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