Si des éléments techniques tels que "Niveau de mise à niveau de V1 à V2" ou "Augmentent les performances de démarrage" ou "Module de connexion des refacteurs pour réduire la complexité du code" entrent dans l'arriéré du produit et, si oui, comment un propriétaire de produit non technique peut-il être capable pour les hiérarchiser vs autres éléments d'arriétrage plus fonctionnels?
devrait-il y avoir un arriéré séparé pour des trucs techniques? Devrions-nous avoir un rôle commun avec deux personnes pouvant hiérarchiser des trucs fonctionnels et techniques sur l'arriéré du produit?
3 Réponses :
J'ai eu du succès avec l'approche à double arriéré:
Backlog du produit appartient au propriétaire du produit. Il contient des éléments de niveau d'histoire (fonctionnalités) qui sont estimés par l'équipe, puis hiérarchisés par le propriétaire du produit. Ce processus d'estimation divise les histoires dans des tâches plus petites.
Backlog Team est la propriété de l'équipe de développement. Il contient des éléments de niveau de tâche relativement petit (peut être complété dans un sprint). Ils peuvent être liés à des histoires, par exemple comme des obstacles: compléter l'histoire, les tâches techniques suivantes doivent être terminées en premier. Ils peuvent également être indépendants de manière à ne pas être requis pour une histoire en soi, mais ils remboursent une dette technique pour permettre une vitesse supérieure à l'avenir.
(sur certains grands programmes multi-projets que j'ai également eu des arriérés de programme contenant des articles de niveau épique, possédés et hiérarchisés par une équipe de gestion de programme, à se faire scinder aux rétrodies dans des arriérés de produits.)
IMHO, l'approche à double arriéré n'est pas une bonne pratique. L'équipe devrait plutôt essayer d'exprimer des histoires techniques en termes commerciales, de montrer la valeur commerciale qu'ils fournissent, d'expliquer comment ils ont une incidence sur la vitesse de l'équipe. De cette façon, le PO sera capable de les prioriser comme toutes les autres histoires.
Je pense avoir plus d'un arriéré rend le projet ou la gestion de sprint un cauchemar. Je pense que c'est un anti-motif.
Plus d'un arriéré laisse le propriétaire du produit et l'équipe de développement en conflit. S'il y a une confiance entre les deux côtés, ce n'est pas un problème. S'il n'y a pas confiance, vous avez des problèmes plus importants.
Chaque réglage / équipe est différente; Il n'y a pas de règles, vraiment. Une liste des améliorations à faire peut aider à sortir des choses des têtes de développeur. Les articles peuvent être «travaillés dans» estimations pour des histoires d'utilisateurs pendant la planification. Les articles plus gros peuvent être rechargés dans des histoires d'utilisateurs, mais avec la valeur clairement mappée, sa «de sorte que» qui est importante; de sorte que la page charge plus rapidement + lien vers des études d'impact sur la charge / des ventes.
Habituellement dans la section "Vanilla", les tâches techniques que vous avez mentionnées n'iront pas comme des histoires distinctes.
Pour moi, le PO non technique ne devrait pas regarder les histoires telles que "Mettre à niveau le serveur". Ce n'est pas une histoire d'affaires, ce n'est pas visible pour l'utilisateur final, il est donc difficile de prioriser s'il est formulé de cette façon. Les priorités doivent être assignées en fonction de la valeur commerciale des travaux. «Mise à niveau» ne signifie pas beaucoup. «Permettre plus de connexions simultanées», «réduire les temps d'arrêt» ou même «améliorer la vélocité de l'équipe» pourrait fournir une perspicacité beaucoup plus précieuse à une personne non technique. Si vous ne trouvez pas une description non technique, posez-vous une question sur la nécessité de la mise à niveau :)
L'histoire de «refactoring» est encore plus compliquée. Vous êtes-vous demandé pourquoi est-ce une histoire du tout? Le refactoring pourrait être fait comme une tâche dans l'histoire, mais c'est rarement une histoire sur elle-même. Donc, si vous souhaitez que vous souhaitiez que la connexion fonctionne mieux ou que vous fournissez plus de fonctionnalités, c'est une histoire, mais le bricolage sous la hotte ne compte pas comme un. Veuillez également noter que le refactoring sans but commercial pourrait facilement conduire à un «placage d'or» dit
Je suggérerais de faire les histoires de «mise à niveau» en tant que pic avec les «performances d'amélioration» et «re-facteur» étant les tâches d'une histoire pertinente.
P.s. Vous trouverez peut-être une bonne discussion sur ce sujet (principalement dans la partie 3 de celle-ci) dans l'excellent livre de Mike Cohn appelé " Stories utilisateur appliquée: Pour le développement logiciel agile ".
Certaines tâches ne peuvent pas être classées dans vos deux groupes mentionnés. Certaines tâches sont des tâches prépondérables telles que: Prêt à la génération de code, membres de l'équipe de formation, en faisant une infrastructure de journalisation, en faisant l'infrastructure de développement de base, séparant les projets en 3 projets différents pour avoir plus de contrôle sur celui-ci ... Comment les rencontrer?
Je suis d'accord avec la vision de la recherche sur l'avantage commercial de toute histoire technique et de la suivre sur le carnet de produit principal
Je pense que des histoires internes sont liées à la vélocité / capacité de l'équipe, qui sont parfois plus correctement gérées en attribuant une certaine capacité aux développeurs, en particulier lorsque le propriétaire du produit n'est pas intéressé de hiérarchiser ou de gérer ces histoires. Par exemple. Attribuez 10% de capacité à tester l'automatisation automatisée (de la régression héritée), la configuration du serveur CI, etc.
Oui, tout peut certainement être exprimé en termes commerciaux, mais une partie de celle-ci devrait être considérée comme "la façon dont nous avons besoin de faire notre travail" où il y a confiance entre le propriétaire du produit et l'équipe que l'équipe utilisera au mieux la capacité de la capacité assigné à cela.
Peux-tu me donner un exemple? Par exemple, comment puis-je expliquer "Fabrication d'outil de génération de code prêt pour le projet en cours" en termes commerciaux?