Meilleures pratiques de sauvegarde de documentation d’un projet TI

Il y a de bonnes et de meilleures pratiques de sauvegarde de documentation d’un projet TI; en TI comme en toute chose.

Dans les deux premiers billets de cette série sur la documentation d’un projet de développement TI, nous avons traité du « quoi » ou de ce qu’il faut documenter et du « comment » ou, si vous préférez, du format que l’on devrait utiliser.

Dans ce billet, nous ne traiterons pas du « pourquoi » mais bien du « où » sauvegarder la documentation d’un Projet TI.

Si vous pensez que ce billet sur la sauvegarde de documentation d’un projet TI est le parent pauvre des deux précédents, détrompez-vous.  Trop souvent la documentation d’un Projet TI n’est pas consultée parce qu’elle n’est pas facile d’accès et, pour les mêmes raisons, la documentation n’est souvent pas à jour.

Pour déterminer le bon endroit où sauvegarder la documentation de votre Projet TI, il faut tenir compte de 3 facteurs :

• Quelle est la documentation à rendre accessible ?
• Qui sont les utilisateurs ou lecteurs ?
• Quelle est la fréquence d’utilisation (lecture et mise à jour) ?

Les outils de sauvegarde de documentation de projet TI ne sont pas tous égaux

Reprenons les documents mentionnés dans les billets précédents :

• Les standards de conception et de réalisation de l’organisation: Pendant des années, nous avons sauvegardé ces documents, généralement sous format Word, dans notre bibliothèque d’entreprise qui s’appuyait sur SharePoint.  Lors de la dernière optimisation de nos méthodes et processus, nous avons décidé de rapprocher cette documentation des développeurs et nous l’avons transféré dans Visual Studio Team Services, dans un projet « Documentation », pour en faciliter l’accessibilité.
• Quant aux comptes-rendus de réunion, nous les sauvegardons aussi dans Visual Studio Team Services mais cette fois-ci dans le projet lui-même. De cette façon, ils sont disponibles à l’équipe de développement et au client qui a aussi accès à l’outil.
• Les exigences d’affaires et fonctionnelles qui sont sous le format Word pour permettre aux clients de facilement les éditer, sont eux aussi sauvegardés dans le projet créé dans Visual Studio Team Services.
• Évidemment une des fonctionnalités de VSTS est de permettre aux gestionnaires de planifier. Cette planification se fait donc à même l’outil.
• Évidemment toute la documentation générée par les développeurs eux-mêmes, que ce soit les notes dans le code, la documentation technique, les fichiers de design, tout est sauvegardé à même l’outil.
• Pour la documentation technique, une page du wiki est utilisée pour l’éditer.
• Finalement, pour faciliter l’accès à la documentation, dont celle qui est fréquemment utilisée, nous créons pour chaque projet de développement un wiki de projet qui nous permet de filtrer la documentation à exposer et de la rendre facilement disponible. On y retrouve :
  • un sommaire des réunions internes
  • une page contenant les liens aux fichiers Word des réunions externes
  • un tableau des « To-Do »

Conclusion

Il n’y a pas si longtemps chez Analystik, nous retrouvions de la documentation sur notre serveur de fichiers, notre bibliothèque d’entreprise, SharePoint et TFS (maintenant VSTS).

Afin de mieux faire vivre notre documentation de projet de développement, nous l’avons centralisé dans une même plateforme en distinguant ce qui est spécifique au projet et ce qui s’adresse à l’organisation.  De cette façon, tous les intervenants, autant internes qu’externes, y ont facilement accès et le format utilisé est généralement le meilleur pour chaque type d’usagers.

Bon projet de développement,

Denis Paul & Michel