Bonjour,
En mode agile scrum, doit-on écrire des documents de spécifications fonctionnelles en word par exemple (comme en cycle en V) pour d’avoir une vision globale du produit?
Si oui peut-on créér des users stories de rédaction de ces spécifications dans les sprints ?
Merci de votre aide.
Damien
Hello Damien !
Comme ta question est vague, sans une question précise, il va m’être difficile de t’aider. Pour être sûr tout d’abord : qu’est-ce qu’une vision globale du produit, pour toi ? Et qu’est-ce qu’une user story ?
Je peux juste te répondre sur une chose : oui, les spécifications fonctionnelles, bien sûr que tu peux les faire sur word ! Tant que c’est un support maîtrisé par l’équipe, c’est OK. Par contre, en agile, la logique est simple : « un logiciel opérationnel plus qu’une documentation exhaustive ».
Plus ta documentation est exhaustive, c’est à dire complète, plus tu risques de rentrer dans une phase de « paralysie par l’analyse » : parfois il vaut mieux créer des choses simples et se lancer, de livrer, plutôt que de passer des semaines à analyser.
Les User Stories ont été la parade à ça : créer des documents simples, de questions lignes, rédigés par le client (ou son représentant…), avec un critère d’acceptation, représentant ce que fait littéralement un utilisateur. Cela permet d’en discuter avec l’équipe et d’affiner ensemble les sujets fonctionnels voire techniques si besoin.
En clair, le principe d’or pour les spécifications que j’expliquais dans mes formations : comme le but d’une spécification, c’est de communiquer, la meilleure des spécifications, c’est celle comprise par tous. Et la meilleure manière de la communiquer, c’est à l’oral et ensemble. Et le corollaire : plus elle est grosse, plus la communication est imprécise car diffuse, et plus elle est dangereuse !
Bonsoir Damien,
Je crois comprendre ta question, je vais la reformuler :
Existe-t-il un ou des outils généralement utilisés pour écrire les spécifications fonctionnelles en gestion de projet agile, qui permettent d’avoir une vision globale du produit ?
Si oui, peut-on rédiger des User Stories pendant les sprint ?
Je vais répondre à ces deux questions, peut-être que tu auras tes réponses 
Je crois que tu devrais trouver toutes les réponses à tes questions sur le ScrumLife de Youtube, mais n’oublie pas que l’agilité sert à gérer des projets, et qu’un projet a un objectif. Pour l’atteindre dans les meilleures conditions possibles je te conseille d’utiliser les logiciels qui ont été développés pour ces fonctions, qui te permettront de gagner du temps, de la qualité, et de la bonne humeur.
Le manuel de l’agilité ne dit pas « pas de documentation », il dit
" * Les individus et leurs interactions plus que les processus et les outils
@Fabulfab et @dmnbeginner, soyez les bienvenus sur le forum.
Vision globale du produit
Oui, User Story Mapping est un outil qui peut aider.
Rédiger les spécifications
Le but est d’avoir des spécifications exécutables automatiquement.
D’après mon expérience, un Word n’est pas très pratique pour y arriver.
Les pratiques sont :
- Behaviour Driven-Development (BDD)
- Acceptance Test Driven-Development (ATDD)
- 3 amigos
- Exemple Mapping
Sources :
Rédiger des User Stories pendant les Sprints
Oui, rien ne l’empêche.
Selon le Scrum guide. Il n’y a aucun engagement sur le contenu du Sprint, mais sur le Sprint Goal.
Donc il est totalement possible de faire évoluer le Sprint Backlog durant le Sprint. L’évènement dédié, mais pas que, est le Daily Scrum.
Sinon, y’a un truc cool qui genre fait des specs fonctionnelles détaillés, est réutilisable en BDD, DDD, DCI et couvre à peu près tout ce qui est noté plus haut:
Oui, et non.
Oui, toute la doc qui n’est pas viable devrait être cramée après avoir été utilisée pour son but, et oui, la majorité du temps, ce but est la communication. La doc d’archi, la doc technique et tout autre document pré-implémentation sont des mensonges au mieux.
« Le schéma n’est pas le plan et le plan n’est pas non plus l’architecture »
La seule vérité, technique ou architecturale est celle du code, et la meilleure approche sur le sujet à ma connaissance est la living documentation proposée par Cyrille Martraire.
Non, d’une parce que l’acte d’écrire amène plus facilement à du Système 2 parce que l’effort est plus important. De deux parce que tant que le « Pourquoi » est documenté (ADR notamment), les traces sont importantes. De trois parce que le point de focus que sont les use-cases nécessite aussi de la documentation parce que ces derniers ne change pas. La seule chose qui changent réellement, c’est notre compréhension de ces derniers.
Je fais la différence entre la doc et les spécifications fonctionnelles.
La documentation englobe bien plus que des specs. Je suis en phase avec ça. Et je suis pour écrire d’abord avant d’en discuter (c’était le but des US).
Comment ça ? Tu veux dire que la User-Story n’est pas le ticket que tu bouges dans Jira, et que personne qui n’a jamais rencontré un utilisateur de tout le projet ne devrait avoir la prétention d’appeler cet artefact une User Story de toute façon ? :0 Je suis abasourdi.
mais oui mais quand est-ce ce que tu nous présente ça plus clairement !! 
Le truc le plus simple et mieux fait que j’ai sans que ce soit payant, et en anglais, c’est çà : Use Cases | Usability.gov
Sinon la doc officiel se trouve là : https://www.ivarjacobson.com/publications/white-papers/use-case-20-e-book (mais faut vendre son âme au diable)
Et puis je suis sûr que @jplambert et @const sauront faire une vidéo sur le sujet 
Merci pour vos réponses.
Par vision globale du produit je voulais un document qui englobe toutes les fonctionnalités du produit (pour décrire le logiciel dans son ensemble)
Quand une nouvelle personne arrive dans l’équipe ce document sert de référence.
Retrouver l’ensemble de toutes les fonctionnalités du produit dans les user story dans JIRA semble compliquer.
Pour revenir au sujet de la question initiale de @dmnbeginner
Je vois que les réponses ont dévié sur les US, je pense pas que c’était ça le sujet de Damien.
Personnellement en tant que PO je maintiens une spec fonctionnelle « élargie » du produit que je possède. Ce ne sont pas des user stories compilées, rien n’à voir.
Je suis propriétaire du produit : les utilisateurs, parties-prenantes, mon successeur, auront tôt ou tard besoin de cette documentation qui explique ce qu’est le produit, le contexte de réalisation, les enjeux, la couverture fonctionnelle, l’architecture, les données manipulées, les workflows, comment il est intégré dans le système d’information de l’entreprise, comment il est couplé avec des systèmes externes, les principales fonctionnalités, les rôles des utilisateurs etc. Bref tout ce qui peut avoir de la valeur pour les personnes qui n’ont pas été dans l’équipe Scrum de réalisation et qui ont besoin d’interagir avec le produit d’une façon ou d’une autre (reprise de projet, transfert de co, audit sécu, cnil, RGAA,…)
Ca fait partie des livrables attendus de mon client et c’est totalement normal de laisser une trace autrement que le logiciel lui-même.
Par rapport à ta question « doit-on écrire des documents de spécifications fonctionnelles ? » je réponds donc oui, ça reste la documentation de référence à laquelle on se réfèrera, à la condition qu’elle soit à jour bien sûr.
Le sprint backlog concerne les tâche permettant la réalisation du produit, donc il n’y aura pas de User Stories de création de documentation, comme il n’y a pas de user stories du scrum master : planifier la sprint review, préparer la rétro…
En tant que PO, si il est nécessaire de revoir la doc avec le lead dev, ajouter des schéma d’archi ou je ne sais quoi qui nécessite un investissement du développeur sur un sprint, ça peut être identifié comme une tâche sur le Sprint Backlog
Donc la doc, je la complète quand c’est nécessaire, quand c’est possible, dans un cadre beaucoup plus élargie que le cadre des sprints, je me fixe des objectifs avec le client ou le manager sur une temporalité de trimestre ou semestre suivant ce qu’il est nécessaire d’y voir figurer.
Est-ce que je réponds à ta question ?
Encore une fois, les use-cases répondent à une majorité de ces points. On y dénombre les acteurs (internes ou externes), les outils, les fonctions… Pour ce qui est de l’architecture et des points plus techniques par contre, encore une fois, la living-documentation est un très bon moyen de faire les choses.
Notre process actuel : nous avons des tickets qu’on dépile (nan j’déconne, c’est un clin d’œil pour les agités du forum qui, comme moi, font le tour des nouveaux messages 
).
Nous avons des stories. Dans ces stories il y a soit l’expression d’un besoin et/ou d’une problématique, soit une demande de mise en œuvre.
Pour les besoins/problématiques, elles sont reformulées généralement sous forme de user story (en tant que afin de je souhaite - enfin c’est encore je veux mais ça va bientôt changer, hein POW, si tu passe par là un jour 
) il y a également des critères d’acceptation, qui prennent souvent la formulation gherkin juste pour le plaisir de mieux se comprendre (étant donné quand alors) ou d’un tableau d’exemple ou de n’importe quoi d’autre, orienté comportement ou données attendues (si on veut que 1+1=4, ya sérieusement intérêt à le préciser, non ?). Ces critères sont émergeants, mis à jour tout au long du cycle de vie de la stry par l’équipe (dev po sm), parfois par ce qu’on pourrait appeler des PPO (responsables de processus opérationnels correspondant à des modules dans le produit). On se base dessus pour écrire les cas de test manuels ou automatisés. De mon point de vue on pourrait considérer l’ensemble (stry, ac et cases) comme des spécifications, ce qu’on appelle le ‹ cahier des charges › qui défini le périmètre et qu’on fige en approches traditionnelles.
Pour les demande de mise en œuvre, on est sur des spécifications fournies par le demandeur, souvent selon un template et puis bon ben, on met en œuvre quoi, on ne cherche pas une solution à une problématique. La mise à jour de spécifications a rarement lieu ça dépend de ce à quoi elles pourraient bien servir.
Toutes ces stry ont des tâches, autant qu’on veut d’ailleurs, mais par défaut on a au moins ‹ coding ›, ‹ crosstesting › et ‹ documentation › (et aussi un petite nouvelle qu’on vient de planter qui cause de gestion des tests automatisés, pour infos pour ceux qui connaissent un peu l’équipe, au travers mes récits ici et ailleurs 
, on arrose, ça pousse 
) Donc dans notre workflow, on a un bout de DoD sur la tâche coding qui concerne l’alimentation de la tâche documentation, histoire de mettre au chaud les éléments qui rentrerons effectivement dans la doc. Avant que ce soit done pratiquement tout peu bouger jusqu’à très tard, donc on maintien tout ça, jusqu’à ce que les tests soient ok. Là on a une autre partie de la DoD sur la stry dont un critère qui cause de faire la mise à jour effective de la doc dans le fichier (word pour le coup, le plus souvent).
Pour les mises en œuvre, il n’y a pas toujours de la doc, surtout pour les trucs récurrents, la doc, c’est le produit (= extraction bien pensée, par exemple).
Par contre pour les autres, plus souvent, ces docs elles sont appelées ’ spécifications technico fonctionnelles’… Voilà ya un peu tout dedans pour comprendre comment est monté le produit (technique) compte tenu de son contexte (fonctionnel). On essaie de la restreindre au minimum nécessaire et d’y passer le moins de temps possible. C’est ce qui se rapproche le plus de la vision globale dont tu parles.
Nous avons résorbé notre dette de documentation, pour ce faire, il nous est arrivé de créer des stry typées dette et de les embarquer dans les sprints pour y consacrer du temps en parallèle ou en plus de l’objectif, selon les possibilités, mais ce qui a compté surtout, c’est de l’inclure dans la DoD et de s’y tenir (évidemment, non ?). Et franchement, c’est aussi plus agréable à faire au fur et à mesure
En ce moment, nous avons un sujet un peu plus itératif qu’incrémental pour lequel nous avons réalisé un découpage à plus haut niveau (Epic > sous Epic > stry > tâches) et dans ce contexte nous avons une stry de documentation qui est alimentée au fur et a mesure (la tâche de doc sur chaque stry n’avait pas de sens, nous avons adapté temporairement cette partie, la DoD est toujours respectée (les critères sont orientés ‹ faire si nécessaire ›, l’équipe juge de la nécessité).
Pour ce sujet, nous avons eu des spécifications encore un autre genre, un doc arrêté, mode bon vieux cycle en V avec fourniture d’un chiffrage, des règles, des tableaux, des schémas pas toujours très compréhensibles, des choses qui manquent, qui ne sont pas claires et qui vont changer tout ça tout ça… heureusement qu’on ne fait pas une mise en oeuvre ‹ bête et méchante › ! 
C’est loin d’être Scrum, mais c’est notre contexte actuel, vivement la reprise lol Bref c’est un autre type de spécifications. Et spoiler alert, on ne gardera pas cette spec 
Donc des spécifications ça revêt plusieurs formes pour moi, plusieurs usages aussi et tout cela dépend du contexte. Le plus important, c’est que cela ne fasse pas de l’ombre aux interactions, que le produit fonctionne avant tout, qu’il y ai le moins possible de gaspillage, que les docs répondent à un besoin avéré…
Bon et moi j’aimerai bien encore plus capitaliser autour des ac, test, specs… et je dois absolument trouver du temps pour la living documentation et aussi ces fameux use case dont @Samuel_Abiassi nous parle de temps en temps (
). J’ai tellement peu de temps, cela demande beaucoup d’investissement de découvrir un nouveau sujet, si seulement il y avait quelqu’un qui connaissait bien le sujet, on pourrait en faire un partage d’expérience, une présentation, un quelque chose, je suis persuadée que ca apporterait de la valeur à la communauté (je pose ça ici quelque fois que ça ne tombe pas dans l’oreille d’un sourd )
Je vais finir par le faire, vu que @jplambert ne semble pas répondre à nos requêtes… 
Bonjour,
C’est amusant de faire des spécifications. Comme ça tout le monde sait à l’avance ce qu’il a faire. On peut même ensuite planifier le travail avec des dates, gérer les dépendances et tout …
En fait c’était cool le mode projet.
Pourquoi avez-vous besoin de spécifications ?
Est-ce qu’un document de x pages, n détails, permettra d’avoir une vision globale ?
Est-ce du gaspillage de le maintenir à jour si personne ne va lire avant mon remplacement ?
…
Mode produit vs Mode Projet, quelle différence ?
Comment je m’autorise à explorer des solutions si tout est déjà défini ?
C’est amusant de pas du tout savoir ce qu’il y a à faire. On peut ensuite partir dans des directions qui n’apporte aucune valeur et en plus sans que personne ne soit aligné ni sur le pourquoi, ni sur le comment. On peut même ensuite balancer de l’argent par les fenêtres au nom de « l’agilité » et n’avoir aucun sens de ce que Lean veux dire.
Je taquine, mais l’argumentaire est quand même assez grossier.
Si on reste dans le scope de 1 à 3 pages et un niveau de détails plutôt haut niveau, oui. Et je te mets au défi de me prouver le contraire.
Oui c’est du gaspillage, mais seulement post-implémentation, et seulement si le code ne permet pas de documenter à lui seul le use-case. (BDD, DCI…)
Si tout est défini, on est clairement pas sur du produit à priori. Pas sûr de comprendre la question dans ce scope.
Par ailleurs, pour l’exploration de solution, on a plusieurs textes du côté du Lean qui vont dans le sens qu’une approche itérative est sous-efficiente vs une approche Set-based.
Je comprends l’intention, mais ça penche un peu trop dans l’autre sens effectivement.
Samuel, aurais-tu tu le mal de mer ? 
Le mégalodon n’est pas loin.
Pour comprendre la blague, voir ce sujet :