Bonitasoft adopte un nouveau niveau de développement agile en ligne avec sa stratégie globale

Au milieu de l'année 2009, j'ai créé Bonitasoft avec deux autres cofondateurs, Miguel Valdés Faura et Rodrigue Le Gall, et nous avons commencé le développement de notre logiciel avec 7 développeurs. C'est en janvier 2010 que nous avons lancé Bonita Open Solution 5.0, la première version du logiciel éditée par notre société. Aujourd'hui, nous sommes les leaders des logiciels BPM Open Source avec plus de 2,75 millions de téléchargements, plus de 875 clients et une communauté de plus de 60 000 contributeurs.

Bonitasoft compte actuellement 17 développeurs travaillant à temps complet sur la solution Bonita BPM, ainsi qu'un architecte système, une équipe QA (assurance/qualité), une équipe dédiée à la documentation et un ingénieur ergonome, soit une équipe de 40 personnes.

Comment fait-on croître une équipe de développement de plus de 200% en moins de 5 ans tout en maintenant sa position de leader ? Cela s'est avéré un réel défi et une expérience enrichissante, mais surtout une opportunité d'appliquer des méthodes agiles avancées et efficaces.

Initialement, notre petite équipe était répartie entre le développement du moteur d'exécution, du portail web et du studio de modélisation de processus de la solution Bonita, avec un responsable technique et des compétences spécifiques pour chacun des groupes. Dès le départ, nous avons appliqué des méthodes agiles de développement : tous les membres de l'équipe globale travaillaient ensemble sur un sprint de deux semaines et participaient à la réunion Scrum quotidienne.

Avec une petite équipe, nous étions en mesure d'avancer de façon vraiment efficace en travaillant tous sur le même code. La première version de Bonita Open Solution a ainsi été finalisée en 6 mois.

Mais quand notre équipe de développement s'est agrandie, d'inévitables problèmes ont commencé à apparaître et nous avons dû faire face à des ralentissements de productivité. Si la chaîne de développement se rompait, la progression du travail de chacun en était affectée.

Pour remédier à ces problèmes liés à la croissance de l'entreprise, nous avons scindé le département R&D en trois équipes distinctes (toujours focalisées sur le moteur, le portail web et les éléments du studio de la suite Bonita BPM) et nous avons mis en place pour chacune d'entre elles un processus de validation indépendant pour chaque nouvel élément développé. Cela nous a grandement aidés à isoler les bugs mais l'équipe Studio était toujours la dernière à les corriger. Elle avait besoin d'une version stable de l'équipe Portail web, qui elle-même avait besoin d'une version stable de l'équipe Engine en charge du moteur. Il fallait parfois attendre jusqu'à deux semaines pour qu'un bug découvert et corrigé le jour même par l'équipe Engine soit pris en charge par l'équipe Studio.

L'expansion du nombre d'employés n'était qu'un aspect des pressions auxquelles devait faire face notre équipe d'ingénieurs. Dès que nous avons sorti la version 5 de Bonita Open Source et commencé à nous atteler au développement de notre nouveau logiciel, Bonita BPM 6, nous avons commencé à travailler plus étroitement avec l'équipe marketing. Ensemble, nous avons cherché de nouvelles solutions pour permettre à la R&D de travailler sur plusieurs fonctionnalités simultanément, du début à la fin, sans pour autant mettre en commun les ressources de chaque équipe. Nous voulions réduire la durée des cycles complets de développement de nouvelles fonctionnalités et de correction des bugs, tout en améliorant la qualité du produit. Une évolution logique de la chaîne de valeur de Bonitasoft devait s'opérer : connecter la R&D aux objectifs stratégiques d'innovation et de perfectionnement de la directionde l'entreprise.

Les analyses de l'équipe marketing influencent fortement les priorités des trois premiers pôles. Les priorités de développement du pôle Fast-track viennent des services support, satisfaction client, avant-ventes et livraison, soit les équipes de Bonitasoft en contact avec les clients. C'est dans cette optique que nous continuons à améliorer notre produit à travers l'innovation et le perfectionnement incrémental, qu'il s'agisse de nouvelles fonctionnalités ou de l'optimisation des fonctionnalités existantes.

Chaque pôle est constitué de développeurs dédiés au moteur, au web et au studio ainsi que d'un responsable produit et des membres des équipes documentation et qualité. Notre architecte systèmes et notre ingénieur ergonome travaillent au sein des 4 pôles.

Quand une fonctionnalité ou une optimisation est développée dans un pôle, elle est complètement programmée puis testée sur son serveur d'intégration continue dédié. Une fonctionnalité est considérée finalisée uniquement lorsque la traduction, la documentation et que les tests sont OK. C'est seulement à partir du moment où tout le code du pôle est stabilisé qu'il est envoyé sur les serveurs d'intégration continue partagés pour devenir accessible et utilisable par les autres pôles.

Quand il est temps de finaliser une version majeure, le code est envoyé vers un autre serveur dédié où le contrôle final qualité/assurance est réalisé.

Les bénéfices de cette approche de développement sont limpides : l'isolement de chaque pôle et l'implication de l'équipe QA dans chacun d'entre eux impliquent que le code ne soit partagé que quand il est prêt, et aucun pôle n'est dépendant d'un travail extérieur pour pouvoir avancer.

Il est aussi plus clair d'avoir un pôle dédié en permanence à la maintenance. Nous utilisons un système round-robin afin qu'un seul pôle à la fois travaille sur les correctifs de maintenance et que chaque pôle puisse le faire à son tour.

Notre principal challenge actuellement n'est plus la vitesse de propagation du code, mais plutôt la gestion d'une communication efficace entre les pôles. Le développement a beau se faire de façon isolée, une communication claire et avec le bon timing est essentielle lors des étapes majeures. Pour répondre à ce défi, nous partageons régulièrement l'information à travers des présentations informelles et chaque chef d'équipe a la responsabilité de partager l'information aux autres équipes. Toutes leurs matinées sont principalement dédiées aux tâches de coordination alors que leurs après-midi sont dédiées aux tâches de développement.

Nous observons déjà d'excellents résultats de notre approche agile par pôles. Les versions patchées sortent régulièrement chaque mois et l'application de la feuille de route de développement est mieux équilibrée entre les 4 pôles de développement. Bonita BPM a connu deux mises à jour importantes en 2013, et deux autres sont planifiées pour 2014. Avec le pôle Fast-track, nous avons été en mesure de répondre rapidement aux suggestions d'innovation de nos clients et des utilisateurs ainsi qu'aux besoins métiers, avec une flexibilité qui met en évidence et qui confirme l'efficacité de la méthode agile.