SlideShare une entreprise Scribd logo
1  sur  29
Télécharger pour lire hors ligne
Écrire de la
Documentation
Persistante pour un projet Drupal
Matthieu Gadrat
https://drupal.org/u/mgadrat
https://mgadrat.com
@mgadrat
Dans cette présentation
Pourquoi?
Qu’est-ce
qui ne marche
pas?
Comment?
Qu’est-ce
qu’on peut y
faire?
Quoi?
La
documentation
persistante
Dans cette présentation
● Un guide de rédaction
● La promotion d’un outil de document
● Des gifs amusant ( Par manque de temps )
Pourquoi?
Pourquoi produire de la doc?
Communiquer :
● Construire la BONNE CHOSE
● Faciliter l'entretien de ce qui a été construit
C’est quoi le problème avec la doc?
● Pas à jour?
● Qu’est-ce qui fait partie de la documentation ?
● Qui doit la faire / mettre à jour ?
● Quel niveau de détail ?
● Personne ne la lit !
● Différente de projet en projet !
● Différent documents se contredisent !
● Elle contient des éléments « Out of Scope »
Spoiler:
On ne fera pas de miracle ...
Comment ?
Évaluez l’effort de documentation
● Estimez le temps que vous passerez à produire
○ La documentation fonctionnelle (User stories etc.)
○ La documentation technique
○ Un manuel d’utilisateur / manuel d’installation
○ Maquettes / Wireframes / Workflows
○ Plan de test / Gestion de risques
● Technique d’estimation
○ À la pièce
○ % global du projet
Considérez les outils dans Drupal
● Simplifiez vos manuels d’utilisation avec des descriptions de champs clairs
● Construisez des contenus exemples
● Devs, utilisez les (.info.yml) pour expliquer le rôle d’un module et ses
dépendances
● Avez-vous entendu parler du « tour api? »
Planifiez la rédaction de documentation
● Maintenant que vous avez des chiffres
● Mettez-le à l'horaire !
● Ne planifiez pas toutes le heures au début du projet
Créez une vitrine de projet
● « One Pager » pour « on-boarder » l’équipe
● Doit expliquer
○ Où trouver « quoi »?
○ Comment utiliser la documentation?
○ À qui poser des questions?
Décidez QUI rédige
● Chacun son corps de métier
● Lors de la planification, soyez claire sur les livrables et les responsables de
ces livrables.
Évitez de faire rédiger la documentation fonctionnelle par la personne qui va
construire l’outil (le dev).
Présentez la documentation
● Ne faites pas juste envoyer la documentation aux destinataires
○ Personne ne va la lire
○ Ceux qui vont la lire ne vont rien retenir
○ Des questions cruciales ne seront pas posées
● Rencontrez-vous pour présenter la documentation !
Prévoyez l’évolution de la doc
● Ayez un processus pour permettre l’évolution de la doc qui est:
○ Simple
○ Permet à tout le monde de le faire
○ Permet l’approbation des correctifs rapidement
Désignez un concierge
● S'assurer régulièrement que:
○ Les processus sont respectés
○ La documentation est au bon endroit
○ Les meilleurs pratique de l’entreprise sont suivis
○ Les individus font bien le « ménage » derrière eux
● Peut être externe au projet
● S’il a des connaissances techniques peut aussi vérifier que les
« repos » sont en ordre.
Quoi ?
( On y arrive finalement, la documentation elle-même )
Choisir le type de documentation
● Il y en a des tonnes (stratégique, technique, fonctionnelle, etc.)
● S’entendre au début du projet sur ce qui sera utile
● Prendre conscience de documentations jetables vs persistantes
● 80 / 20 : + de valeur = + doc
● Un document est un livrable en soit, même si c’est pour l’interne
● N’oubliez pas les besoins de votre équipe
Ex: Un dev à besoin de savoir comment installer un projet sur son ordinateur.
Exemple de type de documentation
● Arborescence
● Wireframe
● Mockups
● Ui-Kit
● Copy Deck
● Maquettes
● Diagramme de systèmes
d’information
● Workflows (ANSI / UML)
● Requis fonctionnels
● Requis non-fonctionnels
● User Stories
● ...
● User Stories
● Plan de test
● Plan de gestion du risque
● Issues: Todo, bug, feedback
● Manuel d’installation
● Manuel d’utilisation
● Diagramme de DB
● Diagramme de Classes
● Processus de déploiement
● Contacts
● ...
« In App » Drupal
● Aide
● Tooltips
● Description des champs
● Description des modules
● Inscriptions du « Status Page »
● ...
Écrivez de la documentation facile à maintenir
● DRY (Do not Repeat Yourself)
● Indiquez clairement ce qui n’est pas utile dans un document
ex: « Ne pas se fier au texte dans cette maquette »
● Favorisez des « bullet point » lorsque c’est possible.
● Ne pas mélanger de la documentation « jetable » avec de la documentation
« persistante »
ex: Une description fonctionnelle et une tâche
Parlons des User Stories 1/2
● C’est bon pour
○ Démarrer une conversation
○ Comprendre le contexte d’une fonctionnalité, couvre les besoins
○ Parler du parcours d’un utilisateur
○ Point de départ des plans de test
● C’est moins bon pour
○ Dire à un dev ce qu’il faut construire
○ Requis non-fonctionnel (Sécurité, performance, etc. )
○ Énumérer des choses
Si c’est mal écrit, ça sonne bizarre...
Parlons des User Stories 2 / 2
● Oui, c’est juste un phrase, mais voyez la comme un titre
Titre: En tant que « rôle », je peux « action » afin de « but »
Description: Tous les détails de ce que ça implique.
● Utilisez-les pour grouper des spécifications
● N’oubliez pas d’y joindre tous les détails nécessaires pour les devs
● Gardez les titre courts, gardez les détails pour la description
Un User Story =
Persistant Jetable
Une tâche
Parlons des User Stories 3 / 2
User story:
En tant qu’éditeur je peux rétablir une version antérieure d’un article afin de
corriger une modification accidentelle.
Tâche:
Activer les révisions sur les articles pour les éditeurs.
Parlons des User Stories 4 / 2
User story:
En tant qu’éditeur je peux rétablir une version antérieure d’un article afin de
corriger une modification accidentelle.
Tâche (bogue):
Les éditeurs peuvent voir les révisions,
mais il ne peuvent pas les rétablir.
Choisir un outil de documentation
● Joue un rôle de « HUB »
● Versionnés
● Statuts
● Commentaires
● Facile à mettre à jour
● Séparer le jetable du persistant
● Faire des liens entre les documents
● Faire des liens vers des outils externes ex: Mockups, invision etc.
● N’est pas WORD
En résumé....
● Évaluez et planifiez l’effort et l’évolution de documentation
● Considérez les outils dans Drupal
● Créez une vitrine de projet
● Présentez la documentation
● Favorisez la documentation facile à maintenir
(même si c’est moins beau)
● Faites des choix éclairés
(Type de document, outil de documentation, etc.)
Questions ?
https://drupal.org/u/mgadrat
https://mgadrat.com
@mgadrat

Contenu connexe

Similaire à Écrire de la documentation persistante pour un projet Drupal

Projet Confluence - Une base de données de type Wiki
Projet Confluence - Une base de données de type WikiProjet Confluence - Une base de données de type Wiki
Projet Confluence - Une base de données de type WikiMylneRoffi
 
Design systems : Bench et reco sur les outils
Design systems : Bench et reco sur les outilsDesign systems : Bench et reco sur les outils
Design systems : Bench et reco sur les outilsIdean France
 
Introduction à Scrum et aux méthodes agiles (v1.0)
Introduction à Scrum et aux méthodes agiles (v1.0)Introduction à Scrum et aux méthodes agiles (v1.0)
Introduction à Scrum et aux méthodes agiles (v1.0)Blackbird
 
Cours Devops Sparks.pptx.pdf
Cours Devops Sparks.pptx.pdfCours Devops Sparks.pptx.pdf
Cours Devops Sparks.pptx.pdfboulonvert
 
Presentation du socle technique Java open source Scub Foundation
Presentation du socle technique Java open source Scub FoundationPresentation du socle technique Java open source Scub Foundation
Presentation du socle technique Java open source Scub FoundationStéphane Traumat
 
Pourquoi la documentation compte ?
Pourquoi la documentation compte ?Pourquoi la documentation compte ?
Pourquoi la documentation compte ?sarahhaim shl
 
Introduction scrum v0.7
Introduction scrum v0.7Introduction scrum v0.7
Introduction scrum v0.7CClr
 
Des poneys à Liberation.fr
Des poneys à Liberation.frDes poneys à Liberation.fr
Des poneys à Liberation.frliberation_dev
 
Presentation du Livre Django Avancé
Presentation du Livre Django AvancéPresentation du Livre Django Avancé
Presentation du Livre Django AvancéYohannGabory
 
Créer un site web ? Méthode illustrée par la médiathèque de Roubaix - PARTIE 1
Créer un site web ? Méthode illustrée par la médiathèque de Roubaix - PARTIE 1Créer un site web ? Méthode illustrée par la médiathèque de Roubaix - PARTIE 1
Créer un site web ? Méthode illustrée par la médiathèque de Roubaix - PARTIE 1Médiathèque de Roubaix - La Grand-Plage
 
Panels, une autre façon de construire. DrupalCamp Paris 2013
Panels, une autre façon de construire. DrupalCamp Paris 2013Panels, une autre façon de construire. DrupalCamp Paris 2013
Panels, une autre façon de construire. DrupalCamp Paris 2013bellesmanieres
 
Sketch pour les designers : pourquoi, quand et comment l'utiliser ?
Sketch pour les designers : pourquoi, quand et comment l'utiliser ?Sketch pour les designers : pourquoi, quand et comment l'utiliser ?
Sketch pour les designers : pourquoi, quand et comment l'utiliser ?Idean France
 
Meetup WordPress Lyon #3 : Bien organiser son code dans WordPress.
Meetup WordPress Lyon #3 : Bien organiser son code dans WordPress.Meetup WordPress Lyon #3 : Bien organiser son code dans WordPress.
Meetup WordPress Lyon #3 : Bien organiser son code dans WordPress.wplyon
 
Le gameday...un concept devopsludique
Le gameday...un concept devopsludiqueLe gameday...un concept devopsludique
Le gameday...un concept devopsludiqueEspritAgile
 
Le product designer by Thiga
Le product designer by ThigaLe product designer by Thiga
Le product designer by ThigaThiga
 

Similaire à Écrire de la documentation persistante pour un projet Drupal (20)

Projet Confluence - Une base de données de type Wiki
Projet Confluence - Une base de données de type WikiProjet Confluence - Une base de données de type Wiki
Projet Confluence - Une base de données de type Wiki
 
Design systems : Bench et reco sur les outils
Design systems : Bench et reco sur les outilsDesign systems : Bench et reco sur les outils
Design systems : Bench et reco sur les outils
 
WPB Producer 4
WPB Producer 4WPB Producer 4
WPB Producer 4
 
Breizh campux
Breizh campuxBreizh campux
Breizh campux
 
Introduction à Scrum et aux méthodes agiles (v1.0)
Introduction à Scrum et aux méthodes agiles (v1.0)Introduction à Scrum et aux méthodes agiles (v1.0)
Introduction à Scrum et aux méthodes agiles (v1.0)
 
Cours Devops Sparks.pptx.pdf
Cours Devops Sparks.pptx.pdfCours Devops Sparks.pptx.pdf
Cours Devops Sparks.pptx.pdf
 
Presentation du socle technique Java open source Scub Foundation
Presentation du socle technique Java open source Scub FoundationPresentation du socle technique Java open source Scub Foundation
Presentation du socle technique Java open source Scub Foundation
 
Pourquoi la documentation compte ?
Pourquoi la documentation compte ?Pourquoi la documentation compte ?
Pourquoi la documentation compte ?
 
Introduction scrum v0.7
Introduction scrum v0.7Introduction scrum v0.7
Introduction scrum v0.7
 
Etude materiel
Etude materielEtude materiel
Etude materiel
 
Des poneys à Liberation.fr
Des poneys à Liberation.frDes poneys à Liberation.fr
Des poneys à Liberation.fr
 
Presentation du Livre Django Avancé
Presentation du Livre Django AvancéPresentation du Livre Django Avancé
Presentation du Livre Django Avancé
 
Créer un site web ? Méthode illustrée par la médiathèque de Roubaix - PARTIE 1
Créer un site web ? Méthode illustrée par la médiathèque de Roubaix - PARTIE 1Créer un site web ? Méthode illustrée par la médiathèque de Roubaix - PARTIE 1
Créer un site web ? Méthode illustrée par la médiathèque de Roubaix - PARTIE 1
 
Panels, une autre façon de construire. DrupalCamp Paris 2013
Panels, une autre façon de construire. DrupalCamp Paris 2013Panels, une autre façon de construire. DrupalCamp Paris 2013
Panels, une autre façon de construire. DrupalCamp Paris 2013
 
Agile Methodologies
Agile MethodologiesAgile Methodologies
Agile Methodologies
 
Sketch pour les designers : pourquoi, quand et comment l'utiliser ?
Sketch pour les designers : pourquoi, quand et comment l'utiliser ?Sketch pour les designers : pourquoi, quand et comment l'utiliser ?
Sketch pour les designers : pourquoi, quand et comment l'utiliser ?
 
Meetup WordPress Lyon #3 : Bien organiser son code dans WordPress.
Meetup WordPress Lyon #3 : Bien organiser son code dans WordPress.Meetup WordPress Lyon #3 : Bien organiser son code dans WordPress.
Meetup WordPress Lyon #3 : Bien organiser son code dans WordPress.
 
Le gameday...un concept devopsludique
Le gameday...un concept devopsludiqueLe gameday...un concept devopsludique
Le gameday...un concept devopsludique
 
DDD FOR POs.pdf
DDD FOR POs.pdfDDD FOR POs.pdf
DDD FOR POs.pdf
 
Le product designer by Thiga
Le product designer by ThigaLe product designer by Thiga
Le product designer by Thiga
 

Plus de Symetris

Hyperpersonnalisation des sites web et écosystèmes numériques - Les best prac...
Hyperpersonnalisation des sites web et écosystèmes numériques - Les best prac...Hyperpersonnalisation des sites web et écosystèmes numériques - Les best prac...
Hyperpersonnalisation des sites web et écosystèmes numériques - Les best prac...Symetris
 
How to maintain, evolve and maximize the return on your Drupal website invest...
How to maintain, evolve and maximize the return on your Drupal website invest...How to maintain, evolve and maximize the return on your Drupal website invest...
How to maintain, evolve and maximize the return on your Drupal website invest...Symetris
 
Should you upgrade your Drupal 7 website or migrate to Drupal 8?
Should you upgrade  your Drupal 7 website or  migrate to Drupal 8? Should you upgrade  your Drupal 7 website or  migrate to Drupal 8?
Should you upgrade your Drupal 7 website or migrate to Drupal 8? Symetris
 
Different approaches for different scopes: How to tackle a medium-sized Dr...
Different approaches for different scopes: How to tackle a medium-sized Dr...Different approaches for different scopes: How to tackle a medium-sized Dr...
Different approaches for different scopes: How to tackle a medium-sized Dr...Symetris
 
Trop gros pour des mercenaires, trop petit pour une armée: Comment s'attaquer...
Trop gros pour des mercenaires, trop petit pour une armée: Comment s'attaquer...Trop gros pour des mercenaires, trop petit pour une armée: Comment s'attaquer...
Trop gros pour des mercenaires, trop petit pour une armée: Comment s'attaquer...Symetris
 
Symetris présente Drupal 8 - Linux-Meetup (Montreal) 02/02/2016
Symetris présente Drupal 8 - Linux-Meetup (Montreal) 02/02/2016Symetris présente Drupal 8 - Linux-Meetup (Montreal) 02/02/2016
Symetris présente Drupal 8 - Linux-Meetup (Montreal) 02/02/2016Symetris
 
Les particularités de Drupal en gestion de projet: une histoire d’amour et de...
Les particularités de Drupal en gestion de projet: une histoire d’amour et de...Les particularités de Drupal en gestion de projet: une histoire d’amour et de...
Les particularités de Drupal en gestion de projet: une histoire d’amour et de...Symetris
 
Personnaliser l'interface administrateur de Drupal - DrupalCamp Montreal 2014
Personnaliser l'interface administrateur de Drupal - DrupalCamp Montreal 2014Personnaliser l'interface administrateur de Drupal - DrupalCamp Montreal 2014
Personnaliser l'interface administrateur de Drupal - DrupalCamp Montreal 2014Symetris
 
Symetris ambiance
Symetris ambianceSymetris ambiance
Symetris ambianceSymetris
 
WTF: Where To Focus when you take over a Drupal project
WTF: Where To Focus when you take over a Drupal projectWTF: Where To Focus when you take over a Drupal project
WTF: Where To Focus when you take over a Drupal projectSymetris
 
Présentation Symetris - Drupalcamp Montreal 2013 le diable est dans les détails
Présentation Symetris - Drupalcamp Montreal 2013 le diable est dans les détailsPrésentation Symetris - Drupalcamp Montreal 2013 le diable est dans les détails
Présentation Symetris - Drupalcamp Montreal 2013 le diable est dans les détailsSymetris
 
Mieux Filtrer ses listes WordPress avec Ajax et WP_Query
Mieux Filtrer ses listes WordPress avec Ajax et WP_QueryMieux Filtrer ses listes WordPress avec Ajax et WP_Query
Mieux Filtrer ses listes WordPress avec Ajax et WP_QuerySymetris
 
Générer plus de revenus par le web: Pouvez-vous faire mieux ?
Générer plus de revenus par le web: Pouvez-vous faire mieux ?Générer plus de revenus par le web: Pouvez-vous faire mieux ?
Générer plus de revenus par le web: Pouvez-vous faire mieux ?Symetris
 
Connecter Drupal à des API externes
Connecter Drupal à des API externesConnecter Drupal à des API externes
Connecter Drupal à des API externesSymetris
 

Plus de Symetris (14)

Hyperpersonnalisation des sites web et écosystèmes numériques - Les best prac...
Hyperpersonnalisation des sites web et écosystèmes numériques - Les best prac...Hyperpersonnalisation des sites web et écosystèmes numériques - Les best prac...
Hyperpersonnalisation des sites web et écosystèmes numériques - Les best prac...
 
How to maintain, evolve and maximize the return on your Drupal website invest...
How to maintain, evolve and maximize the return on your Drupal website invest...How to maintain, evolve and maximize the return on your Drupal website invest...
How to maintain, evolve and maximize the return on your Drupal website invest...
 
Should you upgrade your Drupal 7 website or migrate to Drupal 8?
Should you upgrade  your Drupal 7 website or  migrate to Drupal 8? Should you upgrade  your Drupal 7 website or  migrate to Drupal 8?
Should you upgrade your Drupal 7 website or migrate to Drupal 8?
 
Different approaches for different scopes: How to tackle a medium-sized Dr...
Different approaches for different scopes: How to tackle a medium-sized Dr...Different approaches for different scopes: How to tackle a medium-sized Dr...
Different approaches for different scopes: How to tackle a medium-sized Dr...
 
Trop gros pour des mercenaires, trop petit pour une armée: Comment s'attaquer...
Trop gros pour des mercenaires, trop petit pour une armée: Comment s'attaquer...Trop gros pour des mercenaires, trop petit pour une armée: Comment s'attaquer...
Trop gros pour des mercenaires, trop petit pour une armée: Comment s'attaquer...
 
Symetris présente Drupal 8 - Linux-Meetup (Montreal) 02/02/2016
Symetris présente Drupal 8 - Linux-Meetup (Montreal) 02/02/2016Symetris présente Drupal 8 - Linux-Meetup (Montreal) 02/02/2016
Symetris présente Drupal 8 - Linux-Meetup (Montreal) 02/02/2016
 
Les particularités de Drupal en gestion de projet: une histoire d’amour et de...
Les particularités de Drupal en gestion de projet: une histoire d’amour et de...Les particularités de Drupal en gestion de projet: une histoire d’amour et de...
Les particularités de Drupal en gestion de projet: une histoire d’amour et de...
 
Personnaliser l'interface administrateur de Drupal - DrupalCamp Montreal 2014
Personnaliser l'interface administrateur de Drupal - DrupalCamp Montreal 2014Personnaliser l'interface administrateur de Drupal - DrupalCamp Montreal 2014
Personnaliser l'interface administrateur de Drupal - DrupalCamp Montreal 2014
 
Symetris ambiance
Symetris ambianceSymetris ambiance
Symetris ambiance
 
WTF: Where To Focus when you take over a Drupal project
WTF: Where To Focus when you take over a Drupal projectWTF: Where To Focus when you take over a Drupal project
WTF: Where To Focus when you take over a Drupal project
 
Présentation Symetris - Drupalcamp Montreal 2013 le diable est dans les détails
Présentation Symetris - Drupalcamp Montreal 2013 le diable est dans les détailsPrésentation Symetris - Drupalcamp Montreal 2013 le diable est dans les détails
Présentation Symetris - Drupalcamp Montreal 2013 le diable est dans les détails
 
Mieux Filtrer ses listes WordPress avec Ajax et WP_Query
Mieux Filtrer ses listes WordPress avec Ajax et WP_QueryMieux Filtrer ses listes WordPress avec Ajax et WP_Query
Mieux Filtrer ses listes WordPress avec Ajax et WP_Query
 
Générer plus de revenus par le web: Pouvez-vous faire mieux ?
Générer plus de revenus par le web: Pouvez-vous faire mieux ?Générer plus de revenus par le web: Pouvez-vous faire mieux ?
Générer plus de revenus par le web: Pouvez-vous faire mieux ?
 
Connecter Drupal à des API externes
Connecter Drupal à des API externesConnecter Drupal à des API externes
Connecter Drupal à des API externes
 

Écrire de la documentation persistante pour un projet Drupal

  • 3. Dans cette présentation Pourquoi? Qu’est-ce qui ne marche pas? Comment? Qu’est-ce qu’on peut y faire? Quoi? La documentation persistante
  • 4. Dans cette présentation ● Un guide de rédaction ● La promotion d’un outil de document ● Des gifs amusant ( Par manque de temps )
  • 6. Pourquoi produire de la doc? Communiquer : ● Construire la BONNE CHOSE ● Faciliter l'entretien de ce qui a été construit
  • 7. C’est quoi le problème avec la doc? ● Pas à jour? ● Qu’est-ce qui fait partie de la documentation ? ● Qui doit la faire / mettre à jour ? ● Quel niveau de détail ? ● Personne ne la lit ! ● Différente de projet en projet ! ● Différent documents se contredisent ! ● Elle contient des éléments « Out of Scope »
  • 8. Spoiler: On ne fera pas de miracle ...
  • 10. Évaluez l’effort de documentation ● Estimez le temps que vous passerez à produire ○ La documentation fonctionnelle (User stories etc.) ○ La documentation technique ○ Un manuel d’utilisateur / manuel d’installation ○ Maquettes / Wireframes / Workflows ○ Plan de test / Gestion de risques ● Technique d’estimation ○ À la pièce ○ % global du projet
  • 11. Considérez les outils dans Drupal ● Simplifiez vos manuels d’utilisation avec des descriptions de champs clairs ● Construisez des contenus exemples ● Devs, utilisez les (.info.yml) pour expliquer le rôle d’un module et ses dépendances ● Avez-vous entendu parler du « tour api? »
  • 12. Planifiez la rédaction de documentation ● Maintenant que vous avez des chiffres ● Mettez-le à l'horaire ! ● Ne planifiez pas toutes le heures au début du projet
  • 13. Créez une vitrine de projet ● « One Pager » pour « on-boarder » l’équipe ● Doit expliquer ○ Où trouver « quoi »? ○ Comment utiliser la documentation? ○ À qui poser des questions?
  • 14. Décidez QUI rédige ● Chacun son corps de métier ● Lors de la planification, soyez claire sur les livrables et les responsables de ces livrables. Évitez de faire rédiger la documentation fonctionnelle par la personne qui va construire l’outil (le dev).
  • 15. Présentez la documentation ● Ne faites pas juste envoyer la documentation aux destinataires ○ Personne ne va la lire ○ Ceux qui vont la lire ne vont rien retenir ○ Des questions cruciales ne seront pas posées ● Rencontrez-vous pour présenter la documentation !
  • 16. Prévoyez l’évolution de la doc ● Ayez un processus pour permettre l’évolution de la doc qui est: ○ Simple ○ Permet à tout le monde de le faire ○ Permet l’approbation des correctifs rapidement
  • 17. Désignez un concierge ● S'assurer régulièrement que: ○ Les processus sont respectés ○ La documentation est au bon endroit ○ Les meilleurs pratique de l’entreprise sont suivis ○ Les individus font bien le « ménage » derrière eux ● Peut être externe au projet ● S’il a des connaissances techniques peut aussi vérifier que les « repos » sont en ordre.
  • 18. Quoi ? ( On y arrive finalement, la documentation elle-même )
  • 19. Choisir le type de documentation ● Il y en a des tonnes (stratégique, technique, fonctionnelle, etc.) ● S’entendre au début du projet sur ce qui sera utile ● Prendre conscience de documentations jetables vs persistantes ● 80 / 20 : + de valeur = + doc ● Un document est un livrable en soit, même si c’est pour l’interne ● N’oubliez pas les besoins de votre équipe Ex: Un dev à besoin de savoir comment installer un projet sur son ordinateur.
  • 20. Exemple de type de documentation ● Arborescence ● Wireframe ● Mockups ● Ui-Kit ● Copy Deck ● Maquettes ● Diagramme de systèmes d’information ● Workflows (ANSI / UML) ● Requis fonctionnels ● Requis non-fonctionnels ● User Stories ● ... ● User Stories ● Plan de test ● Plan de gestion du risque ● Issues: Todo, bug, feedback ● Manuel d’installation ● Manuel d’utilisation ● Diagramme de DB ● Diagramme de Classes ● Processus de déploiement ● Contacts ● ... « In App » Drupal ● Aide ● Tooltips ● Description des champs ● Description des modules ● Inscriptions du « Status Page » ● ...
  • 21. Écrivez de la documentation facile à maintenir ● DRY (Do not Repeat Yourself) ● Indiquez clairement ce qui n’est pas utile dans un document ex: « Ne pas se fier au texte dans cette maquette » ● Favorisez des « bullet point » lorsque c’est possible. ● Ne pas mélanger de la documentation « jetable » avec de la documentation « persistante » ex: Une description fonctionnelle et une tâche
  • 22. Parlons des User Stories 1/2 ● C’est bon pour ○ Démarrer une conversation ○ Comprendre le contexte d’une fonctionnalité, couvre les besoins ○ Parler du parcours d’un utilisateur ○ Point de départ des plans de test ● C’est moins bon pour ○ Dire à un dev ce qu’il faut construire ○ Requis non-fonctionnel (Sécurité, performance, etc. ) ○ Énumérer des choses Si c’est mal écrit, ça sonne bizarre...
  • 23. Parlons des User Stories 2 / 2 ● Oui, c’est juste un phrase, mais voyez la comme un titre Titre: En tant que « rôle », je peux « action » afin de « but » Description: Tous les détails de ce que ça implique. ● Utilisez-les pour grouper des spécifications ● N’oubliez pas d’y joindre tous les détails nécessaires pour les devs ● Gardez les titre courts, gardez les détails pour la description
  • 24. Un User Story = Persistant Jetable Une tâche
  • 25. Parlons des User Stories 3 / 2 User story: En tant qu’éditeur je peux rétablir une version antérieure d’un article afin de corriger une modification accidentelle. Tâche: Activer les révisions sur les articles pour les éditeurs.
  • 26. Parlons des User Stories 4 / 2 User story: En tant qu’éditeur je peux rétablir une version antérieure d’un article afin de corriger une modification accidentelle. Tâche (bogue): Les éditeurs peuvent voir les révisions, mais il ne peuvent pas les rétablir.
  • 27. Choisir un outil de documentation ● Joue un rôle de « HUB » ● Versionnés ● Statuts ● Commentaires ● Facile à mettre à jour ● Séparer le jetable du persistant ● Faire des liens entre les documents ● Faire des liens vers des outils externes ex: Mockups, invision etc. ● N’est pas WORD
  • 28. En résumé.... ● Évaluez et planifiez l’effort et l’évolution de documentation ● Considérez les outils dans Drupal ● Créez une vitrine de projet ● Présentez la documentation ● Favorisez la documentation facile à maintenir (même si c’est moins beau) ● Faites des choix éclairés (Type de document, outil de documentation, etc.)

Notes de l'éditeur

  1. Symetris, partenaire numérique, en affaire depuis 2004 Commandite les Drupal Camp Montréal et Ottawa depuis plusieurs années
  2. Pourquoi: Prendre du recule pour nous rappeler les objectifs Comment: Stratégies plus haut niveau pour y arriver Quoi: Tactique, outils et détails
  3. Il se peut que je donne des exemple d’outils (Jira, Redmine, Confluence, DocuWiki, Git etc…) But seriously, do not use word
  4. Représentation de quelquechose d’autre “ceci n’est pas une pipe” Connaître la progression du projet Communiquer à travers l’équipe des changements Faire du contrôle Qualité etc. etc.
  5. Ask the audience
  6. Je n’ai jamais vue un projet dans lequelle toutes les astuces qui suivent sont 100% respectées mais même appliqué individuellement, cela a mené à des bénéfices significatifs
  7. À propos des estimer: Tout le monde est mauvais pour estimer (Présentation séparé) Vous voulez être transparent et ajuster le livrable en fonction du besoin du client
  8. Gant? Calendrier? Dépendance d’issue? Assurez vous de la planifier. Tenez compte des feedbacks etc.
  9. Gant? Calendrier? Dépendance d’issue? Assurez vous de la planifier. Tenez compte des feedbacks etc.
  10. Gant? Calendrier? Dépendance d’issue? Assurez vous de la planifier. Tenez compte des feedbacks etc.
  11. Probablement la 1 chose à retenir C’est ce qui a améliorer le plus les arrimages à l’intérieur de l’équipe et la compréhension des clients.
  12. Ex: Le dev a une contrainte technique qui l’empêche d'accommoder le nom du champ prévu par l’analyste.
  13. Concept expérimental chez Symetris
  14. Concept expérimental chez Symetris
  15. Concept expérimental chez Symetris
  16. DRY: Favorisez les liens, même vers la doc de Drupal.or par exemple Bullet point VS Document Visio pour un pocessus
  17. Bullet point VS Document Visio pour un pocessus
  18. Bullet point VS Document Visio pour un pocessus
  19. Bullet point VS Document Visio pour un pocessus
  20. Bullet point VS Document Visio pour un pocessus
  21. Bullet point VS Document Visio pour un pocessus
  22. Bullet point VS Document Visio pour un pocessus
  23. Bullet point VS Document Visio pour un pocessus