Rendre les dépendances et les connexions croisées visibles dans les modèles Jira

La journée de travail commence mal pour la Team Alpha. Les réunions debout de l’équipe, en fait une courte réunion de routine ciblée, sont désormais caractérisées par des discussions frustrantes et frustrantes. Et finalement, il devient clair que la planification du sprint actuel doit être abandonnée.

Immédiatement après le stand-up, le Product Owner stressé se met en route. Elle doit absolument parler à quelqu’un de l’équipe Beta – mais elle a d’abord beaucoup de choses à expliquer aux parties prenantes.

Comment est née cette expérience désagréable ? L’équipe avait travaillé sur son sprint et avait bien progressé. Tout s’est déroulé comme prévu : les estimations d’effort étaient réalistes, les capacités étaient appropriées, l’équipe était motivée, l’OP était content. Les clients et les utilisateurs peuvent s’attendre à une fonctionnalité plutôt intéressante qui sera bientôt disponible.

Les choses se déroulaient sans problème jusqu’à ce que le travail s’arrête soudainement parce qu’il s’est avéré qu’un ticket important nécessitait d’abord d’accomplir une autre tâche. Et malheureusement, ce n’était pas le cas. Pour ne rien arranger, il s’est avéré qu’une deuxième équipe avait même des parts dans l’opération de blocage en question.

Bon sang, pourquoi personne n’avait-il vraiment remarqué ça ? Pourquoi cette dépendance n’a-t-elle pas été reflétée dans le système de gestion de projet ?

Les dépendances et leur visibilité

La gestion de projet et la gestion de produit sont complexes. Dans le développement de logiciels, les microservices et une variété de composants distribués, dont certains ont de nombreux propriétaires différents, ont remplacé les systèmes monolithiques d’antan.

Mais le niveau de complexité a également augmenté en dehors du développement logiciel. Les équipes commerciales doivent travailler entre équipes et de manière interfonctionnelle ; il existe des connexions croisées, des besoins de coordination et des dépendances, y compris des bloqueurs.

Et la gestion de ces dépendances est une condition préalable essentielle pour des processus et des projets à faible friction. Il faut les identifier, les rendre visibles et les relier entre eux pour éviter un accident comme celui survenu sur la Team Alpha.

Ensembles de tickets réutilisables dans Jira

Mourir Modèles.app est – comme son nom l’indique – utilisé pour créer des ensembles hiérarchiques de modèles de problèmes et de sous-tâches prêts à l’emploi dans Jira, qui peuvent ensuite être utilisés encore et encore en appuyant simplement sur un bouton. Cela permet de gagner du temps et beaucoup d’efforts administratifs, notamment lorsqu’il s’agit de travaux récurrents qui nécessitent à chaque fois beaucoup de préparation répétitive dans Jira.

Les deux articles suivants vous montreront comment utiliser efficacement Templating.app pour Jira dès le début :

Lier les problèmes du modèle à d’autres problèmes

Et cela nous ramène à la situation initiale exemplaire, car Templating.app peut également contribuer à combler dès le départ les lacunes de transparence dans les projets répétitifs et à rendre visibles les dépendances.

Notre équipe de développement a livré une nouvelle fonctionnalité pour Teamplating.app qui figurait en tête des listes de souhaits de nombreux clients : il est désormais possible de relier les processus d’un modèle les uns aux autres et aux problèmes existants !

Existe-t-il des dépendances ou des interactions régulières entre les problèmes à prendre en compte dans un ensemble de tâches récurrentes ? Vous pouvez maintenant les représenter dans le modèle.

Trois scénarios simples montrent à quel point cette option est agréable et utile :

• Dans un projet d’intégration standard pour les nouveaux employés, il n’est logique d’effectuer une formation Jira qu’une fois que le nouveau membre de l’équipe a reçu son ordinateur de travail et son accès au système. Cette simple dépendance peut déjà être représentée dans les modèles d’intégration.
• Les campagnes publicitaires font partie du répertoire standard d’une équipe marketing. Ici aussi, de nombreux rouages ​​s’enclenchent. Cela nécessite du travail de texte, une expertise en matière d’utilisabilité, de conception ainsi que l’apport technique de l’équipe produit – et si nécessaire, des experts doivent vérifier si les publicités sont conformes aux directives de contenu des plateformes. Avec Templating.app, ces dépendances mutuelles peuvent être reflétées directement dans le modèle défini pour les campagnes marketing.
• Une fonctionnalité importante est sur le point d’être publiée. Cependant, l’équipe de développement a décidé de combiner chaque nouvelle fonctionnalité avec une information directe pour les utilisateurs : pas de nouvelle fonction dans le système productif sans notes de version accompagnées pour les utilisateurs. À l’aide d’un raccourci, l’équipe peut rendre cette exigence visible.

Templating.app facilite la vie de votre équipe lorsqu’il s’agit de préparer efficacement le travail récurrent. Ce qui demandait auparavant beaucoup de travail manuel (et souvent ennuyeux) est désormais réalisé en un rien de temps : la configuration administrative du travail dans Jira.

Et désormais, l’application aide également votre équipe à identifier les liens importants avec les problèmes existants ou d’autres processus au sein du modèle dans les tickets modèles.

Mourir Modèles.app des stands Disponible pour des tests sans engagement sur l’Atlassian Marketplace. Ou contactez-nous simplement et prendre rendez-vous: Notre équipe se fera un plaisir de vous parler de vos besoins en matière de modèle Jira et de vous montrer la solution lors d’une session de démonstration pratique !

Informations complémentaires

Templating.app pour Jira : transformez facilement les processus existants en modèles pratiques
Nouveau dans Templating.app : modèles pour modèles
Templating.app : créez des modèles de tâches et de sous-tâches dynamiques avec des variables