Scrum: éléments techniques dans un carnet de commandes qui est géré par un bon de commande non technique? [fermé]

Question

Si des éléments techniques tels que « Mise à niveau sever de v1 à v2 » ou « Augmenter les performances de démarrage » ou « module de connexion Refactoriser pour réduire la complexité du code » aller dans le carnet de commandes de produits et si oui, comment si un propriétaire du produit non technique pouvoir de les hiérarchiser par rapport d'autres éléments de backlog plus fonctionnels?

Faut-il y avoir un carnet de commandes séparé pour des trucs techniques? Faut-il avoir un rôle de PO avec deux personnes qui pourraient donner la priorité des choses fonctionnelles et techniques sur le carnet de produit?

Answer 1

Je l'ai eu du succès avec la double approche du carnet de commandes:

1. Le carnet de produit est la propriété du propriétaire du produit. Il contient des éléments de niveau de l'histoire (caractéristiques) qui s'estimés par l'équipe, puis jugés prioritaires par les propriétaire du produit. Ce processus d'estimation divise les histoires dans les petites tâches.

2. carnet de commandes de l'équipe appartient à l'équipe de développement. Il contient des éléments de niveau de tâches qui sont relativement petites (peut être complété dans un sprint). Ils peuvent être liés à des histoires comme par exemple les obstacles: pour compléter l'histoire, les tâches techniques suivantes doivent être complétées en premier. Ils peuvent également être indépendants afin qu'ils ne sont pas nécessaires pour une histoire en soi, mais ils rembourser une dette technique pour permettre une plus grande vitesse dans l'avenir.

(Sur certains grands programmes multi-projets que j'ai eu aussi des retards du programme qui contiennent des éléments de niveau épique, détenu et priorisés par une équipe de gestion du programme, à diviser les histoires en backlogs de produit plus loin.)

Answer 2

En général, dans la « vanille » SCRUM les tâches techniques que vous avez mentionnés ne vont pas des histoires séparés.

Pour moi, le bon de commande non-technique ne devrait pas se pencher sur les histoires comme «Mise à niveau du serveur. Ce n'est pas une histoire d'entreprise, il est visible à l'est l'utilisateur final si difficile d'établir des priorités si elle est formulée de cette façon. Les priorités doivent être attribués en fonction de la valeur commerciale du travail. « Mise à niveau » ne signifie pas grand-chose. « connexions plus simultanées Autoriser », « Réduire les temps d'arrêt » ou même « l'amélioration de la vitesse de l'équipe » pourrait donner un aperçu beaucoup plus de valeur à une personne non technique. Si vous ne trouvez pas une description non technique vous poser une question sur la nécessité de la mise à niveau:)

L'histoire de « refactoring » est encore plus compliquée. Est-ce que vous vous demandez pourquoi est-ce une histoire du tout? Refactoring pourrait se faire comme une tâche dans l'histoire, mais il est rarement une histoire sur elle-même. Donc, si vous voulez faire des travaux de connexion mieux ou fournir plus de fonctionnalités qui est une histoire, mais bricoler sous le capot ne compte pas comme un. S'il vous plaît noter également que la refactorisation sans but commercial pourrait facilement conduire à une soi-disant « surréglementation »

Je vous conseille de faire les histoires « mise à niveau » comme une pointe avec le « améliorer les performances » et « re-facteur » étant les tâches d'une histoire commerciale pertinente.

P.S. Vous trouverez peut-être une bonne discussion sur ce sujet (la plupart du temps dans la partie 3 de celui-ci) dans l'excellent livre de Mike Cohn appelé « Histoires de l'utilisateur appliquée: Pour Agile Software Development »

.

Answer 3

Je suis d'accord avec le point de vue de la recherche au profit de toute l'histoire de l'entreprise technique et le suivi sur le carnet de commandes du produit principal

Je pense qu'il ya des histoires internes liées à la vitesse / capacité de l'équipe, qui sont parfois gérées plus facilement en attribuant une certaine capacité aux développeurs, en particulier lorsque le propriétaire du produit ne souhaite pas donner la priorité ou gérer ces histoires. Par exemple. attribuer une capacité de 10% à l'essai carnet d'automatisation (de régression existants), la configuration du serveur CI, etc.

Oui, tout peut certainement être exprimé en termes d'affaires, mais certaines d'entre elles devrait être considéré comme « la façon dont nous devons faire notre travail », où il y a la confiance entre les produits du propriétaire et de l'équipe que l'équipe fera le meilleur usage de la capacité affecté à cet effet.