Journal de bord dans JIRA pour les réunions quotidiennes, les rétrospectives et les spécifications.

Question

J'espère que quelqu'un ayant plus d'expérience (bonne ou mauvaise) pourra m'aider : Je suis en train de mettre en place un projet suivi dans JIRA. L'ensemble du processus avec les user stories, la documentation, les sprints, les workflows, l'intégration de bambou et fisheye, etc. est mis en place. Mais maintenant j'ai une question plutôt administrative :

Où les développeurs doivent-ils consigner leur travail lors des réunions, comme les stand-ups et les rétrospectives, et pour la rédaction des spécifications (descriptions détaillées des histoires d'utilisateurs à venir) ? Je ne vois vraiment pas ce qui est logique ici, car j'ai besoin des développeurs (évidemment) pour suivre ce travail, aussi. D'après ce que je vois, les possibilités sont les suivantes :

1. Projet séparé PROJECT-ADMIN JIRA avec des problèmes simples, non agiles.
2. Sprint séparé et parallèle avec les tâches administratives
3. Tâches administratives pour chaque sprint
4. Autres versions ?

L'option 2 semble très bricolée, car les sprints parallèles ne sont qu'au stade bêta pour le module agile de JIRA (anciennement Greenhopper). L'option 3 semble demander un peu plus de travail pour chaque sprint, et je ne suis pas sûr de l'influence que cela peut avoir sur ma vélocité (idéalement, je veux voir le nombre possible de story points qui peuvent être réalisés dans un sprint). L'option 1 me semble la plus raisonnable, mais d'autres l'ont déconseillée, malheureusement sans proposer de solution. Je n'ai pas vraiment examiné l'option 4, car, à mon avis, elle est très similaire à l'option 2.

Je n'ai vu nulle part de meilleures pratiques, et je serais donc très heureux de recevoir des conseils de personnes plus expérimentées. Merci beaucoup.

Answer 1

Nous utilisons Tempo pour enregistrer notre travail facturable par rapport aux problèmes JIRA, qu'il s'agisse d'un seul Epic pour un petit projet ou de tâches individuelles pour un projet plus important. Pour le travail non facturable, nous avons un projet unique où les gens peuvent enregistrer le travail en option, et nous l'utilisons également pour planifier notre temps. L'option 1 est donc la plus proche. Nous pourrions également avoir des catégories pour les différents travaux enregistrés dans Tempo et traiter ce cas de cette façon.

Answer 2

Je suis donc confronté à ce problème précis avec mon équipe et c'est ce qui fonctionne pour nous (pour l'instant) YMMV.

Dans notre structure actuelle, nous avons un projet de type feuille de route (que nous appelons planification) où toutes les questions sont abordées en premier lieu. Ensuite, nous créons des problèmes dans des projets de produits connexes (appelés produits).

1. Au début du cycle de vie, des sous-tâches seront créées pour toutes les réunions, le cadrage, etc. et le temps sera suivi dans le planning. Une fois le projet délimité et planifié, une nouvelle question est créée dans Produit et liée à la question initiale.

2. Une fois que le problème de produit est attribué et que le développeur est convoqué à des réunions pendant que ce problème est dans un sprint, nous créons une sous-tâche sur le produit et attribuons le temps. Si le problème n'est pas dans un sprint, nous allons de l'avant et créons une nouvelle sous-tâche dans Planning et y affectons le temps.

3. Nous avons aussi un projet où nous faisons du travail de type "Housekeeping". Ainsi, si nous devons apporter des modifications à JIRA, Stash, Confluence, nous créerons les problèmes ici. Nous créerons ensuite un nouveau problème sur Planning, nous lierons le problème et nous le planifierons en conséquence.

4. Nous disposons d'un méta-projet qui sert de réceptacle pour tout ce qui n'entre pas dans les autres catégories et que nous passons au crible de temps à autre pour déterminer si nous devons créer des projets distincts.

5. J'ai créé un champ personnalisé qui regroupe toutes les heures des problèmes liés trouvés sur le tableau de planification.

Jetez un coup d'œil au blog de Twitter Visualisation des épopées et des dépendances dans JIRA par Nicholas Muldoon peut-être que cela peut vous aider d'une certaine manière aussi.

Une mise en garde s'impose : nous sommes encore en train d'explorer la meilleure façon de procéder. Chaque environnement est différent et ce qui fonctionne pour nous peut ne pas fonctionner pour vous.

Answer 3

J'ai rencontré le même problème en essayant de suivre les heures des membres de l'équipe qui ne sont pas liées au projet ou qui sont liées au projet mais pas à une histoire ou une tâche spécifique.

Au départ, nous avons opté pour option 3 & avait plusieurs tâches administratives qui persistaient à travers les sprints. Bien que cela soit relativement facile à mettre en œuvre, cela n'a pas fonctionné pour nous, car les membres de notre équipe étaient répartis sur plusieurs projets et, par conséquent, ces tâches administratives qui résidaient dans chaque projet étaient impossibles à gérer et à rapporter pour ces membres de l'équipe.

En fin de compte, nous avons opté pour ce que vous avez décrit comme suit option 1 . En créant un projet séparé avec des questions "non liées aux tâches" telles que les réunions de planification, les questions techniques et le travail du client, puis en installant l'application Extensions de rapport et de journal des temps divers de JIRA nous pourrions fournir aux utilisateurs un moyen facile d'enregistrer les heures sans avoir à changer de projet ou de tableau (puisque le plugin ajoute un menu déroulant à la navigation supérieure).

Le plugin nous a ensuite permis d'obtenir des rapports sur les membres de l'équipe qui enregistrent du temps hors projet, quel que soit le nombre de projets sur lesquels ils travaillent simultanément.

Answer 4

J'avais le même problème, et je sais qu'un certain temps s'est écoulé depuis que cette question a été postée, mais peut-être que cela peut être utile à beaucoup de gens :

Tempo dispose d'une fonction dédiée à ce que vous voulez réaliser et qui est appelée Internal Issues . à ne pas confondre avec Internal activities .

Vous pouvez vous y rendre en naviguant sur Config > System puis cliquez sur le add-ons onglet. Ensuite, faites défiler l'écran jusqu'à la section Tempo dans le menu de la barre de gauche et vous y trouverez un lien qui se lit comme suit Internal Issues . Vous pouvez y créer les problèmes. Gardez à l'esprit qu'avant de créer des problèmes internes, vous devez créer les tâches, par exemple "Planification du sprint" ou "Rétrospective" dans le projet sans les assigner à qui que ce soit, juste au projet.

Lorsque vos utilisateurs veulent enregistrer leur temps de travail pour ces "problèmes internes", ils se rendent à l'adresse suivante Tempo > Timesheets puis cliquez sur le bouton en haut à droite qui indique log work . Là, dans le menu de droite, ils verront l'option "problème interne" où ils peuvent choisir les problèmes internes que vous avez précédemment créés et enregistrer le temps que l'équipe passe sur les cérémonies SCRUM.