Skip to content

Instantly share code, notes, and snippets.

@Em-AK
Last active November 1, 2017 18:46
Show Gist options
  • Save Em-AK/525a8a21afb9dd326580c236f7ebfea2 to your computer and use it in GitHub Desktop.
Save Em-AK/525a8a21afb9dd326580c236f7ebfea2 to your computer and use it in GitHub Desktop.

Brief application web : Les Bons Amis

Les bons comptes font les bons amis

Introduction

Voici le brief de ton client qui souhaite lancer une application web de gestion des dettes entre amis. Cette application peut-être utilisée dans tous les contextes où plusieures personnes ont des dépenses en commun.
Par exemple:

  • quand un.e colocataire règle la facture d'electricité et qu'il faut répartir le montant entre les trois occupant.e.s
  • quand un groupe d'amis part en road trip le temps d'un weekend à l'issue duquel il faut rembourser Marcel qui a payé l'essence, Jeanne qui a reglé la notes des sandwichs, ...
  • quand un.e ami.e achète ma place de concert parce que c'était les dernières et qu'il faut que je la rembourse
  • ...

Tu es développ.eur.euse web au sein d'une entreprise spécialisée dans le dévelopement agile de MVP pour des startups. L'objectif est donc de réaliser un prototype fonctionnel de cette application afin que le client puisse la mettre entre les mains de beta testeurs et valider le plus rapidement possible et à moindre frais que son idée à du potentiel... ou pas.

Un product owner interne a établis avec le client la liste des histoires utilisateur suivantes que le prototype doit implémenter en priorisant par ordre de plus grande valeur ajoutée. Les sénarios de validation des histoires utilisateur sont en cours d'écriture et seront alimentés d'ici le début du sprint final par le product owner. Les 3 premières histoires utilisateur sont indispensables pour lancer le prototype. Le reste du backlog est à développer si il te reste du temps.

Maintenant c'est à toi de jouer !

Contraintes du client

Le code du prototype sera repris par une équipe internationale en cours de recrutement.

  • Le code doit donc être en anglais (nom de variables, de classes, de méthodes, ...)
  • Le README à la racine du projet doit à minima:
    • lister les dépendances du projet (en environnement de dev et de production): techno et version de base de donnée, version de ruby, etc
    • les étapes pour initialiser l'application en developpement lorsque toutes les dépendances sont déjà installées (on suppose que les futurs développeurs savent installer ruby, rails et toutes les dépendances nécessaires) et avoir un serveur local qui tourne
    • la commande pour exécuter les tests
    • les instructions pour déployer l'application en production (avec postgresql) sur Scalingo, ou Heroku.
  • Les tests ne sont pas obligatoires, mais le client est prêt à débourser 25% de budget en plus si tous les scénarios de validation sont testés via des tests de feature. Les tests unitaires de modèles sont un plus.

Le livrable contient le lien du repo sur github et le lien vers l'application déployée sur heroku ou scalingo.

Backlog

Voici la liste des histoires utilisateur depuis la plus prioritaire à la moins prioritaire, avec à chaque fois le/les scénario de validation qui font office de critères d'acceptation.

Pose tes questions en commentaire de ce gist si il te manque des infos pour implémenter une histoire utilisateur.

1 - Ajouter une dépense

Histoire utilisateur

En tant qu' utilisa.teur.trice, je peux ajouter une dépense et l'affecter à un.e ou plusieurs amis, afin de ne plus avoir à m'en souvenir et me libérer l'esprit.

Scénarios de validation

  • Quand je visite la page /
    Alors la page contient le texte Les Bons Amis

  • Soit un Users existant.. Quand je visite la page /
    Et que je clique sur le bouton Ajouter une dépense
    Alors je suis redirigé vers la page /expenses/new
    Et le texte Nouvelle dépense est affiché

  • Soit trois Users existants, Camille, Paul et Marine
    Quand je visite la page /expenses/new
    Et que je sélectionne Camille comme payeuse de la dépense
    Et que je sélectionne Camille, Paul et Marine comme bénéficiaires de la dépense
    Et que je saisis 237,42 dans le champ du montant en euros
    Et que je saisis Facture électricité Enercoop 2ème trimestre 2017 dans le champ du titre
    Et que je clique sur Enregistrer
    Alors une nouvelle Expense est créée
    Et sa méthode amount renvoie 237,42
    Et sa méthode title renvoie Facture électricité Enercoop 2ème trimestre 2017
    Et sa méthode payer renvoie un User qui correspond à Camille
    Et sa méthode beneficiaries renvoie une liste de Users qui inclus Camille, Paul et Marine.

Conseil: Utiliser la gem money-rails qui permet d'utiliser simplement la gem money sur les attributs d'un modèle de Rails. En effet utiliser un float pour faire des calculs sur des montants d'argent est rarement une bonne idée. Comprendre pourquoi.

Conseil: Lire le guide sur les associations

Info: toutes les devises sont en euros dans le cadre du prototype.


2 - Balance vis à vis d'un.e ami.e

Histoire utilisateur

En tant qu' utilisa.teur.trice, je peux visualiser la balance entre un.e ami.e et moi, afin de savoir qui va régler la note du resto.

Scénario de validation

  • Soit deux Users existants, Marinne (id: 1) et Paul (id: 2)
    Et une Expense existante d'un montant de 35,73 affectée à Paul et Marine, payée par Paul
    Et une Expense existante d'un montant de 10,21 affectée à Paul et Marine, payée par Marine
    Et une Expense existante d'un montant de 18,00 affectée à Paul et Marine, payée par Marine
    Quand je visite la page /friends/2?current_user_id=1
    Alors la page contient le texte Balance
    Et la page contient le texte Tu dois 3,76€ à Paul

Conseil: Lire le guide pour savoir comment accéder aux paramètres passés par la query d'URL lorsqu'on est dans le controlleur.


3 - Balance globale

Histoire utilisateur

En tant qu' utilisa.teur.trice, je peux visualiser ma balance globale auprès de tous mes amis, afin de savoir si je suis un.e ami.e digne de ce nom ou si je suis un.e profit.eur.euse.

Scénario de validation

  • Soit trois Users existants, Marinne (id: 1) Camille et Paul
    Et une Expense existante d'un montant de 35,73 affectée à Paul et Marine, payée par Paul
    Et une Expense existante d'un montant de 10,21 affectée à Camille et Marine, payée par Marine
    Et une Expense existante d'un montant de 18,00 affectée à Marine, Paul et Camille, payée par Camille
    Quand je visite la page /?current_user_id=1
    Alors la page contient le texte Balance globale
    Et la page contient le texte 18,76€
    Et la page contient le texte Tu dois 23,87€ à tes amis
    Et la page contient le texte Tes amis te doivent 5,11€

4 - Authentifier les utilisateurs

En tant qu' utilisa.teur.trice, je peux me connecter avec mon email et mon mot de passe, afin de restreindre l'accès à certaines informations me concernant.

Scénario de validation

  • Soit aucun utilisateur connecté
    Quand je visite la page /
    Alors je suis redirigé vers la page /login
    Et la page contient le texte Se connecter
    Et la page contient le texte Email
    Et la page contient le texte Mot de passe

  • Soit un User existant, (email: "camille@hmail.com", password: "secret", firstname: "Camille")
    Quand je visite la page /login
    Et que je saisis camille@hmail.com dans le champ email
    Et que je saisis secret dans le champ mot de passe
    Alors je suis redirigé vers la page /
    Et la page contient le texte Camille

  • Re-valider les scénarios dans 2 et 3 en supprimant le paramètre ?current_user_id= des URLs et en démarrant le sénario avec un utilisateur connecté.

Conseil: Utiliser la gem Clearance pour faciliter la mise en place de l'authentification.


5 - Alerte nouvelle dette

Histoire utilisateur

En tant qu' utilisa.teur.trice, je peux recevoir un email lorsqu'un.e ami.e m'ajoute à une dépense, afin d'être alerté que j'ai une nouvelle dette.

Scénario de validation

  • Soit une User Camille connectée
    Et un autre User existant, Paul (email: paul@hmail.com)
    Quand je visite la page /expenses/new
    Et que je sélectionne Camille comme payeuse de la dépense
    Et que je sélectionne Camille, Paul comme bénéficiaires de la dépense
    Et que je saisis 42,00 dans le champ du montant en euros
    Et que je saisis Location sono crémaillère dans le champ du titre
    Et que je clique sur Enregistrer
    Alors un email est envoyé à paul@hmail.com
    Et le corps du mail contient Location sono crémaillère
    Et le corps du mail contient 21,00€

Conseil: il est possible de prévisualiser le rendu final d'un email dans Rails.


6 - Historique des dépenses

Histoire utilisateur

En tant qu' utilisa.teur.trice, je peux visualiser la liste de toutes les dépenses auxquelles je suis affecté, afin de controler que j'ai bien bénéficié du service/produit lié à chaque dépense.

Scénario de validation

  • TODO

7 - Contester une dépense

Histoire utilisateur

En tant qu' utilisa.teur.trice, je peux contester une dépense qui m'a été affecté, afin de ne pas payer pour une dépense qui ne me concerne pas.

Scénario de validation

  • TODO

8 - Modifier une dépense

Histoire utilisateur

En tant qu' utilisa.teur.trice, je peux modifier une dépense dont je suis l'auteur.e, afin de rectifier (son montant, mes amis impactés) si j'ai fait une erreur.

Scénario de validation

  • TODO
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment