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

33

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.

scrum planning

— utilisateur11347
source

25

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.

— Lunivore
source

3

Sémantique ... à mon humble avis, cela va à l’encontre de la philosophie Agile; en ajoutant la séparation nécessaire là où elle ne procure aucune valeur réelle autre que des sentiments flous chaleureux.

— Aaron McIver

5

Parlez-vous d'expérience ou de théorisation? Je pose la question parce que j’ai utilisé ce modèle avec un certain nombre d’équipes et que j’ai constaté que donner la priorité à l’objectif aide vraiment à établir ce qui est nécessaire pour réaliser la vision du projet. Mike Cohn utilise "so that" facultativement. Je ne le crois pas.

— Lunivore

1

Je vois que ce modèle est utile pour aider à communiquer la valeur de la tâche technique à exécuter au bon de commande non technique. Il existe une différence entre «en tant qu’analyste qualité, je veux un serveur d’intégration continue de sorte que l’application soit testée automatiquement tous les jours» et «afin de réduire le nombre de tests manuels requis à la fin du projet, et la erreur de glisser en production, en tant qu’équipe d’assurance qualité, nous voulons tester un serveur d’intégration continue ". La présentation de l’entreprise cachée fournit au PO suffisamment d’informations pour décider de l’inclure ou non.

— Soronthar

1

@ Soronthar Où finit-il alors? "Afin de réduire les frustrations, en tant qu'équipe de développement, nous souhaitons établir nos propres règles". C’est une des raisons pour lesquelles vous êtes resté concentré sur l’utilisateur et c’est tout. Les tâches doivent être cachées du bon de commande. comme le PO ne devrait pas avoir à se préoccuper de ces détails.

— Aaron McIver

9

Oh, et juste au cas où ce ne serait pas clair - je me soucie plus de faire un travail utile que de faire pour Scrum. Ou maigre. Ou BDD. Je pense également que le travail le plus utile en matière de logiciels concerne l’apprentissage et la gestion des risques. Lorsque la méthodologie empêche de faire un travail utile, je me tourne vers le travail utile.

— Lunivore

12

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.

— Kristo
source

3

Je pense qu'il est dangereux pour les équipes de brouiller la distinction entre les éléments qui ont une valeur directe pour l'utilisateur et ceux qui, espérons-le, offrent une valeur indirecte. En particulier, une approche "tout ce que nous aimons vaut de la valeur" encourage les développeurs à utiliser des technologies de l'or et des infrastructures pour l'infrastructure. J'encourage fortement les gens à ne compter que les histoires ayant une valeur commerciale directe pour Velocity, car c'est la seule chose pour laquelle les clients paient de l'argent.

— William Pietri

3

Valser avec des ours. Tout ce que vous faites qui est vraiment précieux a surtout de la valeur parce que personne ne l’a fait auparavant (sinon, il existe d’autres moyens moins coûteux de le faire). L’essentiel de notre travail est d’apprendre à faire les choses nouvelles. Les tâches d'infrastructure nous aident à obtenir des informations sur les nouveautés et à apprendre plus rapidement. Je suis avec @Kristo si cela nous aide à apprendre plus rapidement.

— Lunivore

@Lunivore - La différence est que personne ne vous paie pour apprendre. Ils vous paient pour ce que vous faites avec l'apprentissage. Les équipes devraient toujours prendre du temps pour améliorer leurs outils et leurs connaissances. Mais le considérer comme une vélocité le confond avec le type de travail que l’équipe doit faire.

— William Pietri

Il ne s'agit pas uniquement d'outils et de connaissances. Expérience de pensée d'Ashley Johnson: Pensez au dernier projet que vous avez fait. Réfléchissez au temps qu'il faudrait pour le refaire avec les mêmes personnes, les mêmes exigences, la même technologie, mais après avoir appris tout ce que vous avez appris. Les citations des gestionnaires de projets vont de 25% à 33% - le reste est l’apprentissage que nous faisons dans les projets logiciels. Lisez le billet de Dan North sur Deliberate Discovery: dannorth.net/2010/08/30/introducing-deliberate-discovery

— Lunivore

11

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.

— William Pietri
source

+1: Spike solution la première fois, puis refactor pour qu'elle soit meilleure et plus fiable la deuxième fois.

— S.Lott

Alors, comment vous assurer que les tâches axées sur les développeurs ne prennent pas le relais du sprint, en particulier lorsque vous n'avez pas encore établi de métrique de vélocité satisfaisante? Je ne voudrais pas rater une livraison rapide parce que nous avons passé trop de temps sur des choses qui aideront à long terme.

— Kristo

Et vous devriez prendre le temps de réfléchir régulièrement et d’améliorer de toute façon les processus comme celui-ci.

— Michael

@ Kristo, je ne pense pas que votre chef de produit / client vous laisserait vous en tirer. Même sans une vitesse établie, vous ferez une bonne estimation et négocierez la valeur à fournir pour ces premiers sprints. De plus, si vous croyez @ S.Lott, vous ne livrerez pas de toute façon.

— Michael

@ Kristo: Vous vous en assurez en le faisant progressivement et en réfléchissant régulièrement. Lorsque vous débutez, tout ce que vous savez, c'est que vous ferez certainement le mauvais montant. Chaque semaine, demandez-vous si vous devriez avoir plus ou moins d'infrastructures et si vous vous concentrez sur les projets les plus rentables. C'est toujours un acte d'équilibre.

— William Pietri

6

À 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.

— Aaron McIver
source

Merci pour cette réponse. Elle précise enfin comment procéder: "l’idéal est de placer les efforts d’infrastructure en tant que tâches dans la user story où elle a d’abord une valeur".

— Igor Popov

En réalité, ces travaux d'infrastructure devraient faire partie de la définition du terme «fait».

— Igor Popov

4

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.

— Ladislav Mrnka
source

2

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.

— Andy Wiesendanger
source

Certaines équipes travaillent ainsi, mais cela rend plus difficile la mesure de la valeur livrée. Personnellement, je suggère aux équipes de créer uniquement des histoires qui ont une valeur commerciale. (Les pointes ont une valeur commerciale car les utilisateurs de produits achètent des informations sur les options futures et leurs coûts.)

— William Pietri Le

Mais quelle est la valeur commerciale? C'est un terme large, et tout ce qui permet à une entreprise de publier un logiciel plus tôt / mieux / etc a de la valeur pour cette entreprise.

— Andy Wiesendanger

La distinction que je fais est entre des choses qui ont une valeur directe principalement pour l’équipe et des choses qui ont une valeur directe principalement pour les personnes que vous êtes réellement là pour servir. Je pense que vous ne devriez compter que ces dernières en termes de vitesse, car c’est la seule valeur qui compte en fin de compte. Les actions entreprises pour améliorer cette création de valeur sont prises en compte dans la vitesse par l'amélioration de la vitesse à long terme. Le compter immédiatement fausse les incitations et compte deux fois le gain.

— William Pietri

2

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.

— BillThor
source

1

+1: Si ce n'est pas en place, Agile est vraiment difficile. Une infrastructure et une plateforme stables et éprouvées sont une sorte de condition préalable à l’agilité.

— S.Lott

1

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é.

— Chris
source

0

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.

— Steven A. Lowe
source

2

XP ne recommande pas cela. Certaines personnes le font, mais cela ne fait certainement pas partie de la programmation extrême telle que définie par Beck et al. Personnellement, je pense que l'itération zéro est une mauvaise idée.

— William Pietri

Un autre problème, vous ne commencez pas toujours à 0, vous réaliserez peut-être que vous avez besoin de quelque chose maintenant ou dans le prochain sprint.

— Andy Wiesendanger

@William: voir "Planning Extreme Programming" de Kent Beck, chapitre 15, page 66.

— Steven A. Lowe Le

Ce n'est pas une recommandation. Ils disent que c'est une idée et disent: "Si vous n'avez pas encore utilisé votre technologie, envisagez de passer deux semaines à acquérir cette technologie juste avant de commencer à programmer." Et ils ne suggèrent pas "toute l'infrastructure", mais juste des tests automatisés de base, la création et le déploiement de scripts.

— William Pietri

@ William: aha, je vois où vous voulez en venir. Je ne parlais pas de toute l' infrastructure logicielle , mais de tout ce que vous avez mentionné

— Steven A. Lowe Le

0

Dans notre équipe, nous faisons ce qui suit:

Supposons un facteur de focalisation inférieur .
Essayez d' inclure de telles tâches dans les user stories qui nécessitent réellement de les implémenter.
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.

— P Shved
source