Manuels - À jour?

Si vous avez un produit sur le marché depuis longtemps, mais qu'il est toujours en développement actif quotidiennement - à quelle fréquence les manuels doivent-ils être mis à jour? Si vos utilisateurs sont constamment mis à jour vers la version de pointe en raison du fait que votre organisation juge bon que les dernières corrections de bogues soient toujours dans la version livrée. Cela signifie que vous pourriez corriger un bug un jour et le lendemain, il atteindrait la production.

Je mettrais à jour le manuel:

1. Pour chaque version majeure, et
2. Lorsque de nouvelles fonctionnalités importantes deviennent suffisamment stables et matures pour que vous sachiez qu'elles ne changeront pas toutes les cinq minutes.

mettre à jour le manuel (PDF) à chaque fois qu'un changement de code modifierait les instructions du manuel - faites simplement la mise à jour de la partie manuelle du processus de publication

si les utilisateurs comptent sur le manuel pour leur dire comment utiliser le produit et que le produit change, alors il est logique que les sections pertinentes du manuel changent également

En 2010, parlons-nous encore de documentation imprimée? Pourquoi? ;)

Sérieusement, la documentation (soit l'aide à l'application "F1", le PDF ou la documentation en ligne) devrait faire partie de chaque version. Aucune excuse. C'est aussi simple que de «publier». En fait, l'OMI, il n'y a aucune excuse pour ne pas mettre à jour la documentation régulièrement (en ligne et PDF), même entre les versions, dès que les problèmes sont connus et corrigés. Il n'a pas besoin du même niveau d'assurance qualité - même pas proche.

Je suppose que vous parlez de documentation pour l'utilisateur final. Écrire de la documentation est une douleur dans le @ $$ et même si j'ai développé une technique pour me convaincre de l'inverse, j'ai toujours des problèmes avec ça. Voici comment j'essaye de le gérer:

Intégrez la mise à jour de la documentation dans votre DoD ( Définition du fait )

Cela garantira que votre documentation sera à jour à la fin de chaque user story.

Voici la définition du fait que nous avons écrit. J'ai essayé de conserver les formats originaux, donc vous avez l'idée. Il s'agit d'une page A4 placée sur le tableau blanc.

---------- 8 <------------ Couper ici ------------ 8 <----------

Le non négociable

Définition de «Terminé»

• Code avec une couverture de test unitaire de 80%, validé dans le référentiel

• Captures d'écran le cas échéant (1024x728, 395x281, 170x121 et 729x329)

• Descriptions des fonctionnalités, le cas échéant (50 caractères, 100 caractères)

• Documentation complète pour l'utilisateur final

• Quoi de neuf fichier correctement mis à jour

---------- 8 <------------ Couper ici ------------ 8 <----------

Bien sûr, vous pouvez ajouter un processus de révision dans la documentation. Nous l'avons, car aucun de nous n'est anglophone.

L'un des avantages de la définition de Terminé comme celui-ci est que votre produit peut être expédié à la fin de chaque user story.

Utilisez cette technique en combinaison avec celle-ci .

Dans mon organisation, nous avons généralement 3 types de versions:

1. Version d'ingénierie - essentiellement correctif pour certains clients spécifiques ou certaines fonctionnalités que seul un client particulier a demandé sur une base immédiate.
2. Version mineure - corrections de bugs, prise en charge incrémentielle
3. Version majeure - prise en charge de nouvelles fonctionnalités, etc.

Par définition, la version majeure doit disposer de la documentation pertinente en ligne et hors ligne. Notre système de suivi garantit que la documentation fait partie intégrante de la liste de contrôle.

Les versions mineures n'ont besoin de documentation que sur tout ce qui a été ajouté au niveau de la perception de l'utilisateur. Donc, si vous avez inclus une autre heuristique qui pourrait réduire la complexité du temps dans certains scénarios spécifiques, il peut ou non être un appel important à le mettre dans le pdf.

Les versions d'ingénierie pourraient se passer de documentation. Certaines notes d'utilisation informelle devraient être suffisantes pour commencer.

La documentation doit être synchronisée avec le logiciel que vous expédiez à un client. Tout autre mauvais appariement va vous poser des problèmes. Et si vous n'avez pas d'écrivain dans le personnel, essayez les entrepreneurs. Une fois que vous en avez trouvé un, gardez-le sur la retenue.