La société que je travaille pour est actuellement à la recherche d'une cascade traditionnelle dans Scrum pour le développement. Nous sommes en train d'adopter lentement quelles pratiques nous pouvons sans faire complètement le déménagement (nous avons encore beaucoup à apprendre avant que nous puissions nous déplacer complètement!).
Une des choses que nous souhaitons mettre en œuvre maintenant, avant de faire le commutateur complet, est le tableau des tâches. Nous estimons tous que c'est un excellent outil qui peut aider au développement et de garder ces utilisateurs d'entreprises au dos de notre dos avec le "Ce que tu fais?" et "comment ça va?" Questions et réunions.
Ainsi, avec tout ce qui dit, une chose que je me demandais est que les tâches du changement de carte de travail? Je sais que vous ne voulez pas changer d'histoires, mais qu'en est-il des tâches dans une histoire? Et si une nouvelle tâche est arrivée, ou une vieille tâche n'est plus valide? Peuvent-ils être ajoutés et / ou supprimés à mi-sprint (bien que nous n'utilisons pas vraiment de sprints, plus comme des cycles de développement courts).
Merci!
5 Réponses :
L'équipe s'engage sur les histoires d'utilisateurs, pas Tâches
Ce n'est pas un problème d'avoir des tâches changeant à mesure que vous rencontrez des problèmes ou d'avoir de meilleures idées de mise en œuvre.
En fait, il est très rare de terminer une sprint avec chaque tâche de 100% "prédite" précise dans la réunion de planification de sprint.
Merci beaucoup pour cela. "L'équipe s'engage sur des histoires d'utilisateurs, pas des tâches" est une chose qui semble être extrêmement utile pour que nous nous souvenions!
Je sais que vous ne voulez pas changer d'histoires, mais qu'en est-il des tâches dans une histoire? Et si une nouvelle tâche est arrivée, ou une vieille tâche n'est plus valide? Peuvent-ils être ajoutés et / ou supprimé mi-sprint (...).
Oui, ils peuvent. Au cours d'une itération, une équipe rassemble généralement la connaissance et comprend une meilleure compréhension de ce qui doit être fait, ou non. En conséquence, une équipe peut découvrir qu'une tâche n'est pas vraiment pertinente, qu'un élément d'arriéré donné nécessite plus de travail que prévu, qu'une estimation initiale est fausse. Dans de tels cas, vous souhaitez définitivement mettre à jour votre arriéré Sprint et votre tableau de brûlures pour coller à la réalité et garder ce qui doit être fait visible: vous voulez vraiment savoir si l'itération est toujours sur la bonne voie, si vous pouvez prendre un autre article. , etc.
Alors, oui, n'hésitez pas à mettre à jour, supprimer, ajouter des tâches
dès que que vous découvrez que cela doit être fait. Et plus tôt, mieux c'est. Dans notre équipe, nous utilisons un tableau de tâches inspiré par Scrum et XP Des tranchées de Henrik Kniberg et nous avons un emplacement spécial pour "Articles non planifiés" comme illustré ci-dessous:
Nous aimons cette approche car il est facile de détecter si des articles non planifiés tuent une itération. Et nous "examinons également" de telles tâches lors de la rétrospective pour voir comment nous pouvons améliorer notre réunion de planification, nos estimations, notre façon de décomposer des articles, etc.
Merci beaucoup pour votre perspicacité Pascal. Cette image est vraiment utile et j'aime bien l'idée d'avoir une zone désignée pour "des articles non planifiés". Je pensais que notre conseil n'est pas vraiment assez grand pour une autre section, je pense que nous pouvons utiliser une note de couleur de couleur différente (car nous utilisons seulement deux couleurs maintenant - vert pour les tâches d'histoire et orange pour les défauts).
Ils peuvent et devraient changer. Le conseil devrait être mis à jour au moins quotidiennement.
Mais Pascal répondit déjà à cela - je veux faire un autre point: de l'expérience "essayer d'adopter" agile à travers de petits changements ne fonctionnera pas. Scrum est un cadre complet - par là, je veux dire qu'il y a très peu dans Scrum (je ne dirais rien) qui peut être abandonné sans faire du mal au processus et de promouvoir le dysfonctionnement ou au moins permettre la dysfonctionnement de continuer (
+1 Pour le point supplémentaire, je partage personnellement ce point de vue.
J'aime déjà les réponses de Pascal et Andy afin de ne pas répéter.
Une alternative utile est de démarrer une carte kanban. Henrik Kniberg a également un bon «livre» à ce sujet, disponible ici: http://blog.crisp.se/henrikkniberg/2009/04/ 03/1238795520000.html
Cela vous permet d'organiser votre travail et d'être ister une pensée agile à la société. Comme l'a dit Andy, Scrum est un tout-intérieur, sinon, vous trouverez que "ça ne marche pas".
Pourquoi pas? Laissez l'espace à l'équipe pour compléter le travail de la façon dont ils aimeraient faire.
Les histoires sont "contrat" entre le client, le propriétaire du produit et l'équipe, il est donc bon de ne pas changer, ajouter, supprimer des histoires sans les laisser savoir. Mais les tâches ne sont que pour l'équipe.
L'équipe devrait être en mesure de suivre l'effort de la manière dont ils ont besoin de le rendre visible.
Disponible est un changement d'heures L'équipe a commis de compléter dans le sprint, mais une bonne équipe de Scrum Scrum et une équipe expérimentée est capable de s'auto-organiser cela.
Cela semble être un bon candidat pour Zone51.stackeXchange.com/proposals/6922/software-Engineering qui entrera bêta privé bientôt ...
Je vote pour fermer cette question comme étant hors sujet car il ne s'agit pas de la programmation.