Kanban / Scrum Boards [fermé]

Question

Je suis curieux de savoir ce que d’autres personnes utilisent comme panneaux physiques Kanban / Scrum dans leurs entreprises. Je comprends qu’en raison d’informations commerciales sensibles, vous ne pourrez peut-être pas fournir de photo du conseil. Je cherche à savoir à quoi ressemble votre forum , et comment vous organisez les user stories et les tâches à mesure qu'elles se déroulent dans un sprint / itération typique?

En règle générale, j'ai travaillé dans des lieux qui organisent le tableau de la manière suivante:

User Story   | Todo                   | In Progress  | Ready for QA     | Done   |
UC-001       | Domain Object, Service | DAO(Bob)     |                  |        |
UC-002       | Payment UI Screen      |              | Payment Srv (Don)|        |
UC-003       |                        |              | UC-003           |        |
             |                        |              |                  | UC-004 |
             |                        |              |                  | UC-005 |

Donc, pour résumer:

• Une tâche pour UC-001 est en cours d'exécution par un membre de l'équipe (Bob). Une liste de tâches que d'autres personnes doivent prendre en charge est en attente dans la colonne Todo, mais cette tâche peut être reprise par un autre membre de l'équipe qui coordonne avec Bob pour effectuer le travail.
• Pour UC-002, la tâche du service de paiement était terminée et un test de faisceau automatisé était effectué pour le contrôle qualité, ce qui leur permettait de tester le service sans interface utilisateur. Si le test échoue, un bogue est soulevé et déplacé avec la tâche de service de paiement dans la phase d'assurance de la qualité.
• Toutes les tâches de l'UC-003 ont été terminées et déplacées vers Prêt pour QA.
• Toutes les tâches pour Uc-004 et UC-005 étant terminées, la user story a été déplacée vers Terminé.

Cela fonctionne comme un tableau blanc tangible qui implique des personnes interagissant avec chacune des tâches / histoires d'utilisateurs (représentées par des notes post it). Une version électronique est créée avant le sprint / itération et n'est mise à jour qu'à la fin du sprint / itération correspondant à la situation actuelle. Les commentaires et critiques sont les bienvenus:)

Answer 1

Nous utilisons quelque chose inspiré du célèbre Scrum et XP from the Trenches de Henrik Kniberg, les colonnes étant adaptées en fonction du contexte (souvent: TODO, EN COURS, À TESTER, FAIT):

texte de remplacement http://blog.realcoderscoding.com/ wp-content / uploads / 2008/09 / hk.png

Les éléments de backlog de produit sont imprimés sous forme de "cartes physiques". (Format A5) pour la réunion de planification du sprint (du moins la plus importante). Une fois que l'équipe a sélectionné les PBI pour la prochaine itération, les éléments sont décomposés en tâches / activités (sur des notes autocollantes). Après la réunion, tout se passe sur le tableau Scrum et je suggère d'utiliser du ruban adhésif, des punaises ou des aimants. Les PBI sont classés par ordre d'importance, le plus important en haut du tableau, le moins important en bas. L’équipe doit commencer par l’élément le plus important jusqu’à ce qu’il soit terminé. Tout d’abord, l’activité post-it se déplace de gauche à droite. Ensuite, le PBI passe à Done. Des tâches inattendues sont ajoutées à un " Eléments non planifiés " zone (pour les prendre en compte dans le graphique de burndown). Les futurs PBI restent visibles dans un " Suivant " zone (si tous les éléments sont terminés pendant l’itération, nous en sélectionnons un nouveau). Assez simple.

Ces pratiques permettent de détecter visuellement les odeurs, par exemple:

• tâches bloquées (c'est-à-dire qui ne bougent pas) et qui présentent un obstacle potentiel
• l'équipe faisant les choses dans le mauvais ordre et ne se concentrant pas sur les éléments prioritaires, comme sur votre exemple:)
• trop de travaux en cours, rien n'a été fait
• éléments non planifiés qui tuent un sprint

Fonctionne très bien.

Si vous recherchez plus de " orientés vers le kanban " peut-être jetez-vous un coup d’œil sur Kanban vs Scrum , Un jour dans le pays Kanban et Kanban et Scrum - un guide pratique du même Henrik Kniberg. Super truc aussi.

Et, pour plus de photos, essayez Google Images avec scrum + board , kanban , scrumban , scrum + kanban .

Answer 2

Voici notre tableau kanban que nous utilisons à l'adresse TargetProcess . Nous ne travaillons pas au niveau des tâches, mais au niveau des histoires d'utilisateurs et des bogues. Parfois, nous créons des tâches, mais elles ne font pas l'objet d'un suivi explicite sur le tableau.

Nous n’estimons pas les histoires d’utilisateur et les bogues, mais nous essayons de scinder les histoires en plus petites (avec un succès mitigé). Les colonnes sont explicites. Nous accumulons les éléments dans la colonne Testés , puis créons une branche, testez-la et libérez une nouvelle version. Nous publions généralement les nouvelles versions toutes les deux semaines.

Le tableau indique également aux développeurs et aux testeurs la charge et les classes de services via un code couleur.

UPD. Nous avons maintenant plusieurs petites équipes et utilisons un seul tableau pour suivre les progrès de toutes les équipes dans le http: //www.targetprocess. com / 3

Answer 3

Scénario de programmation Scrum / Extreme.

http://www.flickr.com/photos/dafydd_ll_rees/4138686549/

Le travail apparaît sur la deuxième colonne de gauche et progresse à travers les différentes étapes de l’exhaustivité.

Noms de colonne: Pas démarré, juste démarré, à mi-chemin, presque terminé, prêt pour la présentation (contrôle qualité réussi)

La première ligne est spécialement réservée à la correction des bogues - une priorité fixe pour la résolution des bogues.

Les personnages des Simpson représentent chaque membre de l'équipe. Ils sont déplacés pour que nous puissions voir qui travaille sur quoi.

Answer 4

Je vous suggère de jeter un coup d'oeil sur le tableau d'Eylean. = geffort Il peut répondre à tous vos besoins grâce à son interface intuitive, ses statistiques et son tableau de bord. En outre, il s’adapte à tous les processus et le plus important est qu’il est très facile à utiliser. Ce tableau vous permet de représenter plusieurs projets sur un même tableau en utilisant des rangées. Toutes les lignes peuvent être visibles à la fois ou vous pouvez supprimer celles sélectionnées de la portée. Une autre solution peut être le regroupement de tâches et le filtrage par catégories. Toutes les tâches peuvent alors être représentées sur un tableau et une ligne, mais rattachées à différentes catégories.

Answer 5

Dans la pratique, il est préférable que l’équipe détermine l’organisation du tableau de travail en cours en fonction de votre situation et de votre environnement. (Agile == gestion autonome.)

Cela dit, voici ce que nous avons fait dans mon équipe précédente, dans le cadre d'un effort de développement de plus de 300 développeurs relativement nouveau pour Agile et Scum:

Nous avions deux tableaux - un avec des fiches pour les histoires à venir afin de pouvoir dire ce qui allait se passer, et un avec le travail actuel du sprint. Nos colonnes sur le tableau actuel de sprint étaient tout simplement

Not Started
Under Development
Dev Done 
In QA
Complete ("Done Done")

et une case dans le coin pour Blocked .

Un post-it représentait chaque histoire.

Les développeurs avaient chacun un petit aimant qu'ils utilisaient chaque matin au stand-up pour indiquer qui travaillait sur quoi. Notre équipe était assez nombreuse (environ 12 à un moment donné), ce qui nous a vraiment permis de déterminer qui était associé à qui.

Nous n’avons pas utilisé de version électronique (aucun point), bien que notre responsable de produit disposait d’un système Scrumworks qu’il devait maintenir à jour. Nous nous sommes tenus aussi loin que possible de cela!

Answer 6

Je suis un féru de Lean / Kanban et cela fait un moment que nous parcourons notre processus, à l’origine par un flux de travail personnalisé dans JIRA, mais ce n’est pas sans problème compte tenu de la complexité administrative de la version entreprise. Nous avons maintenant étendu notre utilisation d'un tableau blanc et avons décidé d'itérer notre processus à l'aide du tableau blanc pendant un certain temps avant de le recodifier dans JIRA. Voici un exemple de notre mise en page:

• Nous sommes 6 développeurs
• Quand une histoire est dans le développement, c'est sur le bureau du développeur. De même, être revu, être soumis à une QA, etc. Cela signifie que chaque carte sur le tableau représente un élément pouvant donner lieu à une action, et fournit également un instantané décent de la progression des itérations. La règle est que vous n’avez que plusieurs cartes sur votre bureau dans des circonstances exceptionnelles.
• Nous avons convenu de ne pas avoir plus de deux cartes "empilées". dans la colonne En attente de révision. Cela permet de conserver un "flux".

Backlog   | Awaiting Dev   | Awaiting Review   | Awaiting Design  | Awaiting Deployment | Awaiting QA | Done |
Story11   |    Story2      |    Story9         |     Story 6      |   Story1            |    Story9   |
Story3    |    Story7      |                   |                  |                     |    Story12  |
Story8    |    Story10     |                   |                  |                     |             |
          |                |                   |                  |                     |             |
          |                |                   |                  |                     |             |

C’est assez proche de la mappage du flux de valeur sauf pour la partie de déploiement en attente, qui est un hack pour résoudre le problème où le contrôle qualité ne peut pas contrôler un élément tant que nous ne l’avons pas déployé sur son serveur - nous déployons 3/4 fois au cours d’une itération de deux semaines.

Une chose que j'ai remarquée en mappant le flux de valeur sur un " informations radiateur " comme par magie, il concentre naturellement les gens sur le travail à valeur ajoutée qu’il reste à faire, ce qui semble accélérer le développement de la valeur ajoutée des entreprises et leur permettre de continuer sur leur lancée.

J'espère que ça aide!

Answer 7

Nous expérimentons différentes structures de conseil dans différents projets que nous exécutons. Un projet possède la structure la plus élémentaire que nous puissions utiliser:

| (Sprint) Backlog | In Progress | Done |

Autant que possible, nous essayons d'avoir un seul post-it pour représenter les activités de développement et d'assurance qualité d'une histoire.

La structure ci-dessus semble bien fonctionner pour les développeurs du projet, mais les membres de l'AQ ont du mal à savoir quand un travail de développement est terminé pour qu'ils puissent exécuter leurs tests. Nous nous sommes retrouvés à déplacer les histoires vers le "côté distant". de la section En cours pour indiquer que le travail de développement a été effectué et que le contrôle qualité peut prendre en compte cette histoire. Cela est devenu très vite ingérable au fur et à mesure que la section En cours se remplissait.

Cela a conduit à la deuxième itération de la structure du conseil d'administration pour un autre projet, à savoir:

| (Sprint) Backlog | In Progress | Ready for Test | Done |

La

section nouvellement ajoutée Prêt pour le test est essentiellement devenue une section formelle du tableau qui était auparavant le "côté distant". de la section En cours . En apparence, cela aurait dû clarifier les choses pour les membres de l'AQ, mais cela a encore semé la confusion, car les gens avaient des interprétations différentes de ce que Prêt pour le test (je ne vais pas vous ennuyer avec le différentes interprétations ici).

Cela a ensuite conduit à la dernière itération de la structure du conseil que nous utilisons pour un autre projet:

| (Sprint) Backlog | Dev in Progress | Dev Done | QA in Progress | Done |

C’est certainement très éloigné des simples sections Backlog , En cours et Terminé de la première itération, mais cela semble travaille bien pour l'équipe. Ils comprennent bien ce que signifie déplacer une histoire à travers différentes sections du tableau et, quelle que soit l'histoire racontée, cela donne une image claire de la situation de cette histoire dans le cycle de la vie. Nous n'utilisons cette structure que depuis le début du sprint actuel (nous sommes 9 à 10 jours), nous allons donc explorer cette structure plus en détail dans notre rétrospective demain. Pas parfait, j'en suis sûr, mais s'il continue à fonctionner pour l'équipe qui le pilote, nous allons essayer de le déployer auprès d'autres équipes de notre organisation.

Answer 8

Notre tableau blanc est divisé en ces colonnes:

Histoire non lancée, Req / Des / Dev *, Examen par les pairs, Assurance qualité, Terminé

Les histoires les plus prioritaires vont de haut en bas. Chaque histoire peut avoir plusieurs tâches, nous utilisons donc un gros postit pour l'histoire et des tâches plus petites pour les tâches. Les tâches se déplacent de gauche à droite. Chaque jour, nous vérifions que nous travaillons sur les reportages les plus prioritaires.

Nous utilisons une étiquette blanche adhésive sur chaque tâche, sur laquelle la personne qui y travaille met ses initiales. Quand ils ont terminé, déplacez-le sur un nouvel onglet blanc par-dessus l'ancien afin de montrer qu'il est disponible pour tout le monde. Lorsque toutes les tâches sont terminées, l’histoire est également transférée dans la colonne Terminé et lors du relèvement, tout le travail effectué est compté et déplacé vers le haut du tableau pour faire de la place au bas de la liste pour plus d’histoires.

Nous avons également des onglets de couleur pour les histoires et les tâches pour indiquer les blocages pour progresser (le bleu indique un blocage d’une autre équipe, le rouge demande l’aide de Scrum Master). Nous parlons des barrages routiers à chaque stand-up.

Nous pouvons voir quand il y a trop de tâches dans une colonne particulière et changer d'emphase pour en faire plus à Terminé. Nous avons délibérément ajouté la colonne Review pour souligner que le travail devait être examiné par une personne autre que celle qui le faisait avant d'arriver à l'assurance qualité.

* Configuration requise / Conception / développement

Answer 9

La nôtre est assez similaire. Chaque développeur a une colonne et nous avons des lignes pour "Terminé", "En cours de test", "Travail en cours", "Arriéré".

Et nous utilisons des notes de style post-it que nous déplaçons physiquement à chaque étape.

Personnellement, je trouve que le système fait défaut ...

• Le déplacement manuel des post-its devient une douleur après un certain temps. Notre équipe d’assurance qualité gère la plupart du temps le déplacement des tickets - et il s’agit d’un effort constant de les synchroniser avec TFS.
• Les post-its ne peuvent vraiment être déplacés que très souvent avant qu'ils ne soient plus collants. Si un ticket est renvoyé après avoir été testé et placé dans "En cours", puis renvoyé aux tests, etc., etc., il ne faut pas grand-chose pour qu'il finisse sur le sol.
• Parfois, le volume de notes est écrasant. Les notes doivent être empilées pour être même visibles à distance - nous les superposons de manière à ce que nous puissions voir l'identificateur unique de chaque note (du mieux que nous pouvons) ... mais alors vous avez une pile de 10 notes et vous devez obtenir le 5ème de la pile et vous contribuez rapidement à la diminution de l’adhésivité qui se terminera par les notes au sol.
• Lorsque les billets se retrouvent sur le sol, il est assez ennuyant de savoir où ils doivent aller. Le billet de ce développeur A était-il? Ou b? Et était-ce en test? Ou était-ce fait? Retournons dans TFS, recherchons ces tickets, puis déplaçons les post-its en conséquence.

Personnellement, je ne pense pas que les notes post-it soient l’outil approprié ici. Il existe une poignée d'outils numériques qui permettent à ce genre de choses de se dérouler sans aucun problème. Nous utilisons Team foundation server - et j’ai vu quelques très bons outils open source, robustes, gratuits et même, qui vont s’interfacer avec le serveur de fondation et gérer tout cela pour vous, en temps réel.

http: / /www.telerik.com/community/labs/tfs-work-item-manager-and-tfs-project-dashboard.aspx

Answer 10

Nos conseils ont tendance à faire des heures supplémentaires au fur et à mesure que nous progressons en équipe. J'ai tendance à préférer les cartes à cartes physiques si vous avez une équipe co-implantée dans une équipe, car cela encourage une meilleure communication face à face, généralement grâce à mon expérience. Évidemment, il y a plus de frais généraux, mais cela vaut la peine de faire travailler l’équipe ensemble. Un autre avantage que j'ai constaté avec les cartes physiques est que cela facilite la participation des entreprises. Les parties prenantes distantes ne peuvent pas simplement se connecter et voir les progrès réalisés dans le sprint actuel et sortir du contexte, car parfois les cartes ne racontent pas toute l'histoire. Ils doivent avoir une conversation et venir au conseil d'administration, ce qui peut être bénéfique car les choses peuvent être expliquées. Cela signifie également qu'ils peuvent être encouragés à aider à résoudre les obstacles. Cependant, cela n’est pas exclusif aux conseils physiques, mais cela aide.

Comme mentionné, nos conseils évoluent en fonction des besoins des équipes. Nous commençons souvent par la méthode Scrum, mais nous encourageons l’amélioration continue et aboutissons généralement à une solution Scrumban. Ces changements sont reflétés en visualisant le nouveau flux de travail à travers les tableaux. J'ai récemment écrit un article sur notre dernier changement si vous êtes intéressés à consulter notre Scrum de sablier / tableau Kanban

Je pense que l'équipe devrait participer à la création des tableaux, car cela les aiderait à comprendre le flux de travail et non à devenir des silos. De plus, si l'équipe a contribué à la création du conseil, elle contrôle mieux ses propres processus, ce qui facilite l'auto-organisation car c'est un produit auquel ils ont apporté leur contribution.

Answer 11

Nous sommes allés avec la structure de conseil suivante dans notre société.

Backlog | Next sprint |      Current sprint         | Done
                         Buffer    |     Working

Les voies sont attribuées à des membres spécifiques. Chaque membre a un travail différent dans notre bureau, donc les tâches varient. Nous ajoutons ce que nous devons travailler à notre carnet de commandes, puis nous le transférons dans Next Sprint s'il approche de la date limite. Les tâches vertes bloquées sont utilisées pour les tâches continues qui doivent être travaillées quotidiennement. Les cartons rouges indiquent l’importance de la tâche et doivent être terminés dès que possible. Notre conseil nous permet de collaborer librement et d’ajouter des tâches aux couloirs de nageurs si nous avons besoin que quelque chose soit fait par différents départements.

Nous utilisons KanbanTool (Kanbantool.com) pour visualiser notre flux de travail et gérer des projets. C'est vraiment intuitif et facile à utiliser. La communication de notre équipe s’est considérablement améliorée.