Oui.

Si on applique la méthode correctement, les systèmes Agile créent des stories.

La plupart d’entre elles peuvent au moins devenir des candidats pour la documentation. Ces stories peuvent aussi permettre au responsable produit ou au chef de projet de décider si la documentation est nécessaire.

Transformer les stories utilisateur en topics orientés tâche

Dans un environnement Agile, le développement est orienté par les stories utilisateurs qui définissent les tâches que les utilisateurs finaux souhaitent faire dans le logiciel. Les stories utilisateurs doivent être centrées sur le client, succinctes, et pouvant être testées. Aussi, les rédacteurs peuvent s’en servir comme levier pour créer de la documentation orientée tâches et centrée sur les utilisateurs. La rédaction orientée tâches complète non seulement l’utilisation des stories utilisateurs dans le développement, mais est aussi une nécessité absolue si l’on considère la courte durée des cycles itératifs et le nombre de ressources rédactionnelles souvent limité. Les conditions nécessaires pour créer de l’information sur l’installation et sur la configuration ainsi que des procédures solides (probablement dans un système d’aide en ligne) laissent souvent peu de temps, dans n’importe quel cycle de production, pour construire de l’information conceptuelle ou des bonnes pratiques. Cependant, ce type d’information peut être produit en suivant un cycle de production particulier. Dans un cycle, l’accent mis sur les tâches aide les rédacteurs à écrire de façon minimaliste, une autre technique particulièrement appropriée pour faire de la documentation en environnement Agile.

Documenter au bon moment signifie aussi documenter juste ce qui est nécessaire

Le minimalisme en rédaction technique a été prôné depuis que John Carroll de chez IBM a écrit The Nurnberg Funnel: Designing Minimalist Instruction for Practical Computer Skill Minimalism, en 1990. Les principes du minimalisme sont particulièrement pertinents quand vous adaptez les méthodes Agile pour produire de la documentation qui complète le développement logiciel à la fin de courtes itérations. Par exemple, il faut éviter les longues vues d’ensemble qui ne sont pas orientées taches, ou les procédures évidentes comme le copier-coller de texte ou l’impression de documents.

Tiré de : http://justwriteclick.com/2007/07/02/writing-end-user-documentation-in-an-agile-development-environment/

Comment les méthodes agile peuvent-elles aider ?

  • les méthodes agiles comportent des spécifications
  • un responsable produit sait où il va
  • si correctement appliquées:
    • les méthodes agile permettent la création de stories
    • les méthodes agile permettent l’utilisation de cas de test

Beaucoup de ces éléments peuvent devenir, à minima, des candidats pour intégrer la documentation. Ces stories peuvent aussi permettre à un responsable produit ou un chef de projet de décider s’il est nécessaire de documenter.

la question c’est : comment ?  Vous devez avoir une stratégie et les outils adéquats.

Premièrement, la stratégie. Vous avez besoin d’une stratégie éditoriale. Ce sont les spécifications de la partie Documentation du projet informatique. Elles définissent les ambitions, le cadre et le niveau de complexité de ce qui doit être produit. Ceci implique des concepts tels que :

  • demandez-vous si ce qui est écrit  est indispensable. Mieux, demandez au support ou à un utilisateur connu. Assurez- vous de comprendre les besoins des utilisateurs.
  • ne rédiger que dans un cadre qui peut être maintenu. Trop écrire est contre productif.
  • documenter en priorité ce qui est essentiel. Par exemple, documenter une des fenêtres principales n’apporte peut être pas de valeur ajoutée.
  • Just Barely Good Enough (JBGE). C’est le premier niveau d’objectifs. Tout le reste sera suggéré par un cycle de validation, des commentaires utilisateurs ou d’autres formes de retours.
  • faites le en temps et en heure – avant la fin d’un sprint ou au pire, avant la fin de la release
  • regardez ce que signifie YAGNI et gardez le en tête (You Aren’t Going to Need It)
  • rappelez-vous de IBTN (It’s Better Than Nothing)

Impliquez les développeurs. Oui. Ils ont un rôle dans la documentation. Ils ont codé le logiciel donc ils le connaissent. Ils n’ont peut être pas les meilleures compétences rédactionnelles, mais c’est mieux que rien et cela peut servir de base.

Rappelez-vous le in-situ. Construisez la documentation de manière incrémentale (Ecrire la documentation de façon incrémentale). Mettez-vous à la place de l’utilisateur. Prenez en compte le contexte (Qu’entendons-nous par documentation contextuelle ?).

Un pas plus haut. Quand l’utilisateur a lu l’essentiel, que doit-il savoir de plus ? Des sujets connexes, que nous divisons en How-to (procédures), explications de concepts, et FAQs (de l’information formulée en questions qu’il sera susceptible de se poser).

 

Quand peut-on commencer la documentation utilisateur ?

Tôt. Voir Quand faut-il commencer à rédiger la documentation utilisateur ?

 

Qui peut écrire ?

Si vous avez des rédacteurs techniques, formez les à la stratégie d’information en mode agile, en tant que techniciens ou managers. Si vous n’en avez pas, vous pourrez en impliquer en freelance, simplement pour affiner et nettoyer le contenu.

N’importe qui dans le projet peut contribuer.

Les équipes support ont une implication particulièrement utile. Si elles contribuent, elles obtiendront alors du contenu déja mis en forme pour leur usage futur.

 

Tests, relecture, et validation

Cela doit être fait au même rythme que pour le logiciel. Un dashboard peut aider.

 

Feedback

Le feedback est essentiel, non seulement pour pour garder la documentation à jour, mais aussi pour tester sa pertinence et mesurer la satisfaction des utilisateurs.