De l'appel découverte aux tests : Notre processus de développement Bubble

Les entreprises cherchent continuellement à tirer parti des derniers outils pour créer des produits et services qui répondent à des exigences uniques. L’une des évolutions les plus passionnantes dans ce domaine est l’émergence de plateformes no-code comme Bubble, permettant aux développeurs de créer des applications logicielles sans nécessiter de connaissances approfondies en codage.

Chez notre agence Bubble, nous avons développé un processus robuste pour le développement d’applications logicielles utilisant Bubble.

Dans cet article, nous vous guiderons à travers notre approche du développement, de l’appel de découverte initial aux étapes finales des tests.

Pourquoi expliquons-nous notre processus de développement ?

Trouver la bonne agence Bubble est un défi. Savoir quelles questions poser pendant le processus de découverte peut être déroutant, et – surtout – à quoi s’attendre une fois le projet commencé.

Et si vous avez déjà une certaine expérience, vous voulez vous assurer que votre entreprise tire le meilleur parti de sa collaboration avec une agence (c’est-à-dire que vous ne voulez pas de coûts cachés ou de mauvaises surprises).

Alors que de nombreuses agences Bubble vantent leur portfolio, leurs études de cas, leur budget et leur calendrier, aucune n’expliquera son processus de développement. C’est une boîte noire.

Dans cet article, nous visons à être transparents sur les différentes phases du processus de développement et à vous donner un aperçu détaillé de chaque étape. Ainsi, vous saurez comment nous obtenons des résultats pour nos clients !

Articles connexes : Qu’est-ce qu’une agence Bubble

1. Appel de découverte

Un appel de découverte est une réunion brève et préliminaire. C’est l’occasion pour vous et nous de nous présenter, de partager vos objectifs, vos besoins et vos attentes, et de voir comment Bubble peut vous aider à les atteindre.

Un appel de découverte implique généralement vous (le client) et nous (l’équipe de développement et éventuellement un chef de projet). Nous pouvons effectuer l’appel via Zoom, Google Meet ou tout autre outil de vidéoconférence.

L’objectif d’un appel de découverte est de :

• Apprendre à se connaître et à comprendre le contexte
• Obtenir un aperçu général de votre vision, de l’énoncé du problème, du public cible, de la proposition de valeur et des critères de succès
• Identifier les principales fonctionnalités de votre application
• Déterminer s’il est judicieux de planifier un autre appel – l’appel de cadrage – pour discuter des détails de votre projet

Un appel de découverte aboutit à une compréhension générale de la manière dont vous souhaitez aider votre public. Vous recevrez également un e-mail de notre part résumant les points clés de la discussion et proposant les prochaines étapes.

Les étapes suivantes après un appel de découverte peuvent varier en fonction de la complexité et des exigences de votre projet. Certaines étapes possibles sont :

• La signature d’un contrat ou d’un NDA (accord de non-divulgation) si nécessaire
• La planification d’un appel de cadrage pour définir la portée, le calendrier, le budget et les livrables de votre projet
• La création d’un wireframe ou d’une maquette de la conception de votre application
• L’exploration de la documentation API si nécessaire

Cet appel prépare le terrain pour le reste du processus de développement.

2. Appel de cadrage

Un appel de cadrage est une réunion détaillée et approfondie. C’est une session où nous approfondissons vos objectifs, vos besoins et vos attentes et définissons comment Bubble peut vous aider à les atteindre.

Un appel de cadrage implique généralement vous (le client) et nous (l’équipe de développement et éventuellement un chef de projet). Nous pouvons effectuer l’appel via Zoom, Skype, Google Meet ou tout autre outil de vidéoconférence. Si nécessaire, il peut y avoir plusieurs appels de cadrage.

L’objectif d’un appel de cadrage est de :

• Comprendre vos exigences en détail, telles que les parcours utilisateur, la structure des données, les workflows, les préférences de conception et les intégrations
• Identifier les principaux défis et risques de votre projet
• Déterminer la portée, le calendrier, le budget et les livrables de votre projet
• Clarifier toutes les questions ou préoccupations que vous pourriez avoir concernant Bubble

Le résultat d’un appel de cadrage est un accord clair et mutuel sur ce que vous voulez construire avec Bubble et comment vous voulez le construire.

Les prochaines étapes sont :

• Le partage d’une proposition préliminaire détaillant le calendrier, le budget, les jalons et les livrables
• L’examen et l’approbation du document de proposition
• La création d’un wireframe ou d’une maquette de la conception de votre application

Un appel de cadrage est une partie importante de tout processus de développement Bubble réussi. Il vous aide à aligner la portée et les attentes de votre projet.

3. User Stories

L’étape suivante est celle des user stories.

Les user stories sont des descriptions courtes et simples de ce qu’un utilisateur veut faire ou accomplir avec votre produit. Elles sont écrites du point de vue de l’utilisateur et se concentrent sur la valeur ou le bénéfice de l’utilisation de votre produit. Elles nous aident à prioriser et à planifier le développement en fonction de ce qui compte le plus pour vos utilisateurs.

Pour écrire une bonne user story, nous suivons quelques directives :

• Utiliser un format standard : En tant que , je veux afin de .
• Être spécifique et concis : Nous évitons les termes vagues ou ambigus et nous nous concentrons sur les détails essentiels.
• Inclure des critères d’acceptation : Nous définissons comment vous saurez quand la user story est terminée et répond aux attentes de l’utilisateur.
• Utiliser des personas : Nous utilisons des exemples réalistes et représentatifs de vos utilisateurs cibles pour rendre vos user stories plus pertinentes et empathiques.

Voici quelques exemples de user stories pour une plateforme de blog :

• En tant que blogueur, je veux créer un compte afin de pouvoir publier mes articles en ligne.
• En tant que lecteur, je veux commenter les articles de blog afin de pouvoir partager mes retours et opinions avec d’autres lecteurs et blogueurs.
• En tant qu’éditeur, je veux réviser et approuver les articles de blog avant leur publication afin de garantir la qualité et la cohérence.

Les user stories diffèrent des fonctionnalités du produit car elles se concentrent sur le problème ou le besoin de l’utilisateur plutôt que sur la solution ou la fonctionnalité. Les fonctionnalités du produit décrivent ce que le produit fait ou comment il fonctionne, tandis que les user stories décrivent pourquoi le produit existe ou à qui il s’adresse.

• Fonctionnalité du produit : La plateforme de blog dispose d’un éditeur de texte riche qui prend en charge le formatage, les images, les liens, etc.
• User story : En tant que blogueur, je veux formater mes articles facilement afin de pouvoir les rendre plus attrayants et engageants pour mes lecteurs.

Les user stories nous aident à décomposer des projets complexes en morceaux gérables que nous pouvons livrer de manière incrémentale. En écrivant des user stories claires et précieuses, nous pouvons nous assurer que nous construisons des produits qui résolvent de vrais problèmes pour de vraies personnes.

Cartes de User Stories

Nous utilisons une technique appelée cartographie des user stories pour mieux organiser nos user stories.

La cartographie des user stories est une visualisation du parcours client avec notre produit du début à la fin. Elle inclut toutes les tâches qu’ils accompliraient typiquement pendant ce parcours.

La cartographie des user stories nous aide à identifier comment les utilisateurs expérimentent notre produit et quels efforts mèneront aux meilleurs résultats pour eux. Elle nous aide également à décider ce qui est le plus important, à organiser le travail en versions (offrant une nouvelle expérience client) et à déprioriser le travail ayant moins de valeur pour l’utilisateur.

Pour créer une carte de user stories, nous suivons ces étapes :

• Identifier nos personas : Nous définissons qui sont nos utilisateurs cibles en fonction de leurs objectifs, besoins, comportements, points de douleur, etc.
• Définir notre colonne vertébrale : Nous listons toutes les activités de haut niveau (également appelées Épopées) que nos personas effectueraient avec notre produit chronologiquement de gauche à droite.
• Décomposer en tâches : Nous ajoutons des détails en décomposant chaque activité en tâches plus petites (Stories) représentant des actions ou des étapes spécifiques au sein de chaque Épopée. Nous les arrangeons verticalement sous chaque Épopée selon la priorité (priorité plus élevée en haut).
• Découper en versions : Nous regroupons les Stories connexes en morceaux horizontaux (également appelés Versions) en fonction de leur proposition de valeur.

Voici un exemple de carte de user stories partielle pour une plateforme d’hébergement et d’organisation d’événements.

La cartographie des user stories nous aide à créer un module utilisable en garantissant que chaque version offre une expérience client complète plutôt que des fonctionnalités ou des tâches isolées. Elle nous aide également à n’attribuer des tâches aux équipes frontend ou backend que si nous considérons comment elles s’intègrent dans le parcours client global.

4. Wireframes

Un wireframe est une représentation visuelle de la conception de votre application. Il montre la mise en page, la structure et la hiérarchie des éléments sur chaque page de votre application. Il indique également la navigation et les fonctionnalités et visualise le parcours utilisateur.

Nous utilisons Balsamiq ou Miro pour créer les wireframes.

Un wireframe doit être :

• Brut : Un wireframe n’est pas censé être un design final ou poli. Il est destiné à être un croquis ou un plan qui capture l’essence de la conception de votre application. Nous ne tenons pas compte des couleurs, des polices, des images ou d’autres détails.
• Délimité : Un wireframe doit définir la portée et les limites de la conception de votre application. Il doit montrer quelles fonctionnalités sont incluses et exclues de votre application. Il doit également montrer comment chaque page est liée aux autres et comment les utilisateurs peuvent y naviguer.
• Ouvert : Un wireframe doit permettre la flexibilité et la créativité. Il ne doit pas nous limiter à un design fixe ou rigide. Il doit nous encourager à explorer différentes options, à expérimenter des solutions et à itérer en fonction des retours.

Voici quelques bonnes pratiques pour créer des wireframes :

• Commencez avec un stylo et du papier : Avant d’utiliser un outil numérique, nous commençons souvent avec un stylo et du papier. Cela nous permet d’esquisser rapidement nos idées sans être distraits par les détails techniques ou les contraintes.
• Utilisez des formes et des symboles simples : Pour garder vos wireframes simples et clairs, nous utilisons des formes et des symboles de base pour représenter les éléments sur chaque page. Par exemple, nous utilisons des rectangles pour les boutons ou les champs de texte, des cercles pour les icônes ou les boutons radio, des lignes pour les séparateurs ou les bordures, etc.
• Utilisez des étiquettes et des annotations : Pour rendre vos wireframes plus compréhensibles et informatifs, nous utilisons des étiquettes et des annotations pour décrire les éléments sur chaque page. Par exemple, nous utilisons des annotations pour expliquer la fonctionnalité ou l’interaction des éléments, etc.
• Utilisez des espaces réservés pour le contenu : Pour éviter de nous enliser dans les détails du contenu à ce stade, nous utilisons des espaces réservés pour le contenu tel que le texte ou les images – par exemple, du texte lorem ipsum pour les paragraphes ou les titres.
• Utilisez des exemples et des références : Pour vous inspirer, nous joignons des exemples et des références d’autres applications ou sites web qui ont des fonctionnalités similaires aux vôtres. Par exemple, si votre application a besoin d’une vue calendrier, nous ferons référence à la façon dont Google Calendar ou Outlook Calendar le font.
• Utilisez les retours et les tests : Pour valider et améliorer la conception de votre application, nous utilisons les retours et les tests des utilisateurs potentiels ou des parties prenantes.
• Utilisez les itérations et les révisions : Nous itérons et révisons les wireframes en fonction des retours et des tests pour affiner et finaliser la conception de votre application.

5. Proposition finale

Une fois que nous avons défini les User Stories et les Wireframes, nous connaissons le projet en détail. Nous pouvons maintenant vous soumettre une proposition engageante avec tout le détail – calendrier, budget, jalons et étendue des travaux.

6. Designs haute fidélité

Les designs haute fidélité sont des représentations détaillées et réalistes de l’apparence et de la sensation de votre produit une fois terminé. Ils incluent les couleurs, les polices, les icônes, les images et les interactions.

Nous utilisons Figma comme outil de conception car il est facile à utiliser, collaboratif et puissant. Nous pouvons également partager nos designs avec votre équipe et les parties prenantes pour obtenir des retours et une approbation.

Pour créer des designs haute fidélité dans Figma, nous suivons ces étapes :

• Utiliser les user stories et les wireframes comme base : Nous utilisons les user stories pour guider les fonctionnalités que nous devons concevoir. Nous utilisons également les wireframes comme base pour nos mises en page et notre structure.
• Appliquer les éléments de design visuel : Nous définissons et appliquons les éléments de design visuel courants tels que la palette de couleurs, la typographie, l’iconographie, l’espacement, etc. Nous utilisons un système de design pour la plupart de nos projets.
• Tester et itérer : Nous partageons nos designs avec vous pour montrer comment le produit fonctionnera. En fonction de vos retours, nous apporterons des modifications aux designs.

Puisque nous construisons un MVP (produit minimum viable), nous nous concentrons davantage sur la fonction que sur la forme. Cela signifie que nous priorisons la conception de fonctionnalités qui apportent de la valeur à nos utilisateurs plutôt que des fonctionnalités agréables à avoir mais facultatives. Cela ne signifie pas que notre interface utilisateur ressemble à celle des années 2000. Ce sera un design esthétiquement plaisant, mais il ne gagnera aucun prix.

7. Développement

Une fois que nous avons finalisé les user stories, les wireframes et les designs haute fidélité, nous sommes prêts à commencer le développement réel du MVP. C’est là que nous transformons votre vision en une application web fonctionnelle en utilisant Bubble, une plateforme no-code qui nous permet de construire des applications sans écrire de code.

Nous utilisons Trello pour suivre les user stories et les critères d’acceptation de chaque fonctionnalité. Trello est un outil qui nous permet de créer des tableaux avec des listes et des cartes qui représentent différentes tâches et étapes du processus de développement. Nous pouvons également joindre des fichiers, des commentaires, des listes de contrôle et des estimations à chaque carte.

Nous décomposons l’ensemble du projet en plusieurs sprints (généralement une ou deux semaines), en nous concentrant sur la livraison de fonctionnalités qui ajoutent de la valeur à l’application. Les sprints sont composés d’un mélange d’épopées combinées – donc ce n’est pas que nous allons terminer la conception, puis le workflow, non.

Chaque sprint aborde un module d’application spécifique, afin que nous puissions rester concentrés et obtenir des résultats plus rapidement. Par exemple, nous pourrions consacrer un sprint à la page d’accueil, au processus d’inscription et à la page de profil utilisateur.

Les user stories et les critères d’acceptation de chaque sprint sont ajoutés au tableau Trello. Au fur et à mesure que le développement progresse, nous mettons à jour le tableau Trello – afin que les clients aient une visibilité.

Aucun développement logiciel réussi ne peut se faire dans le silence radio. Pour toutes les communications, nous utilisons Slack pour discuter des doutes et autres questions. C’est bien mieux que de communiquer par e-mail ou par appels vidéo.

Une fois qu’une épopée est terminée, nous passons à l’étape suivante pour les tests.

8. Tests

Le test est un processus qui vérifie les défauts et les erreurs dans le produit ou l’application logicielle. Le test n’est pas la même chose que l’assurance qualité (QA), qui est plus large et se concentre sur l’amélioration des processus et des pratiques tout au long du cycle de vie du développement logiciel.

Le test est une approche réactive et corrective qui se concentre sur la recherche et la correction des bugs et des problèmes dans le logiciel.

L’un des aspects essentiels des tests est l’utilisation des critères d’acceptation pour chaque user story. Les critères d’acceptation doivent être remplis pour que la user story soit considérée comme terminée et prête à être livrée. Ils aident à clarifier les attentes et les exigences, ainsi qu’à nous guider dans notre travail.

L’équipe de test utilise les critères d’acceptation pour effectuer différents tests sur chaque user story. Certains des types de tests courants sont :

• Tests unitaires : Validation que chaque unité logicielle fonctionne comme prévu. Une unité est le plus petit composant testable d’une application.
• Tests fonctionnels : Vérification des fonctions en simulant des scénarios métier, basés sur les exigences fonctionnelles.
• Tests de régression : Vérification si les nouvelles fonctionnalités cassent ou dégradent les fonctionnalités existantes.

Si une user story passe tous les tests, elle est marquée comme terminée et passe à l’étape suivante. Si une user story échoue à un test, elle est renvoyée au développeur pour correction.

Une fois qu’un sprint est terminé, nous vous demandons de vérifier les épopées (grandes fonctionnalités composées de plusieurs user stories) pour acceptation. Vous pouvez accepter ou rejeter une épopée en fonction de votre satisfaction. Si une épopée est acceptée, elle est considérée comme faisant partie du MVP (produit minimum viable). Si une épopée est rejetée, elle est renvoyée à l’équipe de développement pour amélioration.

Le processus de test garantit que le MVP est livré avec un minimum de défauts et d’erreurs et qu’il répond à vos besoins et attentes. Il contribue également à améliorer la qualité, la fiabilité et les performances du logiciel.

9. Transfert

Une fois que toutes les épopées et user stories ont été testées, le MVP est marqué comme terminé. Il peut maintenant être transféré. Lors du transfert, il y a 4 choses à faire :

• Transfert de propriété de l’application : L’application Bubble est transférée sur votre compte Bubble et la facturation est configurée.
• Application connectée au domaine : L’application peut être connectée à un domaine personnalisé. Les modifications DNS sont simples et prennent moins de 10 minutes à effectuer. Parfois, nous connectons l’application à un domaine plus tôt dans le développement.
• Formation : Notre développeur Bubble vous fera une présentation de l’application – structure de la base de données et mise en page. Nous ne vous demanderons pas de maintenir l’application, mais Bubble est facile à comprendre à un niveau élevé, même pour les personnes non techniques. Et nos clients apprécient de savoir comment l’application fonctionne en coulisses.
• Documentation : Nous documentons l’application et partageons la documentation avec vous. Elle comprend les workflows, la structure de la base de données, la structure des pages et comment apporter des modifications mineures au contenu statique du site web. Nous utilisons Notion ou Google Docs pour cela.

10. Maintenance

La maintenance est la dernière étape de notre processus de développement.

La maintenance garantit que le produit ou l’application logicielle continue de fonctionner correctement et efficacement après avoir été transféré et déployé auprès des utilisateurs finaux. La maintenance implique également la mise à jour et l’amélioration du produit ou de l’application logicielle pour répondre aux besoins et aux attentes changeants.

Nous proposons des services de maintenance de deux manières : à la demande ou sous forme de contrat de maintenance.

La maintenance à la demande signifie que nous fournissons des services de maintenance chaque fois que vous les demandez ou en avez besoin. Nous facturons un tarif horaire fixe pour les services de maintenance à la demande.

La maintenance sous contrat signifie que nous fournissons des services de maintenance régulièrement, par exemple mensuellement, trimestriellement ou annuellement. Nous facturons des frais mensuels fixes pour les services de maintenance sous contrat. Vous pouvez choisir le type et le niveau de services de maintenance qui conviennent à vos besoins et à votre budget.

Comment gérez-vous les changements de périmètre tout au long du processus de développement ?

Les changements de périmètre sont inévitables dans tout projet. Ils peuvent survenir pour diverses raisons et peuvent avoir un impact sur le calendrier, le budget, la qualité et les livrables du projet.

Nous comprenons que les changements de périmètre sont parfois nécessaires et inévitables. Cependant, nous essayons également de les minimiser autant que possible grâce aux étapes de user story et de wireframing.

Nous examinons les user stories et les wireframes avec vous et obtenons vos retours et votre approbation avant de passer à l’étape de développement. Nous documentons également la portée des travaux de manière claire et explicite dans un contrat ou un accord qui décrit les nouveaux livrables, les délais, les coûts et les responsabilités. Cela garantit que nous sommes sur la même longueur d’onde concernant la portée du projet.

Cependant, nous reconnaissons également que certains changements de périmètre sont attendus et inévitables pendant le processus de développement. Nous suivons ces étapes pour gérer les changements de périmètre :

• Nous évaluons toute demande de changement de périmètre et examinons la faisabilité, la nécessité et la valeur du changement.
• Nous discutons de la demande de changement de périmètre – les avantages et les inconvénients du changement et essayons de parvenir à une solution mutuellement acceptable. Nous proposons également des options alternatives qui peuvent répondre aux besoins.
• Nous documentons toute demande de changement de périmètre et sa résolution dans un ordre de modification formel ou un avenant qui modifie le contrat ou l’accord original. Nous mettons également à jour le plan de projet, le calendrier, le budget et les livrables en conséquence.

Articles connexes : Comment collaborer avec une agence Bubble

Quel est le niveau d’implication des clients dans le processus de développement ?

Le niveau d’implication est élevé jusqu’à l’étape du wireframe. Jusque-là, nous avons besoin de votre contribution pour comprendre ce que nous devons construire et si nous sommes sur la bonne voie.

La plupart des projets de développement logiciel échouent non pas à cause du budget, du calendrier ou des défis techniques, mais à cause d’attentes non satisfaites.

Il n’est pas facile de traduire ce que vous avez en tête sur papier. Encore plus difficile lorsque vous devez l’expliquer à quelqu’un d’autre. Avec les user stories et les wireframes, nous essayons de comprendre la vision que vous avez en tête.

Une fois que nous avons compris, vous pouvez prendre du recul et nous pouvons commencer à développer le produit.

C’est exactement ainsi que nous gérons chaque projet chez NocodeAssistant.