1. Ecriture des stories dans ZenTao

Dans ZenTao, un modèle de story par défaut est proposé à tous les utilisateurs, c'est-à-dire

En tant que <type utilisateur>, je veux <diff érents objectifs> afin que <différents objectifs>.

Ce modèle est basé sur l'écriture de story d’utilisateur dans le développement Scrum, mais nous adoptons un concept relativement neutre.

Dans ce modèle, il y a trois facteurs, rôles, objectifs et raisons. Habituellement, les rôles et les raisons ont tendance à être ignorés, tandis que les objectifs ont fait l'objet de beaucoup d'attention. Cela posera des problèmes. Si les rôles ne sont pas définis, la conception et le positionnement des fonctions du produit seront affectés. Par conséquent, ce produit sera développé pour un seul rôle d'utilisateur, qui est pour le manager de produit qui a écrit des stories. De plus, les développeurs seront confus si les raisons de développement sont ignorées. Ils ne comprendraient pas pourquoi on leur demande de le faire, et il leur sera donc difficile de terminer les stories.

2. Principe d'INVEST pour les stories

À l'exception du modèle mentionné ci-dessus, vous pouvez également vous référer au principe d'Investissement lors de l'écriture d'une story. Reportez-vous à   https://en.wikipedia.org/wiki/INVEST_ (mnemonic) pour en savoir plus sur le principe d'INVEST.

I —— Indépendant

Une story d’utilisateur doit être indépendante de l'autre story d’utilisateur. Les stories interdépendantes rendraient assez difficile la planification, l'établissement des priorités et l'estimation. La dépendance peut être réduite grâce à la combinaison / subdivision des étages.

N —— Négociable

A user story should be negotiable. A story card should contain a brief introduction of the story, which is defined through meetings and discussions. A card which contains much information actually reduces the talking with clients.Une story d’utilisateur doit être négociable. Une carte de story doit contenir une brève introduction de la story, qui est définie au cours de réunions et de discussions. Une carte qui contient beaucoup d'informations réduit en fait les discussions avec les clients.

V —— Valuable

Chaque story d’utilisateur doit être précieuse pour les clients (à la fois les clients et les utilisateurs). Une façon de valoriser les stories d’utilisateurs est de laisser les clients les écrire. Une fois que les clients se rendront compte qu'une story d’utilisateur n'est pas contractuelle mais négociable, ils seront très disposés à les rédiger.

E —— Estimable

Les développeurs doivent estimer la story d’utilisateur afin de définir des priorités et de faire des plans. Mais ce qui fait qu'il est difficile pour les développeurs d'estimer, c'est le manque de connaissances pertinentes dans certains secteurs, qui pourrait être résolu par plus de communication; ou parce que la story est trop grande et devrait être subdivisée.

S —— Small

Une bonne story d’utilisateur doit être petite en termes de charge de travail et de description, et elle peut être réalisée par deux / trois personnes. Les stories d’utilisateurs plus importantes que la charge de travail de 2 à 3 personnes poseront des problèmes lorsqu'elles seront subdivisées et estimées.

T—— Testable

Les stories d’utilisateurs sont testables et peuvent être terminées par des tests. N'oubliez pas que les stories qui ne sont pas testables ne doivent pas être développées. Si vous ne pouvez pas tester les stories, vous ne saurez jamais quand elles peuvent être terminées. Un exemple de story d’utilisateur non testable est que le logiciel doit être convivial.

Une story d’utilisateur bien écrite est la base du développement Agile. Les stories doivent être indépendantes les unes des autres et pratiques pour la communication entre les développeurs et les utilisateurs. Dans le même temps, ils doivent être précieux pour les utilisateurs et aussi petits et clairs que possible pour les développeurs, ainsi que testables.

3. Différences entre une story un modèle de prototypage et un document de conception de story dans ZenTao

Dans la gestion de projet traditionnelle, de nombreux managers de produit utilisent des logiciels pour concevoir un prototype ou un document de conception de story complet. Ensuite, le modèle ou le document de prototypage est envoyé aux concepteurs pour la conception Web, puis aux développeurs pour le codage. Alors, quelles sont les relations et les différences entre les modèles de prototypage et les stories d’utilisateurs ?

• Par rapport aux stories d’utilisateurs, les modèles de prototypage ou les documents de conception de stories sont considérés comme une seule unité et compris au niveau macro. C'est très intuitif, ce qui est également l'avantage du prototypage de modèles.
• Puisqu'il s'agit d'une unité, il ne peut pas être divisé en une barre de navigation ou au milieu d'une page, etc.
• Puisqu'il ne peut pas être subdivisé, les priorités ne peuvent pas être définies dans les modèles de prototypage. Par exemple, certaines parties d'une page sont importantes tandis que d'autres ne le sont pas, dont les priorités ne peuvent pas être affichées dans les modèles de prototypage.
• Puisqu'il ne peut pas être subdivisé, vous ne pouvez pas suivre la progression des modèles de prototypage. Par conséquent, vous ne savez pas combien a été réalisé.
• Les modèles de prototypage ne sont pas flexibles, ce qui rend difficile le changement pour les concepteurs et les développeurs. Ce qu'ils peuvent faire, c'est implémenter passivement des prototypes.
• Les documents de conception d'histoires sont généralement très spécifiques, ce qui rend également les chefs de produit pris dans les détails et réduit la gestion globale.

Bien qu'il existe certaines lacunes dans la gestion traditionnelle, les modèles de prototypage ou les documents de conception de stories peuvent se compléter mutuellement dans le développement réel. La gestion de la bibliothèque de documents a été ajoutée dans ZenTao .