Dans Scrum, les tâches telles que la configuration de l'environnement de développement et le développement des capacités doivent-elles être gérées comme des sous-tâches dans les user stories réelles?


23

Parfois, dans les projets, nous devons consacrer du temps à des tâches telles que:

  1. explorer d'autres cadres et outils
  2. apprendre le cadre et les outils sélectionnés pour le projet
  3. mise en place des serveurs et de l'infrastructure du projet (contrôle de version, environnements de construction, bases de données, etc.)

Si nous utilisons des User Stories, où devrait aller tout ce travail?

Une option consiste à les faire tous partie de la première user story (par exemple, faire la page d'accueil pour l'application). Une autre option consiste à effectuer un pic pour ces tâches. Une troisième option consiste à intégrer la tâche à un problème / obstacle (par exemple, un environnement de développement non encore sélectionné) plutôt qu'à une histoire utilisateur.


J'ai changé question un peu pour le rendre plus clair .. question a maintenant comme dans les sous - tâches des histoires réelles de l' utilisateur au lieu de les histoires
Asim Ghaffar

Réponses:


12

Nous avons beaucoup réfléchi à ce problème au cours de la dernière année.

Bien que je convienne qu'un cadre de base devrait exister avant le démarrage du projet, dans la pratique, il peut faire partie du projet lui-même. Vous devez donc gérer en quelque sorte.

Bien que mélanger la configuration du projet avec les user stories puisse avoir du sens, nous avons parfois choisi des tâches simples qui peuvent être ajoutées au backlog du produit et obtenir la même attention que les user stories. Nous savons que ces tâches techniques sont parfois nécessaires, mais elles doivent être justifiées dans tous les cas. Si l'équipe pense qu'ils sont absolument nécessaires pour atteindre un certain objectif, ils feront partie d'un sprint.

Il est difficile de dire ce qui vous convient le mieux, alors expérimentez ! Un pic pourrait suffire pour l'instant, mais je pense que vous vous retrouverez avec le même problème plus tard, alors planifiez à l'avance. Effectuez des tâches qui sont un espace réservé pour de telles activités. Pour séparer les tâches des histoires deux, je les comparerai rapidement en fonction de mon expérience avec elles.

Tâche: Une tâche est une nécessité technique. Cela peut être des choses pour la gestion de la configuration ou la configuration générale du projet, comme la mise en place d'un référentiel pour les validations, ou l'ajout de l'outil de révision de code le plus chaud que vous ayez jamais vu au processus de développement. Les tâches doivent être prises en compte dans la planification, tout comme une user story. Si l'équipe peut convaincre le propriétaire du produit qu'avoir le dernier et le meilleur outil de révision de code augmente les performances et améliore la communication de l'équipe en éliminant les sessions de programmation de paire de longue durée ou les révisions de code en personne, alors cela attirera l'attention du propriétaire du produit.

Histoires : axées uniquement sur la perspective commerciale, les histoires produisent toujours une valeur visible pour le client. La qualité interne est quelque chose qui va de pair avec la production de valeur commerciale.

Nous attribuons même des points d'histoire aux tâches et travaillons parfois avec eux de la même manière que nous le ferions avec les histoires.

En fin de compte, j'opterais pour cette solution dans votre cas (qui pourrait également s'appliquer en général):

  1. Séparez les "réglages" et les éléments techniques en tâches (éléments qui ne produisent pas directement de valeur commerciale pour le propriétaire du produit).
  2. Peut-être faire un pic avant la configuration du projet pour mettre en place les outils les plus importants (SCM, outils de développement, définition de processus, normes de codage, etc.)
  3. Acceptez que ces tâches apparaissent pendant la durée du projet et planifiez-les en ayant un "type" d'activités distinct des histoires.

Donc, ce que vous appelez TASK est fondamentalement un élément de travail comme User story ou Bug? .. Ce n'est pas le TASK comme dans les tâches dans les user stories, par exemple le code, le test, le déploiement, etc.
Asim Ghaffar

2
Oui pour faire la distinction entre ceux que nous appelons les sous-tâches des histoires "Activités".
malte

Ce que vous appelez Tâche est alors essentiellement un problème selon MSF pour Agile 5.0
Asim Ghaffar

Si vous vous référez à cette description ici: msdn.microsoft.com/en-us/library/dd997897.aspx - Vous pourriez l'appeler un problème tel qu'il a été décrit ici, ce serait approprié je pense. Cela en ferait donc votre option numéro 3.
malte

2
Le point 3 «Accepter que ces tâches apparaissent pendant la durée du projet» est particulièrement important. Le processus unifié agile a une excellente image qui le démontre: i.stack.imgur.com/CUVFI.jpg . Notez que leur discipline "d'environnement" ne disparaît jamais vraiment. Notez également que la majeure partie du travail sur l'environnement est en amont. Donc, si vous constatez soudainement que vous effectuez beaucoup de travaux environnementaux dans une phase ultérieure, il peut y avoir quelque chose qui ne va pas.
Michael

4

Faites ce qui a le plus de sens dans votre entreprise. Ne laissez jamais la façon dont les autres font les choses être un obstacle au bon sens.

Mais je dirai que toutes ces tâches sonnent comme quelque chose qui devrait se produire bien avant de commencer le développement. Je me demande donc si Scrum est même pertinent pour ces tâches. Il y a une maintenance continue et telle pour le contrôle des sources et les bases de données, mais celles-ci ne devraient pas être planifiées, elles devraient simplement être des choses qui se produisent et affectent votre vitesse.

Il y aura des moments où vous devrez sélectionner un framework ou autre pendant un projet, mais quand je dis que je veux dire un framework comme nHibernate, pas un framework comme .NET. Dans ces cas, la recherche devrait être enrichie et chronologisée, pour ne pas mentionner assez courte. Essayez de le gérer comme si vous aviez un développeur malade pendant quelques jours.

Le transfert de connaissances est un autre processus en cours qui devrait être géré en dehors de la vitesse de développement générale.


quand j'ai dit le framework .. c'était comme si nous devions aller pour JSF ou Spring .. ou quand j'ai dit que l'outil .. c'était comme si on devait aller pour Jboss ou Glassfish ..
Asim Ghaffar

1
Je ne sais pas ce que vous voulez dire "bien avant de commencer le développement" .. lorsque le projet démarre, ne devrait pas sprinter 1 démarrer dès que possible, par exemple dans les 2 semaines suivant la date de début du projet ... et dans le sprint 1, il y a un vrai codage.
Asim Ghaffar

1
@AsimGhaffar: Je ne pense pas que ce soit le cas, non. Si vous commencez à coder avant même d'avoir pris des décisions telles que le serveur d'applications à utiliser, vous allez prendre au moins une décision qui vous obligera à réécrire la majeure partie de ce code. Et je ne peux pas imaginer démarrer un projet de nos jours sans configuration de contrôle de source. Je veux dire ok, si vous avez des développeurs assis, trouvez-les quelque chose de productif à faire, comme des prototypes. Mais n'entrez pas tête baissée dans le projet avant d'avoir pris les décisions clés.
pdr

"ne devrait pas sprinter 1 démarrer ASAP par exemple dans les 2 semaines suivant la date de début du projet". Correct. Cela signifie que votre environnement est tout configuré et prêt à fonctionner. Vous êtes déjà compétent dans l'utilisation des outils, dans les builds et les déploiements. Si vous n'êtes pas déjà compétent dans ces domaines et que l'environnement n'est pas configuré, vous n'êtes pas prêt à commencer.
S.Lott

@ S.Lott hmm Je pensais que l'on acquiert les compétences requises SUR LE TRAVAIL, c'est-à-dire en travaillant sur le projet et il n'y a pas d'outil d'apprentissage requis pour le sprint 1.
Asim Ghaffar

2

Il y a un nom pour prendre autant de décisions de conception que possible avant le début "officiel" de votre projet. Cela s'appelle une cascade. Il n'y a rien de mal avec les histoires d'utilisateurs comme: "En tant que développeur, je dois sélectionner un cadre, nous avons donc un point de départ pour le site Web." Si c'est trop grand pour tenir dans une itération, essayez de le décomposer comme, "En tant que développeur, j'ai besoin d'implémenter une page d'accueil de base dans Drupal, donc nous saurons si cela correspond à nos besoins."


1

Une option consiste à les faire tous partie de la première user story, par exemple faire la page d'accueil pour l'application.

Brise "user story" en tant que concept. Quel utilisateur est impliqué dans cela? Aucun. C'est un travail que vous auriez déjà dû faire.

Une autre option consiste à faire un pic pour cela.

Pas mal.

La troisième option consiste à intégrer la tâche à un problème (par exemple, l'environnement de développement n'est pas encore sélectionné) plutôt qu'une histoire utilisateur.

À peu près la même chose qu'un pic en ce qui concerne la planification et les frais généraux.

La configuration n'est pas une histoire d'utilisateur.

C'est ce que vous devriez avoir mis en place avant même de commencer ce projet.

Vous ne pouvez pas vraiment démarrer le projet à moins d'avoir le framework / outil et les serveurs configurés et prêts à démarrer.

Je sais bien que de nombreuses organisations n'existent vraiment qu'après la signature du contrat. Je sais également que de nombreuses organisations ne choisissent une technologie qu'après la signature du contrat. Ce sont toutes des choses inefficaces qui sont en dehors de toute user story.


le problème n'est pas le même que Spike. Considérez le problème comme un élément de travail planifié dans un sprint normal mais n'a pas de points d'histoire. Exemple de problème: SVN n'est pas sélectionné. J'emprunte le mot word à MSF pour Agile 5.0
Asim Ghaffar

"Le problème n'est pas le même qu'un pic". Pour les définitions des mots, vous avez raison. Mais lorsque vous pensez à planifier un travail supplémentaire avant le sprint 1, peu importe que vous l'appeliez un problème ou un pic. Choisissez-en un. Un tirage au sort. Têtes.
S.Lott

Encore une fois, je voulais dire un problème de planification à côté des histoires dans Sprint 1 - pas avant Sprint 1. Donc, pour Sprint 1, disons que nous choisissons 2 histoires d'utilisateurs et 1 problème. Aucun point d'histoire pour Issue cependant. Spike sera en effet avant le sprint 1 ..
Asim Ghaffar

Spike ou Issue n'a pas d'importance. Tout ce travail ne fait pas partie d'une user story. C'est tout le travail qui doit être fait avant le premier sprint. Vous pouvez appeler cela un pic ou un problème, tout ce qui vous rend heureux. Mais ce n'est pas une histoire d'utilisateur.
S.Lott

1

Au travail, nous utilisons une tâche pour préparer l'environnement. Cela peut être déroutant pour certaines personnes, mais la tâche que nous utilisons est à peu près la même tâche que la tâche d'une histoire d'utilisateur. La tâche n'appartient pas à une user story mais est estimée en heures et doit être acceptée par le propriétaire du produit pour se terminer dans un sprint particulier.

Nous utilisons également la tâche pour des travaux architecturaux qui n'ont pas de valeur commerciale "apparente" mais qui ajoutent de la qualité au produit, en particulier pour un produit existant avec une grande base de code.

Ceux-ci peuvent ne pas s'appliquer à votre environnement de travail, mais cela a bien fonctionné pour nous.


0

Je pense que vous mélangez deux choses indépendantes. Une user story ne doit pas contenir de détails techniques.

Le choix du cadre, la mise en place de référentiels et de serveurs, et d'autres tâches, doivent entrer dans l'itération initiale.


vous avez raison et je ne suggère pas de les avoir dans la description de l'histoire. une page d'accueil pour avoir un accès rapide aux fonctionnalités essentielles.
Asim Ghaffar

@AsimGhaffar Cela peut être fait lors de l'itération initiale. Pas comme une histoire d'utilisateur, car les utilisateurs n'ont pas besoin de savoir (ni de s'en soucier) quelle technologie vous avez utilisée pour satisfaire leurs besoins.
BЈовић

0

J'ai récemment suivi un cours Scrum et l'instructeur a suggéré qu'un sprint spécial appelé Sprint 0 soit utilisé pour résoudre exactement ce genre de problèmes. Il y avait des personnes sur le parcours avec différents degrés d'expérience dans Scrum et presque toutes les personnes expérimentées étaient d'accord, disant qu'elles avaient fait la même chose. Dans certains cas, les entreprises ont utilisé Sprint 0 pour évaluer le projet et ont décidé s'il était réalisable ou non.

Pour quelqu'un de nouveau dans la méthodologie Scrum comme moi, cela semble être une solution fantastique car elle vous protège des histoires d'utilisateurs et de tous les autres aspects d'un sprint normal tels que les commentaires des utilisateurs.

Comme Sprint 0 est la même durée que vos autres sprints, il agit comme un moyen de vous assurer que vous ne passez pas trop de temps à configurer les choses car elles peuvent toujours être modifiées plus tard. L'essentiel est de vous mettre dans un état où vous pouvez réellement commencer à développer le produit.


3
Citant Alistair Cockburn, j'ai l'impression que quelqu'un a été pressé par son utilisation de Scrum quand il a fait quelque chose qui n'avait aucune valeur commerciale évidente au début, et il a inventé "Oh, c'était Sprint Zero!" pour éloigner les paysans avec les pioches de sa porte.
Asim Ghaffar

0

sur l'exploration de 2-3 cadres / outils alternatifs

Parfois, cela peut se produire si vous avez une exigence particulière, vous devez faire un POC pour choisir le meilleur outil pour résoudre l'exigence. C'est à cela que sert Spike, car sans savoir quel framework vous utiliserez, vous ne pouvez probablement pas estimer l'histoire et stocker sans estimation ne peut pas être planifié et divisé en tâches.

puis sur l'apprentissage du cadre que nous sélectionnons pour le projet

Bien. C'est assez dangereux. Lorsque le client vous paie pour un SW, il s'attend à ce que vous soyez un professionnel qui sache déjà comment utiliser ses outils. Le client ne vous paie pas pour l'apprentissage ou l'approche de développement d'essai / d'échec. Il est de la responsabilité du développeur d'apprendre de nouveaux outils dans son temps libre ou dans le temps spécial alloué payé par son employé et non par le client. Dépenser de l'argent client pour apprendre sans en informer le client n'est pas professionnel.

Si vous devez vraiment utiliser quelque chose de spécial (par exemple, l'API d'un client ou un outil client sélectionné) que vous n'avez jamais utilisé auparavant, vous devez informer le client que le prix sera augmenté par le temps nécessaire pour apprendre à utiliser l'API. Peut-être que le client changera d'avis si l'augmentation des prix est trop importante.

Bien sûr, je ne parle pas d'une situation où vous devez rechercher un nouveau problème particulier dans le cadre que vous avez utilisé plusieurs fois. Je veux dire la situation où vous commencez à utiliser une nouvelle API ou un nouveau cadre sans passer un certain temps (en dehors du projet) pour l'apprentissage.

Si vous ne respectez pas cela, il sera de toute façon visible dans votre vitesse, car vous apporterez une très petite valeur commerciale par itération. Si le client n'est pas au courant de la raison, il annulera très probablement le projet.

Ceci est toujours valable en cas de projets internes - vous devez informer votre manager / entreprise du temps nécessaire pour apprendre une nouvelle API ou un nouvel outil. Cela a généralement de très mauvaises conséquences si le gestionnaire compte avec votre productivité normale et que votre productivité n'est qu'une fraction en raison de la nouvelle API que vous essayez d'apprendre pendant vos tâches. C'est évidemment encore pire si certains vendeurs calculent avec une productivité normale lorsqu'ils signent un contrat avec le client.

sur la configuration des serveurs (SVN, bases de données, etc.)

Ce sont votre infrastructure et vos coûts internes. Lorsque vous démarrez le projet, vous devez avoir préparé votre infrastructure. La configuration de votre environnement de développement n'a aucune valeur pour le client et ne doit faire partie d'aucun indicateur lié au projet - par exemple la vitesse dans Scrum. J'ai vu cela implémenté comme une itération spéciale d'avant-projet utilisée uniquement pour configurer l'environnement, créer une infrastructure de base, etc.


Nous sommes dans le développement de produits et non dans les projets clients :).
Asim Ghaffar

D'accord. Dans ce cas, vous devez toujours suivre séparément le temps consacré à l'apprentissage et à l'infrastructure pour voir les frais généraux dont vous disposez. Masquer cette fois à l'intérieur des tâches corrompra la visibilité de votre processus de développement.
Ladislav Mrnka
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.