IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Méthodes Agiles Discussion :

Lister les differentes fonctionnalités.


Sujet :

Méthodes Agiles

  1. #1
    Nouveau membre du Club
    Homme Profil pro
    Étudiant
    Inscrit en
    décembre 2017
    Messages
    26
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Seine Saint Denis (Île de France)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : décembre 2017
    Messages : 26
    Points : 26
    Points
    26
    Par défaut Lister les differentes fonctionnalités.
    Bonjour futur étudiant en développement Web, je viens poser une question dont je n'arrive pas à avoir le degré d'information qui me convient. J'ai accès à des cours qui sont assez théoriques.
    De ce que j'ai pu comprendre, je vais apprendre des choses qui ne sont plus appliquées dans la réalité. Par exemple la manière dont on doit rédiger des spécifications techniques.Cependant je vais avoir des projets à rendre sur la maniéré dont on choisis une solution technique et on liste les fonctionnalites demandés par un client.
    J'aimerai savoir lorsque je rédige le backlog, est ce que c'est cela lister les fonctionnalités ou je devrais faire autre chose*?

    Pour m'entrainer, j'ai imaginé qu'une entreprise venait me donner un cahier des charges pour réaliser un site internet.
    J'ai donc réaliser un backlog et j'aimerai savoir si créer ce backlog, c'est uniquement cela lister les fonctionnalités*?
    Je sais que chaque fonctionnalité je devrais rédiger un manuel utilisateur, de la documentation technique, je voudrais savoir si c'est de cela dont on parle ou si je dois rédiger un autre document ou je vais lister toutes les fonctionnalités*? Si c'est le cas, j'aimerai savoir quelles sont les normes que je devrais respecter pour les rédiger*? Est ce que comme un backlog, je dois commencer par les plus importantes*?
    Si par exemple une des fonctionnalité serait une barre de recherches, je dois ajouter quoi comme autre information ou je liste uniquement barre de recherche.
    Là pour l'exercice que j'ai imaginé, j'ai créer un document qui a pour titre:Ensemble des fonctionnalités
    Ensuite j'ai fais des tirets ou je met le nom de la fonction puis à cotés à quoi elle va servir
    Exemple*:
    -Barre de recherche*: Fonction qui permettra à l'utilisateur de rechercher des informations sur le site et/ou dans la base de données.
    Si je suis hors sujet, n'hésitez pas à me le dire
    Si vous avez un document d'exemple, je suis preneur.

    Merci d'avance pour vos réponses.*

  2. #2
    Nouveau membre du Club
    Homme Profil pro
    Étudiant
    Inscrit en
    décembre 2017
    Messages
    26
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Seine Saint Denis (Île de France)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : décembre 2017
    Messages : 26
    Points : 26
    Points
    26
    Par défaut
    En ce qui concerne un manuel utilisateur ,j'ai trouvé cela
    http://periurbain.cget.gouv.fr/sites..._numerique.PDF

    Est-ce que cela correspond?

  3. #3
    Membre éprouvé Avatar de 4sStylZ
    Homme Profil pro
    Null
    Inscrit en
    novembre 2011
    Messages
    304
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : Null
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : novembre 2011
    Messages : 304
    Points : 1 000
    Points
    1 000
    Par défaut
    Bonjour,

    Les entreprises fonctionnent en géneral avec deux processus (agile et les autres méthodes) et surtout deux « mondes » qui s'opposent.
    Là ou tu entendra parler de pratiques de développement produit et méthode agile, tu aura certainement des fonctionnalités, un backlog, des users story etc.
    Si à l'opposé tu travaille avec des sociétés non agiles, tu croisera des livrables très différent. Souvent de grosses documentations très rigides comme un cahier des charges, une expression de besoin, des spécifications fonctionnelles ou techniques avec des niveaux de détails différents.

    Ne t'en fait pas sur ce que tu apprend. Sur ces méthodes « théoriques » pour faire des spécifications techniques. Si c'est méthodes peuvent être jugées obsolètes, elles t'apprennent néanmoins à analyser et à formuler des réponses. Tous les développeurs doivent trouver des solutions techniques et les formuler quelque part à l'écrit et cela même des dans processus de développement agiles.

    « Pour m’entraîner, j'ai imaginé qu'une entreprise venait me donner un cahier des charges pour réaliser un site internet »
    Un client final ne fera presque jamais ça, sauf une société ayant de fortes prédominances techniques. Il n'est rarement cultivé à rédiger un cahier des charges. Un cahier des charges peut être réalisé par ton client si… tu est une société qui fait la sous-traitance du développement.

    Cahier des charges est un mot très très fourre-tout utilisé pour tout et n'importe quoi, mélanger des besoins fonctionnelles, des exigences techniques etc…
    Une expression de besoin est un document qui peut être intéressant à formuler pour initier un projet, et certains besoins peuvent être présents pour répondre à des contraintes légales.

    Le backlog lui a une connotation très « agile ». Il contient la vision à court et long terme de ton produit. Il contient des « items » de différents types : De simples post-it contenant des idées. Des besoins utilisateurs exprimées sous forme de users-stories ou job stories.

    Je vais répondre à toutes tes questions seulement d'un point de vue « méthode agiles » / « Mode Produit » car c'est mon métier, qu'on est dans la section agile, et que les autres méthodes ne m’intéressent pas vraiment .

    Dans un backlog, souvent, les items sont hiérarchisés / découpé (slicing) de la sorte :

    1 backlog par produit

    • Idées d'improvement en vrac / ticket de TMA à gérer qui sous cette forme sont inexploitables pour des développeurs.
    • Epic / Épopées : Une liste de fonctionnalités qui peuvent répondre à un grand enjeux, un module de l'application etc.
    • Features / Fonctionnalités : Une solution qui fonctionnelle métier pour répondre à un besoin plus précis.
    • Users stories : Un besoin utilisateur (et souvent, une solution à ce besoin qui a été négocié avec les membres de l'équipe : Designers, PO, développeurs etc)
    • Des tests d'acceptations / Acceptance criterias qui permettent d'identifier, valider, tester qu'une users story délivrée amène à un incrément au produit (tant technique que fonctionnelle).


    Souvent, le backlog utilise des « Personas » utilisateurs / clients pour parler des utilisateurs. De manière à différencier ceux-ci quand c'est nécessaire.

    Pour construire un backlog, il est une très mauvaise pratique de s’intéresser uniquement aux fonctionnalités, à la solution que l'on veut dans notre produit.
    La démarche produit c'est avant tout de se focaliser sur les utilisateurs : De quoi ont ils besoin ? C'est ne chercher à faire que le plus important, le plus valorisant pour l’expérience des utilisateurs.

    Lister des fonctionnalités à développer (souvent en étant persuadé que c'est la chose à faire) c'est faire du projet. Souvent ce n'est pas agile (qui dit qu'on aura besoin de ça au final ? Est-on sur de ne pas changer d'avis ? d'avoir le budget de réaliser ça ?).

    L'un des procéder pour élaborer un backlog, que je suggère souvent :
    - 0) Identifier les utilisateurs du produit (les personas utilisateurs).
    - 1) Liste d'abord les besoins, les users needs. (Un simple tableau Miro ou expression de besoin peut aider)
    - 2) Lister les exigences légales (e. g. Mon client Européen, donc soumis à la RGPD). -> Peut être présent dans un cahier des charge technique ou un DAT (document d'architecture technique).
    - 3) Ensuite essaie de répondre à ces besoins par une ou plusieurs « users journey » (on parle parfois de customer journey) puis en parcours utilisateur sous forme de mockups / sketch. (Un prémisse de solution, formalisé sur des slides, un Miro ou des diagrames)

    Une fois que le parcours utilisateur est connu, qu'on a une plus claire idée de ce que l'on peut produire en matière de design, et si possible que le client à une idée claire de ce qu'il veut :
    - 4) On créé un story map. Les personas sont en haut, chaque user journey peut être une Epic ou plusieurs Epic, et on peut découper tous les élements (à partir de maquettes si on en as) en users stories.
    - 5) On ne rédige que les users stories les plus importantes, celles que l'on veut présenter le plus vite aux devs.
    - 6) On les raffine avec eux (Backlog grooming / Refinement) et redécoupe si besoin. Ils peuvent préciser le détail des solutions techniques sur les users story dans une séction dédiée, dans le DAT, ou dans des items séparés (ce que je considère personellement comme un bad-pattern).

    Tous ses documents n'ont de sens que si tu les montre aux bonnes personnes. Si tu parle à des marketeux / des sales / des account manager, ne montre pas forcément ta board dans le détail mais seulement les épic / le story map.

    Pour apprendre à rédiger des stories, cherche à propos d'INVEST, des templates de tests d'acceptations.

    PS : Je te conseille le reddit scrum et les forums US. Honnêtement les forums dvp.com en matière d'agile c'est tout mort

Discussions similaires

  1. Réponses: 3
    Dernier message: 23/05/2012, 10h13
  2. Lister les softs installés sur un Pc
    Par Jflgb dans le forum C++Builder
    Réponses: 18
    Dernier message: 23/06/2004, 17h34
  3. Lister les tables d'une Base
    Par YanK dans le forum PostgreSQL
    Réponses: 4
    Dernier message: 08/10/2003, 10h40
  4. [VB6] [Réseau] Lister les ordinateurs du réseau
    Par CYFL dans le forum VB 6 et antérieur
    Réponses: 3
    Dernier message: 17/12/2002, 09h25
  5. [TP]Lister les fichiers d'un répertoire
    Par nvtitan dans le forum Turbo Pascal
    Réponses: 4
    Dernier message: 21/06/2002, 11h22

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo