Récemment, nous avons répondu à des questions sur le forum 4D concernant des commandes et des fonctionnalités qui semblaient incomplètes ou manquantes, comme la fonctionnalité Mail.
Dans ce billet de blog, nous allons examiner la stratégie de 4D qui sous-tend la décision de publier des versions qui ne sont pas entièrement développées, et qui est résumée dans le paradigme« Release Early, Release Often« .
Qu’est-ce que RERO (Release Early, Release Often) ?
RERO est une philosophie de développement de logiciels qui souligne l’importance des versions précoces et fréquentes. Chez 4D, nous essayons d’être à la hauteur de cette philosophie en instaurant une culture agile et ouverte qui nous permet d’inclure les commentaires des clients à un stade précoce.
Faites l’expérience de la dernière et de la meilleure version plus tôt
En publiant tôt, nous donnons à nos utilisateurs la chance de découvrir la dernière version du logiciel. Si la fonctionnalité publiée est inadéquate pour une raison quelconque, les utilisateurs peuvent réagir beaucoup plus rapidement. Ces courtes boucles de rétroaction nous permettent d’orienter les équipes de développement de produits dans la bonne direction afin de garantir que les préférences des clients sont prises en compte.
Identification plus rapide des bogues
Les premières versions sont l’occasion de tester les nouvelles fonctionnalités dans des scénarios réels. Cela nous permet d’identifier les bogues et de les corriger rapidement. Cela s’est produit récemment avec l’autocomplétion de certaines commandes 4D qui ajoutent automatiquement des parenthèses fermantes ; dans certains contextes, cela créait des erreurs dans le code. Quelque chose de difficile à découvrir sans mettre le produit entre les mains de vrais clients pour l’utiliser dans des scénarios réels.
Plus la version est petite, moins il y a de chances que quelque chose se passe mal.
Des périodes plus longues entre les versions augmentent la pression pour rendre chaque version significative, ce qui signifie plus de code, plus de fonctionnalités et plus de tests. Le résultat est la possibilité d’avoir plus de bogues. Des versions plus petites et plus rapides limitent naturellement le nombre de fonctionnalités et donc le nombre de bogues.
Dernière réflexion
Le premier principe du Manifeste Agile souligne que « Notre priorité absolue est de satisfaire le client par la livraison précoce et continue de logiciels de qualité. »
Vous pouvez toujours choisir la stratégie qui correspond à vos besoins. Les versions précoces garantissent des boucles de rétroaction courtes et vous permettent de bénéficier rapidement des nouvelles fonctionnalités, mais vous pouvez aussi décider d’attendre qu’elles soient entièrement développées.