Atlassian GreenHopper et Release Management

Question

Nous jouons avec les produits Atlassian et j'ai préparé un sprint agile en utilisant GreenHopper, et je suis un peu confus avec le flux.

Voici comment nous procédons pour le développement actuel à mon bureau :

1. Les développeurs complètent les questions qui leur sont assignées. Ils les marquent comme résolus.

2. Une fois que tous les problèmes du sprint sont résolus, nous avons un ticket de publication qui fournit les détails de la publication et nous l'attribuons à l'équipe INF pour qu'elle construise et déploie le système d'assurance qualité. Si les choses sont approuvées par l'équipe d'assurance qualité, le projet est transféré à la production.

3. Si nous trouvons des problèmes ou si l'un d'entre eux n'est pas résolu, nous rejetons la version et la renvoyons aux développeurs, qui la corrigent et préparent une autre version.

Quelqu'un a-t-il des suggestions pour réaliser quelque chose de similaire avec JIRA+GreenHopper ou de meilleures idées.

Answer 1

Il semble que votre processus soit assez simple. Je vous recommande d'essayer les nouveaux Rapid Boards de GreenHopper 5.10.1. Les tableaux rapides ont un flux clair Plan > Travail > Rapport.

En regardant vos spécificités, je vous recommanderais ce qui suit :

• Créez d'abord un tableau rapide pour le développement général. Ce tableau sera utilisé par votre équipe de développement et comportera des sprints comprenant les corrections de bogues, les histoires et les éléments du backlog. La dernière colonne de ce tableau serait "Terminé" ou "Prêt pour l'AQ".
  • À la fin du sprint, l'équipe doit simplement "terminer" ce sprint et enregistrer un ticket pour que la construction soit faite et déployée vers l'AQ.
• Je recommanderais alors de déplacer le même les problèmes qui se sont présentés dans le sprint à travers le processus d'assurance qualité afin que chacun d'entre eux puisse être rejeté. Pour ce faire, l'équipe d'AQ peut simplement disposer d'un tableau Scrum Rapid séparé dont la première colonne est "Prêt pour l'AQ". Cela lui permettra d'exécuter un Sprint séparé qui inclut les problèmes du Sprint qui vient de se terminer.
  • À la fin de ce sprint, seules les histoires qui sont prêtes à être lancées seront dans la colonne "Done" et l'équipe peut décider de déployer uniquement les histoires correctes ou de rejeter l'ensemble de la version.
  • Les histoires qui ne passent pas le test d'AQ peuvent être remises à un statut qui les remet sur le backlog de l'équipe de développement pour être incluses dans le prochain Sprint. Alternativement, elles peuvent être soulevées séparément auprès de l'équipe de développement pour être corrigées.

Answer 2

Nous faisons quelque chose d'assez similaire ici, et tout fonctionne bien dans JIRA / Greenhopper :

1. Le propriétaire du produit crée des Epics / Thèmes / User stories dans JIRA/Grasshopper.

2. Un toilettage du backlog est effectué, l'histoire est un peu remaniée et les points de l'histoire sont introduits dans l'histoire de l'utilisateur.

3. Planification du sprint : Les histoires sont sélectionnées pour le sprint à venir, et en utilisant greenhopper, nous créons les histoires à ajouter au sprint. voir ci-dessous

4. Le sprint commence.. Les tâches sont créées dans JIRA par les développeurs pour suivre la progression, et sont liées à l'histoire de l'utilisateur. Une fois que toutes les tâches d'une histoire sont terminées, l'histoire de l'utilisateur est terminée.

5. Nous avons mis scripts dans JIRA pour avoir un bouton pour "done" qui assigne automatiquement la story à notre équipe de construction, qui la fusionne dans notre baseline principale (pas sûr que cela s'applique à vous). Une fois qu'ils l'ont intégré dans une version de production, le scénario utilisateur est attribué à l'équipe d'assurance qualité.

6. L'équipe d'assurance qualité teste le build de production... s'il passe, l'histoire est close.

J'ajouterai que l'équipe d'assurance qualité peut prendre plus de temps pour tester l'histoire que le sprint ne le permet - ainsi, pour les besoins du sprint et de la vélocité d'une équipe, l'histoire est considérée comme terminée au moment où elle est assignée à l'équipe de construction.

Est-ce que ça a un sens ?

JIRA est capable de faire tout cela, c'est génial, même si vous devrez peut-être configurer les entrées pour les épopées/thèmes, etc.

Nous utilisons la fonctionnalité Greenhopper pour créer et suivre les histoires et les sprints, mais pour l'avancement des tâches, etc., nous utilisons un tableau blanc - beaucoup plus visible, et meilleur pour le standup quotidien.

J'espère que cela vous aidera. Si vous avez des questions, je serai heureux d'y répondre :)