BMI SYSTEM applique les principes fondamentaux de Extreme Programming (XP), une méthode de gestion de projet informatique visant à répondre aux contraintes actuelles en termes de flexibilité et complexité des logiciels actuels.

L'Extreme Programming repose sur des cycles rapides de développement appelés itérations. Chaque itération se compose des phases suivantes :

Le cycle se répète tant que le client peut fournir des scénarios à livrer et tant qu'il peut affiner ceux déjà livrés. La première livraison est généralement plus importante et n'est réalisée qu'après quelques itérations. Après la première mise en production, les itérations peuvent devenir plus courtes.

Tout en mettant l'accent sur les bonnes pratiques de programmation, XP préconise un déroulement par itération courte et géré collectivement, avec une implication constante du client. Il en découle une redéfinition de la relation entre client et fournisseur, avec de surprenants résultats en termes de qualité de code, de délais et de satisfaction de la demande du client.

Extreme Programming est étroitement lié à Agile Programming qui complète et précise certains aspects de cette approche.

Pour parvenir à ce résultat, BMI SYSTEM applique les valeurs suivantes, fondations de Extreme programming :

La communication
Le moyen fondamental pour anticiper les problèmes et éviter les malentendus et incompréhensions. Les pratiques que préconise l'XP imposent une communication intense. Les tests, la programmation en binôme et le jeu du planning obligent les développeurs, les décideurs et les clients à communiquer. Si un manque apparait malgré tout, un coach se charge de l'identifier et de remettre ces personnes en contact.

La simplicité
La façon la plus simple d'arriver au résultat est la meilleure !

Le feedback
Le retour d'information est primordial pour le programmeur et le client. Les tests unitaires indiquent si le code fonctionne. Les tests fonctionnels donnent l'avancement du projet.  Les livraisons fréquentes permettent de tester les fonctionnalités rapidement.

Le courage
Certains changements demandent beaucoup de courage. Il est parfois indispensable de modifier l'architecture d'un projet, remettre en cause certains choix techniques ou tout simplement améliorer le code (refactoring).  La simplicité, le feedback et la communication rendent ces tâches possibles.

Client sur site
Un représentant du client doit être présent pendant toute la durée du projet. Il doit avoir les connaissances de l'utilisateur final et avoir une vision globale du résultat à obtenir. Il réalise son travail habituel tout en étant disponible pour répondre aux questions de l'équipe.

Planning
Le client crée des scénarios pour les fonctionnalités qu'il souhaite obtenir. L'équipe évalue le temps nécessaire pour les implémenter. Le client sélectionne ensuite les scénarios en fonction des priorités et du temps disponible.

Intégration continue
Lorsqu'une tâche est terminée, les modifications sont immédiatement intégrées dans le produit complet, ceci afin d'éviter la surcharge de travail liée à l'intégration de tous les éléments avant la livraison. Les itérations courtes facilitent cette intégration.

Petites livraisons
Les livraisons doivent être les plus fréquentes possibles. L'intégration continue et les tests réduisent considérablement le coût de livraison.

Tests de recette
À partir des scénarios définis par le client, l'équipe créé des procédures de test de recette (tests fonctionnels) qui permettent de vérifier l'avancement du développement. Dans la mesure du possible, ces tests sont automatisés.

Tests unitaires
Avant d'implémenter une fonctionnalité, le développeur écrit un test qui vérifiera que son programme se comporte comme prévu. Ce test sera conservé jusqu'à la fin du projet, tant que la fonctionnalité est requise. À chaque modification du code, on lance tous les tests écrits par tous les développeurs, afin d'éviter la régression et une détérioration du logiciel au fur et à mesure de sa complexification.

Conception simple
L'objectif d'une itération est d'implémenter les scénarios sélectionnés par le client, et uniquement cela. Envisager les prochaines évolutions nous ferait perdre du temps sans avoir la garantie qu'on en gagnera plus tard. Plus l'application est simple, plus il sera facile de la faire évoluer lors des prochaines itérations. De même, la documentation doit être minimale : on préfèrera un programme simple qui nécessite peu d'explications à un système complexe.