La mise en œuvre d'une évolution Produit chez Isogeo

Comme tout produit informatique, la solution Isogeo doit s’adapter aux évolutions des besoins du marché, aux nouvelles technologies du Web, mais également aux nouvelles menaces en matière de cybersécurité.

Comment organiser le développement d’un produit lorsqu’on est un éditeur logiciel comme Isogeo ?

Dans cet article, nous vous présenterons les étapes nécessaires à la mise en production d'une évolution au sein de la solution Isogeo, de son intégration dans la Roadmap produit à sa mise en production.

Méthode Agile

D’une manière générale, l’équipe Isogeo développe ses produits selon la méthode AGILE (SCRUM) adaptée au contexte de la société (effectifs, missions individuelles…).

La méthode Agile préconise de se fixer des objectifs à court terme. Les projets utilisant cette méthode sont divisés en plusieurs sous-projets. Une fois le premier objectif entrepris atteint, on passe au suivant, et ainsi de suite jusqu'à l'accomplissement de l'objectif final.

Vous retrouverez donc dans cet article des termes liés à cette méthode : “sprints”, “product owner”, “sprint planning meeting”, etc.

Identification du besoin

L’origine d’une évolution peut provenir :

• d’une demande spécifique d’un ou de plusieurs clients ;
• d’une demande d’un prospect (via un appel d’offres, une demande entrante…) ;
• d’une évolution technologique (ex : arrêt de la maintenance du .NET Framework, authentication Okta) ;
• d’une évolution d’un logiciel (QGIS, ArcGIS Pro, FME) ;
• d’une évolution d’une norme (WMS, WFS, XML, CSW, DCAT) ;
• d’une évolution des besoins du marché (ex : catalogage global, livraison On-premises) ;
• de la R&D interne d’Isogeo.

Intégration à la Roadmap produit & priorisation trimestrielle

Une fois le besoin identifié, la première étape est l’intégration de l’évolution au sein de la Roadmap produit (contenant la liste exhaustive des tâches à réaliser pour chacun de nos produits).

La Roadmap produit contient également toutes les tâches de développement à effectuer, comme la mise en place du déploiement automatique (DevOps), ou la livraison en mode On-premises.

Chaque trimestre, nous priorisons ces tâches sur les 3 prochains mois selon les ressources disponibles. Cette priorisation est effectuée par l’équipe produit lors d’une semaine de travail prévue à cet effet.

Chaque produit dispose ensuite de sa propre Roadmap trimestrielle contenant tous les tickets à traiter dans un “Backlog”. Les évolutions prioritaires sont intégrées dans la colonne “To do first”, et celles moins urgentes dans la colonne “To do then” (ex :  Roadmap du Plugin QGIS).

Rédaction de la spécification fonctionnelle

Ensuite, une évolution nécessite la rédaction d’une spécification fonctionnelle, c'est-à-dire d’un document spécifiant ses différentes fonctionnalités. La spécification fonctionnelle peut être rédigée :

• dans un document Word ou Powerpoint ;
• dans un ticket GitHub ;
• ou dans une combinaison de ces 3 supports.

Une spécification fonctionnelle doit également contenir un contexte de développement, une expression du besoin, des scénarios utilisateurs, une maquette, etc…

Rédaction de la spécification technique

La spécification technique contient l’ensemble des tâches techniques à effectuer, comme l’adaptation du code, de l’interface, des appels à l’API ou encore des requêtes SQL en base de données, etc.

La spécification technique est rédigée par le développeur dans un ou plusieurs tickets GitHub (selon la transversalité de l’évolution), après avoir étudié l’implémentation de la spécification fonctionnelle.

Des échanges réguliers sont ensuite organisés entre le développeur et le Product Owner (ou le client) pour affiner la spécification technique. Parfois, la spécification fonctionnelle est également remise en question lors de cette phase d’étude technique ; on ne peut pas tout anticiper !

Une fois les dernières décisions fonctionnelles et techniques prises, la phase de développement peut commencer selon les priorités définies au préalable dans la Roadmap.

Développement du produit

L’équipe de développement travaille sur des périodes (des “sprints”) de 10 jours ouvrés, et chaque développeur dispose de sa propre Roadmap.

La décision d'aborder une évolution est prise lors du Sprint Planning Meeting, et les développeurs concernés intègrent le(s) ticket(s) GitHub correspondant à leur Roadmap.

Lors de cette phase, le développeur travaille en local et met régulièrement à jour le ticket pour indiquer son avancement. Si des questions émergent lors du développement, elles sont également inscrites dans le(s) ticket(s) et évoquées avec le Product Owner.

Selon l’impact et l’importance de l’évolution, une branche de développement, voire une branche spécifique à l’évolution peut-être utilisée dans GitHub.

Une fois l’évolution ou une partie de celle-ci développée, le développeur la déploie en QA et indique le(s) ticket(s) à recetter dans un fichier de suivi de la recette. Les produits web sont déployés de manière automatique avec Azure Devops.  

Recette

La “recette” est simplement la phase de test de l’évolution développée.

Cette phase peut-être effectuée par n’importe quel membre de l’équipe produit autre que le développeur initial. Dans l’idéal, deux membres s’occupent de la recette afin de minimiser les erreurs et les oublis. Si besoin, le développeur indique comment recetter l’évolution dans le ticket.

Une fois le ticket “recetté” de fond en comble, celui-ci est basculé dans la catégorie “Recetté” de la Roadmap du produit concerné et le développeur peut l’intégrer à la prochaine mise en production.

Lorsqu’un produit doit être entièrement recetté, des guides de recette spécifiques doivent être suivis par les testeurs afin de n’oublier aucune fonctionnalité.

Dans le cadre de l’élaboration d’un nouveau produit orienté application tierce (ex: DCAT, Plugin ArcGIS Pro…), la recette peut également être réalisée en partie par les clients via un bêta-testing.

Documentation

La documentation de la fonctionnalité est effectuée par l’équipe projet (en collaboration avec le développeur) qui doit également mettre à jour ses supports de formation.

Chaque publication est relue par un des membres de l’équipe qui n’a pas participé à sa conception.

Pour rappel, Isogeo documente l’ensemble des fonctionnalités de chaque produit dans son aide en ligne accessible à l’adresse https://help.isogeo.com.

La documentation du code et du wiki du dépôt, si elle est nécessaire, est à la charge du développeur.  

Mise en production

La phase de mise en production intervient lorsque la recette est terminée et que la documentation est prête.

Programmées une semaine avant, les mises en production s'effectuent en général le soir (18h) pour ne pas gêner l’utilisation des clients (surtout pour le cœur plateforme APP/API/BDD).

Chaque mise en production est suivie d’une nouvelle recette (en production).

Note de version

Les notes de version sont actuellement saisies dans l’aide en ligne du produit concerné.

Les évolutions côté API/BDD ont la particularité d’être documentées dans la doc d’APP.  

Suite à la refonte du Scan en 2019, un bouton “Notes de version” a été intégré à l’interface du Scan. Nous réfléchissions à intégrer cette fonctionnalité côté plateforme Isogeo pour un meilleur suivi par les utilisateurs. Nous imaginons également un système de notification à la première connexion de l’utilisateur, lui indiquant les nouveautés… Bref, de belles évolutions seront certainement ajoutées à notre Roadmap !

Retour à la liste des actualités

‍