Comment nous le faisons

Nous croyons chez Arpinum qu’être agile est le meilleur moyen actuellement de produire les logiciels.
Ce principe guide à la fois la façon dont nous collaborons avec nos clients, mais forge également nos disciplines de développement.

Nous utilisons essentiellement l’eXtreme Programming comme guide de nos développements, et nous pratiquons donc sans concession le Test-Driven Development, le refactoring, l’intégration continue, le pair programming.
En tant que professionnels, nous savons que ces disciplines sont le meilleur moyen de réduire les défauts, tenir les délais et livrer des logiciels qui fonctionnent.
Elles sont donc non négociables. Vous ne demanderiez pas à votre chirurgien de ne pas se laver les mains pour gagner un peu de temps.

Travailler avec nous est donc différent : nous vous demandons de nous faire confiance sur nos pratiques et nos estimations, et en contre partie nous vous mettons réellement aux commandes de votre projet.

Tests

Une équipe de développement sérieuse doit nécessairement avoir une stratégie de test. Bien sûr, tout le monde vous dira que l’application fournie est testée, mais, bien souvent, la stratégie consiste essentiellement à cliquer frénétiquement un peu partout dans l’application la veille de la livraison. Cette approche a bien des défauts :

• les erreurs sont détectées trop tard, et donc plus chères à corriger,
• le taux de couverture d’approches manuelles est tout simplement trop faible,
• les plans de test manuels étant longs à faire, ils sont joués trop rarement,
• tester à travers l’interface revient à tester l’interaction, pas le métier.

Notre stratégie s’appuie donc sur différents niveaux de tests automatisables :

Tests unitaires

Au plus bas niveau, nous pilotons notre développement par les tests. Oui, nous écrivons les tests avant même le code censé les faire passer. Cette pratique au premier abord contre intuitive, apporte en fait énormément de bénéfices :

• nous pouvons modifier le code, nous avons un harnais de tests nous indiquant dans les secondes qui suivent si nous avons introduit une anomalie. Ainsi nous ne développons pas par ajouts successifs de « vérues », mais par améliorations successives. Nous gardons donc une base de code saine, ce qui est le minimum requis pour conserver un rythme de travail stable au fil du temps,
• nous sommes plus productifs : le cycle du TDD nous permet de rester concentrés sur une tâche à la fois. De plus, le cycle étant très court, il génère moins de gaspillage : moins de temps dans le debugger,
• notre code est plus propre : piloter le développement par les tests favorise l’emploi des bonnes pratiques de développement objet,
• notre code est auto-documenté : les tests unitaires, bien plus qu’un manuel, nous indiquent ce que fournissent nos API et comment les utiliser.

Tests d’acceptation

Une des grandes difficultés dans le développement d’un logiciel est de savoir si une fonctionnalité répond au besoin. Pour couvrir ce problème, nous rédigeons en début d’itération, conjointement avec le client, les tests d’acceptation de chacune des histoires à faire ; puis nous automatisons leur exécution.
Ainsi, les critères ne sont plus flous, mais précis et exécutés sur l’application directement. Cette pratique nous permet :

• de mieux communiquer avec le client,
• de documenter l’application,
• d’avoir des tests de non régression fonctionnelle.

Ces tests ne passent pas par les écrans, garantissant ainsi d’être au plus proche du métier.

Tests d’intégration

Enfin, il faut pouvoir vérifier que l’application correctement assemblée et configurée fonctionne. Ici, nous allons pouvoir tester l’application à travers son interface utilisateur, et également vérifier la facilité d’utilisation.

Pair programming

Si vous venez dans nos bureaux, une des premières choses que vous remarquerez est que nous travaillons systématiquement en binôme.
Contrairement aux apparences, cette pratique permet de travailler plus vite et mieux. Travailler à deux permet de rester concentrés sur une tâche, de détecter plus vite des erreurs, de confronter nos idées et de transmettre de manière homogène les connaissances.
Avoir un deuxième avis en permanence permet d’éviter de rester bloqué seul pendant des heures sur un problème.

Apprentissage

Nous savons par expérience que devenir agile, ou devenir un meilleur professionnel, ne peut pas s’enseigner de manière théorique. Seule la pratique avec un mentor permet d’étayer ses connaissances et gagner la qualité et la vitesse d’un professionnel.

C’est pourquoi, lorsque nous accompagnons des équipes, nous appliquons essentiellement des formules d’apprentissages plutôt que du consulting. Nous ne vous disons pas comment faire, nous faisons avec vous. Ainsi nous allons en même temps que vous, apprendre ce qui fonctionne le mieux dans votre environnement, tout en vous transmettant les bases indispensables. Nous allons beaucoup vous écouter et vous poser de nombreuses questions, pour que les réponses émanent de vous.