Tableaux Kanban / Scrum

Question

Je suis curieux de ce que d'autres personnes utiliser physiques Kanban/Scrum conseils dans leurs entreprises. J'apprécie le fait que en raison des informations sensibles vous ne pouvez pas être en mesure de fournir une photo de la carte. Je suis à la recherche pour trouver ce que votre conseil d'administration ressemble, et comment vous organiser des histoires d'utilisateur et les tâches qu'ils se déplacent à travers un type de sprint/itération?

Souvent, j'ai travaillé dans des endroits qui organisent le conseil d'administration comme suit à chaque

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 par un membre de l'équipe (Bob). Une liste de tâches à d'autres personnes pour ramasser sont en attente dans la Todo colonne, mais cela peut être ramassé par un autre membre de l'équipe qui coordonne avec Bob pour obtenir le travail effectué.
• Pour UC-002 le service de paiement tâche a été achevée et un test automatisé harnais a été achevée pour le contrôle de qualité leur permettant de tester le service sans INTERFACE utilisateur. Si le test échoue, un bug est soulevé et déplacé le long avec le Service de Paiement de la tâche en arrière dans la phase de QA
• Toutes les tâches pour UC-003 a été achevée et a déménagé à Prêt pour l'assurance qualité.
• Toutes les tâches pour Uc-004 et UC-005 ont été complète donc l'article de l'utilisateur a été déplacé à Fait.

Cela fonctionne comme un véritable tableau blanc qui implique des personnes qui interagissent avec chacune des tâches/user stories (représenté comme un " post-it). Une version électronique est créé avant le sprint/itération et est mis à jour seulement à la fin du sprint/itération correspondant à la situation actuelle. Les commentaires et critiques sont les bienvenues : )

Answer 1

Nous utilisons quelque chose inspiré par le célèbre Scrum et XP depuis les Tranchées de Henrik Kniberg, les colonnes étant adaptée en fonction du contexte (souvent: à faire, en cours, À ÊTRE TESTÉ, en FAIT):

Produit Articles du Carnet de commandes (PBIs) sont imprimés sous forme de "cartes" (format A5) pour la Réunion de Planification de Sprint (au moins les plus importantes). Une fois que l'équipe a ramassé PBIs pour la prochaine itération, les éléments sont décomposer en tâches/activités (sur les notes collantes). Après la réunion, tout se passe sur le Scrum Board et je suggère d'utiliser du ruban adhésif ou des punaises ou des aimants. PBIs sont par ordre d'importance, le plus important en haut de la carte, de moindre importance, au fond. L'équipe doit travailler sur l'élément le plus important de la première jusqu'à ce qu'il se fait. Tout d'abord, l'activité de post-its se déplacer de la gauche vers la droite. Ensuite, le PBI sauts à Faire. Inattendu tâches sont ajoutées à un "Imprévu éléments de la zone" (à prendre en compte dans le burndown chart). L'avenir PBIs rester visible en un "à Côté" de la zone (si tous les éléments sont complétés au cours de l'itération, on choisit un nouveau à partir de là). Assez simple.

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

• coincé tâches (tâches qui ne sont pas en mouvement) qui montrent un obstacle potentiel
• l'équipe de faire les choses dans le mauvais ordre et ne pas se concentrer sur les points prioritaires, comme sur votre échantillon :)
• trop de travail en cours, rien de fait
• imprévue des éléments qui sont en train de tuer un sprint

Fonctionne très bien.

Si vous êtes à la recherche pour plus d' "kanban" axés sur les choses, peut-être avoir un coup d'oeil à Kanban vs Mêlée, Un jour, dans Kanban Terre et Kanban et Scrum - un guide pratique à partir de la même Henrik Kniberg. Des choses beaucoup trop.

Et, pour plus de photos, de fournir à Google des Images d'essayer avec scrum+conseil, kanban, scrumban, mêlée+kanban.

Answer 2

Voici notre Kanban Board que nous utilisons à TargetProcess. Nous ne travaillons pas sur des Tâches de niveau, juste de l'Utilisateur, des Histoires et des Bugs niveau. Parfois, nous créer des tâches, mais ils ne sont pas suivis de manière explicite sur le conseil d'administration.

Nous n'avons pas d'estimation de l'Utilisateur des Histoires et des Bugs, mais essayez de fractionner les Histoires en plus petits (avec un succès mitigé). Les colonnes sont auto-explicatif. Nous accumulons les éléments Testés colonne, puis de créer une branche , le test de fumée et la sortie d'un nouveau build. Habituellement, nous libérer de nouveaux à construire toutes les deux semaines.

Aussi le conseil de présente aux développeurs et aux testeurs de la charge et des catégories de services via le codage de la couleur.

UPD. Maintenant, nous avons plusieurs petites équipes et à l'utilisation d'un seul conseil à suivre les progrès de toutes les équipes dans http://www.targetprocess.com/3

Answer 3

Scrum / Extreme programming storyboard.

http://www.flickr.com/photos/dafydd%5Fll%5Frees/4138686549/

Travail apparaît sur la deuxième à partir de la colonne de gauche, et progresse à travers le conseil d'administration à travers les différentes étapes de l'exhaustivité.

Les noms de colonne: Pas Commencé, tout a Commencé, à mi-Chemin, Presque Terminé, Prêt pour Vitrine (passé AQ)

La première ligne est spécialement réservé pour la correction de bug - comme un fixe, la priorité pour la compensation de bugs.

Les Simpson: les personnages de représenter chaque membre de l'équipe. Ils sont déplacés afin que nous puissions voir qui travaille sur quoi.

Answer 4

Je vous suggère de prendre un coup d'oeil sur Eylean board. http://www.eylean.com/?utm_source=geffort&utm_medium=content&utm_campaign=geffort il peut s'adapter à tous vos besoins grâce à son interface intuitive, statistiques, tableau de bord. Aussi, il s'adapte à tous les processus et la chose la plus importante c'est très facile à utiliser. Cette carte permet de représenter plusieurs projets sur une planche à l'aide de lignes. Toutes les lignes peuvent être visibles à un moment ou vous pouvez supprimer ceux qui sont sélectionnés à partir de la portée.Une autre solution peut être de la tâche de regroupement et de filtrage par catégories - toutes les tâches peuvent être représentés sur une carte et de la ligne, mais attachés à des catégories différentes.

Answer 5

Dans la pratique, l'organisation de l'avancée des travaux du conseil est mieux pour l'équipe à déterminer en fonction de votre situation et de l'environnement. (Agile == autogestion.)

Cela dit, voici ce que nous avons fait dans mon équipe précédente, partie de 300+ développeur effort qui était relativement nouveau à l'agilité et l'Écume:

Nous avons eu deux conseils, l'un avec les cartes d'index pour les prochaines histoires, de sorte que nous pouvons dire à ce qui était à venir, et un avec le sprint du travail. Nos colonnes sur le sprint du conseil d'administration étaient tout simplement

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

et une boîte dans le coin pour Blocked.

Un post-it note représenté chaque histoire.

Les développeurs avaient chacun un petit aimant qui ils ont utilisé à la liste chaque matin pour indiquer qui travaille sur quoi. Notre équipe était assez grande (~ 12 à un moment) donc cela m'a vraiment aidé à comprendre qui était jumelé avec qui.

Nous ne vous embêtez pas avec une version électronique (pas de point), bien que notre Produit Propriétaire avait un Scrumworks système qu'il avait besoin de le tenir à jour. Nous avons tenu à l'écart à partir de ce que nous pourrions!