Comment une équipe Scrum comptabilise-t-elle les tâches d'infrastructure dans la réunion de planification?

Comment une équipe Scrum comptabilise-t-elle les tâches de développement / infrastructure dans la réunion de planification?

À première vue, elles ne ressemblent pas à des user stories car elles ne fournissent pas de valeur à l'utilisateur final.

Cependant, les associer en tant que tâches à une user story particulière n'a parfois aucun sens. Par exemple, supposons que la tâche soit: "Setup Bamboo". Cette tâche n'est pas nécessaire pour compléter une user story, car l'équipe peut créer et déployer manuellement. Ainsi, l'attacher à une user story n'a pas de sens car cette tâche n'est pas nécessaire pour compléter la user story.

Cela suggère donc que ces tâches deviennent des user stories. Mais ensuite, si l’histoire d’équipe les pointe du doigt, cela modifie la vélocité, ce qui est étrange puisque le Product Owner veut connaître la vélocité vis-à-vis de son carnet de commandes, et non de son carnet de commandes auquel sont associées des histoires d’utilisateurs techniques.

Ce ne sont pas réellement des histoires d'utilisateurs. Ce sont des histoires de parties prenantes. À 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:

• articles avec mots clés, qui permettent aux annonceurs d'avoir des annonces plus efficaces
• Les CAPTCHA sont là pour empêcher les modérateurs de traiter le spam manuellement.

La plupart des articles techniques offrent en réalité un avantage commercial, mais rarement pour les utilisateurs. Les formuler d'une manière différente 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 tous les types de parties prenantes, y compris l'équipe de développement. Vous pouvez désormais rédiger vos récits techniques en soulignant les avantages commerciaux:

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 sur ce sujet: ce ne sont pas des histoires d'utilisateurs , et Feature Injection et des histoires techniques . J'espère qu'ils aident.

La vélocité est une mesure de la capacité de l'équipe à effectuer un travail utile (par opposition à Drag). Les tâches d'infrastructure fournissent toujours une valeur à l'utilisateur final, même indirectement, en rendant l'équipe plus efficace à long terme. Je n'ai aucun problème à suivre ces choses en tant qu'histoires utilisateur (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 en mesure de déterminer où de telles tâches peuvent être exécutées sans perturber les produits livrables.

Faites-les progressivement.

Si aucun intervenant ne le veut, n'en faites pas une histoire. Prenez-en soin, un peu à la fois. Par exemple, la première fois que vous déployez manuellement. La deuxième fois, vous automatisez un peu. La troisième fois, vous automatisez un peu plus. Finalement, votre construction n'est pas le plus gros problème, alors vous vous concentrez sur autre chose.

Vous aurez plus de 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 quelques-uns, il est donc important que l'équipe prenne l'habitude de faire le nécessaire pour améliorer le processus.

À mon humble avis, l'approche idéale consiste à placer les efforts d'infrastructure en tant que tâches dans la user story où elle a une valeur initiale; comme vous l'avez mentionné.

En prenant votre exemple; la construction et le déploiement manuels impliquent un effort continu et aucune forme d'achèvement. Il existe indéfiniment.

La même chose pourrait être dite pour le code qui automatise n'importe quelle partie de l'effort dans une application typique qui était auparavant faite manuellement. Définir cet effort en tant que tâche dans une user story est défini comme complet. qui, par nature, 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 font pas l’objet d’un suivi formel via le carnet de commandes, puis tout devient inutile.

Les user stories définissent une valeur d’entreprise du point de vue de l’utilisateur. En raison de cette infrastructure, les tâches sont généralement considérées comme un "gaspillage". Cela ne signifie pas qu'ils ne sont pas nécessaires. Cela signifie que faire plus de tâches d'infrastructure aura moins de valeur pour l'entreprise. En raison de cette infrastructure, les tâches ne doivent pas être considérées comme un scénario d'utilisateur et ne doivent pas être associées à des user stories.

Lors d’une réunion de planification, l’équipe doit déterminer quelles tâches d’infrasturcture seront absolument nécessaires lors du prochain sprint. L'engagement se fera avec ces tâches d'infrastructure à l'esprit. Cela affectera la vélocité de l'équipe, ce qui est un résultat correct, car elle mesure la valeur commerciale que l'équipe peut offrir.

Je n'ai jamais assimilé les histoires d'utilisateurs à la nécessité de fournir une 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 ponctuellement comme toute autre user story.

D'après ce que j'ai vu, 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é ne leur prêtent pas beaucoup d'attention. Celles-ci forment ce que j'appelle la version 0. Ces éléments doivent être en place avant de commencer le développement. Une fois que vous avez commencé à travailler sur les récits, tout changement apporté à ces éléments peut être suivi en tant qu'amélioration des processus.

Bien que l'équipe de développement puisse avoir son mot à dire, la plupart de ces éléments devraient être gérés par une équipe de support du projet. La standardisation de ces éléments sur plusieurs projets devrait générer un retour sur investissement significatif pour l'organisation.

Considérer ce qui suit:

• L'équipe Scrum ajoutant les principales fonctionnalités à une suite de produits existante.

• Il est nécessaire de mettre à niveau la technologie, les outils et les utilitaires de développement pour rester à jour en fonction des meilleures pratiques d'ingénierie.

• Il est logique de charger une version avec ce travail afin de résoudre les problèmes de Sprint au cours de la publication.

• Étant donné que l'entreprise tire une valeur indirecte de ces éléments, je suggère que, dans un souci de transparence, il s'agisse d' éléments de backlog ( Product Backlog ).

• L'équipe évalue ces articles et les traite comme n'importe quel PBI.

Pour moi, cette question se résume au fait que je ne veux pas perdre de temps à essayer de comprendre comment dissimuler ce travail en tant que tâches relevant d'autres IBP plus centrés sur les entreprises.

Je ne veux pas que le dimensionnement des PBI soit biaisé par ce type de travail d'infrastructure. Je veux voir ce qui se fait et comprendre ce que je paye.

Je pense également qu'il est utile que l'équipe comprenne l'engagement de l'entreprise en investissant dans l'infrastructure nécessaire pour fournir des solutions de qualité.

XP recommande d’ avoir un "itération zéro" où tous les outils et l’infrastructure sont configurés. Ecrire des histoires pour ces derniers est facultatif, mais c'est probablement une bonne idée. Pouvoir tester votre infrastructure (construction incrémentielle, test et déploiement automatisés, notifications, etc.) est bénéfique.

Dans notre équipe, nous faisons ce qui suit:

1. Supposons un facteur de focalisation inférieur .
2. Essayez d' inclure de telles tâches dans les user stories qui nécessitent réellement de les implémenter.
3. Si certaines tâches sont totalement nécessaires mais n'apportent aucune valeur commerciale directe (telle que la migration des tests unitaires d'un framework à 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 les veut. Nous répertorions ces tâches sur notre tableau, tout en les séparant des histoires. Pendant le sprint, à chaque réunion quotidienne, nous examinons ce qui a été fait pour les accomplir.

L'étape 2 est la plus importante. Comme dans une pratique agile, dans Scrum, vous essayez de faire le moins possible pour accomplir vos tâches. Considérez cela comme un moyen de ne pas perdre votre vie à faire un travail inutile: mon expérience montre que pas moins de 50% des choses «prétendument cool» finissent par être abandonnées et non entretenues à long terme.