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?

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.

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.

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.

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

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.

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.

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.

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.

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.