Discussion :

[n3ptvn7]

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.*

[n3ptvn7]

En ce qui concerne un manuel utilisateur ,j'ai trouvé cela
http://periurbain.cget.gouv.fr/sites..._numerique.PDF

Est-ce que cela correspond?

[4sStylZ]

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