Dans paramètre du tableau on peut définir une bordure de couleur à gauche selon certains critères
Quelle version de JIRA utilisez-vous ?
Il serait peut-être utile de préciser la version et/ou si c’est une version next-gen qui est simplifié.
Je n’ai pas souvenir d’avoir vu ce dont la capture d’écran montre dans un projet next-gen, plus simple.
C’est la version Cloud, je ne vois pas de numéro de version
O utilise la même version sur la photo d e christophe
1 « J'aime »
Les cartes sur le board ont un liseré coloré sur la gauche.
On peut choisir parmi certaines propriétés des tickets pour déterminer cette couleur.
En tant que daltonien, je trouve que cette fonctionnalité est discriminante.
Elle ne le serait pas si la couleur était obligatoirement associée à une des valeurs choisies dans la mise en page de la carte.
Bonjour, et si tu remplacais le prêt par "a discuter " ?
Cette colonne pourrait être partie du flux de travail de l’équipe et pourrait recevoir les tickets dont on découvre de l’incertitude et un besoin de discussion pour repartir de l’avant.
Je me sert de ce bac de nettoyage des US en cours de sprint avec les équipes que j’acccompagne et j’y vois deux avantages :
- rend visible la situation sur sujet et peut provoquer des échanges dessus en daily ou en dehors…
- permet de mesurer et de visualiser cette partie d’aléas sur un sprint pour essayer de s’améliorer pour le futur…
Et qui donc peut être présentée dans un Kanban.
Il ne faut pas oublier que les boards dans JIRA ne sont que des vues et elles peuvent être multiples.
Un board rassemble les tickets correspondants
- à un filtre général, (tenant compte des droits de l’utilisateur)
- refiltré ensuite par un filtre spécial (pour faire disparaitre magiquement les tickets fermés depuis un certain temps
- refiltré éventuellement par les filtres actifs
- refiltré par les status de ticket assignés aux différentes colonnes.
Là, on a les tickets à afficher, il y a alors la répartition de l’affichage
Les colonnes affichent les tickets selon leur statut.
Les couloirs/lignes sont plus souples parce que c’est selon des filtres et la règle En partant du haut, j’affiche ce qui correspond au filtre du couloir, et le reste, je passe en dessous"
Pour finir, il y a 2 modes Scrum et Kanban.
Et Kanban a lui-même 2 modes.
Scrum va utiliser l’information « sprint », pas Kanban.
(attention Kanban != kanban. kanban= tableau avec des colonnes, en Scrum il y a un kanban de produit, et un kanban de sprint)
Le kanban est horizontal.
En Scrum, on a un Backlog (vertical)
On assigne les tickets à un (ou plusieurs sprints selon votre configuration)
On affiche un kanban de sprint avec juste les tickets du sprint.
En Kanban, on affiche tout.
En Kanban, on est censé suivre la règle start to finish, finish to start.
Vu qu’il n’y pas le timeboxing comme dans Scrum, on se retrouve facilement avec un board avec des dizaines et dizaines de tickets dans la première colonne, très très peu dans les intermédiaires, et finalement la dernière vide au départ, qui se remplit et se remplit.
Cela donne un affichage peu pratique du court.
Pour la dernière colonne, JIRA règle ça avec ce « un filtre spécial » dont je parlais plus haut.
En gros si le ticket est dans un statut de la catégorie « done » et plus vieux qu’une certaine date relative, alors on ne l’affiche plus. On masque aussi les tickets de la dernière colonne qui sont associés à une version « livrée ».
Pour la première colonne, en Kanban, l’astuce, c’est de séparer le board en 2 affichages
Le premier redevient vertical et s’appelle backlog.
Dans cet affichage, JIRA n’affiche que le contenu des 2 premières « colonnes » mais en pivotant de 90°.
Donc on a une seule colonne, avec en première ligne, le contenu de la 2eme colonne.
Et ensuite le contenu de la première colonne.
Celle-ci peut donc être énorme ca ne gène pas l’affichage.
Et du coup ‹ autre pertie › c’est l’affichage normal du kanban mais amputé de sa première colonne.Il nous reste donc que les colonnes intermédiaires avec un nombre de tickets à priori très raisonnable, et la dernière qui l’est aussi grace au filtre spécial.
Sur base de tout cela et selon vos discussions, est sans juger du bon sens ou de la scrumitude
Vous pouvez faire plusieurs board !
Utiliser un board « Scrum » pour travailler sur le sprint.
Utiliser un board « Kanban » pour travailler sur la vue plus long terme.
Imaginez de mettre dans une colonne de votre Kanban, tous les tickets dont le statut correspond à un statut de « sprint en court ». Et les autres colonnes pour les status « hors » sprint.
Exemple : (J’invente mais c’est pour montrer une colonne de Kanban qui peut-être prise en charge en sprint)
IDée => Acceptée => Pret => // Todo => Run => Done // => Packagé => Sur le marché
Donc un board Kanban basé sur un filtre qui prends tout (et n’oubliez pas qu’il peut prendre ses tickets dans plusieurs projets !! )
Et puis un board Scrum qui ne reprends que les TODO-RUN-DONE.
Plusieurs produits ==> plusieurs projets chacun leur version
Plusieurs équipes ==> plusieurs board sprint avec un élément qui réparti dans le filtre
Je répète, je ne fais pas la promotion de cette complexitude, je montre que l’outil peut s’adapter à votre façon de faire.
Mise en garde supplémentaire : « Les colonnes affichent les tickets selon leur statut. »
Je trouve ça très limitant de ne filtrer que sur les statuts.
Ce la provoque très souvent une « explosion » du nombre de status.
Il faut beaucoup de rigueur.
C’est un classique quand on commence avec l’équipe enumerer les statuts ils en ont beaucoup trop.
Il faut passer par là pour « apprendre » et le temps les amènera à en réduire le nombre… mais dans JIRA ils auront été créés, et il y aura du nettoyage à faire.