Comment une équipe Scrum prend-elle en compte les tâches d'infrastructure lors de la réunion de planification?
Comment une équipe Scrum prend-elle en compte les tâches de développement/infrastructure lors de la réunion de planification?
À première vue, elles ne semblent pas être des histoires d'utilisateurs car elles n'apportent pas de valeur à l'utilisateur final.
Cependant, les attacher en tant que tâches à une user story particulière n'a parfois aucun sens non plus. Par exemple, supposons que la tâche est: "Configurer Bamboo". Cette tâche n'est pas requise pour terminer une user story, car l'équipe peut créer et déployer manuellement. Il n'est donc pas logique de l'attacher à une user story car cette tâche n'est pas requise pour terminer la user story.
Donc, cela suggère que ces tâches deviennent des user stories. Mais alors, si l'histoire de l'équipe les indique, cela change la vitesse, ce qui est étrange, car le propriétaire du produit veut connaître la vitesse par rapport à son carnet de commandes, pas par rapport à son carnet de commandes avec un tas d'histoires d'utilisateurs techniques.
Ce ne sont pas des histoires d'utilisateurs. Ce sont des histoires d'intervenants. À moins que le logiciel ne soit réellement payé directement par les utilisateurs, il est rare qu'une histoire soit entièrement créée à leur avantage.
Je vous donne quelques exemples:
- des articles par mots clés, qui permettent aux annonceurs d'avoir des publicités plus efficaces
- CAPTCHA, qui sont là pour empêcher les modérateurs de traiter le spam manuellement.
La plupart des histoires techniques offrent un avantage commercial, mais elles sont rarement pour les utilisateurs. Les formuler différemment peut aider. J'utilise normalement le modèle d'injection de fonctionnalités de Chris Matts:
In order to <achieve my goal>
As <the stakeholder who wants the goal>
I want (<some users to do>) <some stuff>.
Cela reconnaît explicitement toutes sortes de parties prenantes, y compris l'équipe de développement. Maintenant, vous pouvez également formuler vos histoires techniques, en soulignant l'avantage commercial:
In order to minimize the risk of deploying something broken
As the team deploying the code
We want to spend a few days on an automated deployment system.
J'ai écrit quelques articles de blog à ce sujet: Ce ne sont pas des histoires d'utilisateurs , et Injection de fonctionnalités et gestion des histoires techniques . J'espère qu'ils vous aideront.
La vitesse est une mesure de la capacité de l'équipe à effectuer un travail utile (par opposition à Drag). Les tâches d'infrastructure offrent toujours une valeur pour l'utilisateur final, bien qu'indirectement, en rendant l'équipe plus efficace à long terme. Je n'ai aucun problème à suivre ces choses comme des histoires d'utilisateurs (l'utilisateur est l'équipe de développement dans ce cas) et à les hiérarchiser de manière appropriée. Un Product Owner en bonne communication avec le (s) client (s) doit être capable de déterminer où ces tâches peuvent s'intégrer sans perturber les livrables.
Faites-les progressivement.
Si aucun acteur ne le veut, n'en faites pas une histoire. Prenez-en soin, petit à petit. Par exemple, la première fois que vous déployez manuellement. La deuxième fois, vous en automatisez un peu. La troisième fois, vous automatisez un peu plus. Finalement, votre build n'est pas le plus gros problème, vous vous concentrez donc sur autre chose.
Vous aurez plus de ces tâches axées sur les développeurs au début, et c'est très bien; votre vitesse (mesurée par les histoires) sera juste inférieure. C'est une représentation correcte de la situation. Mais vous en aurez toujours, il est donc important que l'équipe prenne l'habitude de faire ce qui est nécessaire pour améliorer le processus.
À mon humble avis, l'approche idéale consiste à placer l'effort d'infrastructure en tant que tâches sous la user story où il détient la valeur; comme vous l'avez mentionné.
Prenons votre exemple; La construction et le déploiement manuels impliquent qu'il s'agit d'un effort continu et n'a aucune forme d'achèvement. Elle existe indéfiniment.
La même chose pourrait être dite pour le code qui automatise toute portion d'effort dans une application typique qui était précédemment effectuée manuellement. Définir cet effort comme une tâche dans une user story définit complete; qui, par sa nature même, a de la valeur pour l'utilisateur final.
Vous pouvez certainement créer et déployer l'application à chaque sprint, mais cela fait alors partie des tâches quotidiennes qui ne sont pas officiellement suivies via le backlog et tout cela devient théorique.
Les histoires d'utilisateurs définissent une valeur commerciale du point de vue de l'utilisateur. À cause de cela, les tâches d'infrastructure sont généralement considérées comme des "déchets". Cela ne signifie pas qu'ils ne sont pas nécessaires. Cela signifie que faire plus de tâches d'infrastructure offrira moins de valeur commerciale. En raison de cette infrastructure, les tâches ne doivent pas être considérées comme une histoire d'utilisateur et ne doivent être attachées à aucune user story.
Lors d'une réunion de planification, l'équipe doit considérer les tâches d'infrastructure qui seront absolument nécessaires lors du prochain sprint. L'engagement se fera en tenant compte de ces tâches d'infrastructure. Cela affectera la vitesse de l'équipe, ce qui est un résultat correct, car la vitesse mesure la valeur commerciale que l'équipe peut fournir.
Je n'ai jamais assimilé les histoires d'utilisateurs à la nécessité de fournir de la valeur à l'utilisateur final. C'est peut-être courant, mais ce n'est pas la façon dont nous traitons les user stories. Parfois, ces types de tâches sont considérés comme des pics, mais nous avons également eu des user stories régulières, estimées comme n'importe quelle autre user story.
D'après ce que j'ai vu, une grande partie de l'infrastructure est considérée comme une donnée. Cela inclut des choses comme:
- Système de contrôle de révision;
- Système de construction automatisé;
- IDE et autres outils de développement;
- Serveurs de développement;
- Processus de déploiement; et
- Processus et normes du projet.
La plupart des méthodologies avec lesquelles j'ai travaillé n'y accordent pas beaucoup d'attention. Celles-ci forment ce que j'appelle la version 0. Ces choses doivent être en place avant de commencer le développement. Une fois que vous commencez à travailler sur les histoires, tout changement dans ces choses pourrait être suivi comme amélioration du processus.
Bien que l'équipe de développement puisse avoir son mot à dire, la plupart de ces éléments doivent être traités par une équipe de support de projet. La normalisation de ces éléments dans plusieurs projets devrait avoir un impact significatif sur l'organisation.
Considérer ce qui suit:
L'équipe Scrum ajoute des fonctionnalités majeures à une suite de produits existante.
Il est nécessaire de mettre à niveau les technologies/outils/utilitaires de développement pour rester à jour en fonction des meilleures pratiques d'ingénierie.
Il est judicieux de charger une version avec ce travail afin que, au cours de la version, les problèmes de Sprints puissent être résolus.
Étant donné que l'entreprise obtient une valeur indirecte de ces éléments, je suggère que, dans un souci de transparence, il s'agit de Product Backlog Items (PBI).
L'équipe dimensionne ces articles et les traite comme n'importe quel PBI.
Pour moi, ce problème se résume au fait que je ne veux pas perdre de temps à essayer de comprendre comment masquer ce travail en tant que tâches sous d'autres PBI plus centrés sur l'entreprise.
Je ne veux pas que le dimensionnement de l'IBP soit faussé par ce type de travaux d'infrastructure. Je veux voir ce qui se fait et comprendre ce que je paie.
Je pense également qu'il est utile que l'équipe comprenne l'engagement de l'entreprise en investissant dans l'infrastructure requise pour fournir des solutions de qualité.
Dans notre équipe, nous faisons ce qui suit:
- Supposons un facteur de focalisation inférieur.
- Essayez de inclure ces tâches dans les user stories qui ont réellement besoin de les implémenter.
- Si certaines tâches sont totalement nécessaires, mais n'apportent aucune valeur commerciale directe (comme la migration des tests unitaires d'un framework vers un autre), au début du sprint nous créons une liste de "tâches continues". Ce sont des tâches liées au développement qui ne sont pas des histoires, mais l'équipe de développement souhaite qu'elles soient effectuées. Nous listons ces tâches sur notre tableau noir, en le gardant toujours séparé des histoires. Pendant le sprint, à chaque réunion quotidienne, nous passons en revue ce qui a été fait pour les accomplir.
L'étape 2 est la plus importante. Comme dans une pratique agile, dans Scrum, vous essayez d'en faire le moins possible pour accomplir vos tâches. Prenez-le comme un moyen de ne pas perdre votre vie à faire des travaux inutiles: mon expérience montre que jusqu'à 50% des choses "cool" finissent par être abandonnées et non entretenues à long terme.
XP recommande suggère d'avoir un "zéro itération" où tous les outils et l'infrastructure sont mis en place. Écrire des histoires pour ceux-ci est facultatif, mais c'est probablement une bonne idée. Être en mesure de tester votre infrastructure (construction incrémentielle, test et déploiement automatisés, notifications, etc.) est bénéfique