Lorsqu’on a déjà une solution logicielle, qui fonctionne en production et qui est utilisée, il est parfois difficile de considérer un changement. Le changement pour le SaaS peut être assimilé à un changement du mode d’hébergement et de distribution de sa solution, mais il s’agit de plus que cela.
Pourquoi changer?
Les développements agiles sont maintenant bien rodés, avec des méthodologies claires, bien loin d’un phénomène de mode. Un des enseignement fort de cette méthodologie est l’agilité et c’est sans doute le plus grand bénéfice offert. La logique de cycle court est sans doute l’élément le plus important dans cette approche, cela permet de rapidement matérialiser une amélioration et de la valider avec ses utilisateurs, d’effectuer les changements rapidement.
Au centre de cette transformation, c’est la proximité constante entre les équipes qui conçoivent le produit et les équipes qui réalisent ce produit, pour livrer en continu aux clients. L’agilité permet donc une démarche sous forme de « petits pas » à l’aide de cycles clairement établis.
Par où commencer?
Un des enjeux majeurs avec des changements en continu est de s’assurer que les modifications ne vont pas casser l’existant et ne pas créer des régressions. Aussi, il est souvent important de commencer par décrire fonctionnellement son produit à partir de tests.
Pour la conception, c’est d’ailleurs une façon de décrire fonctionnellement son produit en listant les attendus face à une situation : décrire le cas de réussite et les cas d’échec et les implémenter sous forme de test. Un ensemble de jeu de tests fonctionnels peut être défini par les responsables produit, implémentés par les développeurs et mis en place dans la chaine de validation avant chaque nouvelle mise en production.
Pour l’exploitation de la solution, il est également important de mettre en place les tests liés à des problèmes fournis par les utilisateurs : les bugs ainsi corrigés devraient également donner lieu à des tests introduits dans la chaine de validation.
Aussi, l’étape la plus importante est sans doute la mise en place de tests automatiques qui devront systématiquement être validés avant toute nouvelle mise en production. Pour ces tests, il faut au maximum mettre en place des outils automatiques, y compris en testant si besoin les interactions homme machine à l’aide de robots (test selon le navigateur, la taille de l’écran …)
Organiser le travail des tests
Il faut commencer par les tests unitaires qui sont associés à des fonctions particulières du code souvent sous forme d’une formule : pour telles conditions en entrée, on obtient tel résultat, si la condition n’est pas vérifiée, on doit obtenir tel comportement …
Une fois l’étape des tests unitaires implémentée systématiquement, il convient de mettre en jeu des tests fonctionnels, des tests d’usage. Ce sont alors des scénarios qui sont mis en oeuvre pour simuler un comportement plus complexe : un processus d’inscription en plusieurs étapes, des étapes de corrections dans le processus d’inscription …
Avec un jeu de tests qui augmente, on arrive rapidement à un ensemble de règles qui sont validées systématiquement et à des scénarios qui correspondent à des cas d’usage de plus en plus poussés. A ce stade, il faut avoir des jeux de données pour les tests de plus en plus élaborés. On peut alors même imaginer que ces jeux de tests avec des données peuvent alimenter automatiquement une documentation pour les utilisateurs.
Documenter la solution logicielle
La documentation technique est le moyen de permettre le travail collectif dans le temps. Elle vise surtout le travail des équipes de développements. Dans l’idéal, elle devrait accompagner chaque fichier pour permettre de comprendre les différentes fonctions applicatives. On peut aussi avoir une présentation transverse de la solution et des problématiques développées dans une logique de Knowledge Management (Wiki pour les équipes, outils de type Confluence).
Par ailleurs, la documentation utilisateur doit être également mise à jour. On peut miser sur deux grands moyen d’accompagner les utilisateurs pour prendre en main la solution:
- Une FAQ accessible dès la première visite : avec une information hiérarchisée pour aider l’utilisateur aux différentes étapes. Au-delà d’une certaine, volumétrie, il convient de mettre en place un site web avec des rubriques et des sous-rubriques
- Une aide contextuelle disponible dans la solution, avec des exemples ou des données préremplie pour guider l’utilisateur.
Mettre en place une intégration continue
La mise en production doit se faire le plus simplement possible, que ce soit pour mettre à jour une nouvelle version ou pour mettre en place un correctif. La chaine d’intégration continue vas permettre ce travail. Il faut cependant sans doute garder une logique de différents environnements, recette, staging, production en fonction des étapes de validation.
Chaque mise en production doit avoir passé les étapes de tests, la mise à jour de la documentation technique (release note) et une validation par l’équipe produit. Il est également possible de mettre en place un suivi des usages pour analyser les mises en production (en testant sur certains utilisateurs par exemple).
Gérer les bugs
Sitôt que les développements suivent des mises en production rapides et sécurisées, il convient d’être en capacité de garantir la qualité de service applicative. Le processus doit commencer par la gestion des incidents, en traitants les bugs en fonction de leur criticité : les bugs bloquants sitôt identifiés doivent être pris en charge, corrigés et donner lieu à mise en production. Les processus d’escalade des incidents doivent être en place.
Ces corrections doivent naturellement donner également lieu à la mise à jour des tests automatiques pour garantir que le bug ne se reproduira pas. Les incidents servent donc aussi à alimenter la liste des tests automatiques.
Gérer les évolutions
Les usages doivent guider les évolutions de la solution. Il convient donc d’avoir des métriques pour connaitre les usages par les utilisateurs. Si certaines fonctionnalités ne sont que peu utilisées, il faudra s’interroger sur la pertinence de leur présence dans la solution. En revanche, les fonctionnalités les plus utilisées devront donner lieu à des développements complémentaires.
Il convient donc de maintenir un mix entre :
- des corrections pour apporter des améliorations, des gains de performance ou des suppressions de bugs
- des suppressions de fonctionnalités si elles n’apportent pas de valeur significative aux utilisateurs
- des perfectionnements des fonctionnalités les plus utilisées
- de nouvelles fonctionnalités qui viennent compléter la solution
Maintenir une dynamique de cycles
Une fois ces changements mis en place, il convient de pérenniser les méthodes de travail pour garder l’agilité. Toute l’organisation de l’entreprise doit adopter la logique de cycles, de mise en place d’évolution incrémentale, en faisant en sorte que toutes les fonctions de l’entreprises s’inscrivent dans cette répétition des cycles, des équipes techniques aux équipes marketing et ventes. Bousculer cette logique, changer brutalement les priorités, c’est se priver d’une mécanique qui fait le succès des meilleures éditeurs SaaS.
