Une histoire d'utilisateur doit-elle être partagée entre les développeurs? [fermé]

Je vois souvent des histoires qui ont un développement back-end et front-end. Par exemple, considérez une grande boîte de dialogue avec quelques tableaux et quelques contrôles dynamiques. Nous allons faire plusieurs histoires (peut-être une pour chaque table et une autre pour le système de contrôle dynamique).

L'équipe de développement se divisera ensuite avec une personne sur le back-end et une autre sur le front-end. Cela permet à la personne principale de se soucier simplement de la structure de la couche SQL, tandis que la personne frontale se concentre sur des choses comme la mise en page. Une fois que l'interface initiale entre le back-end et le front-end est convenue, les deux développeurs peuvent concentrer leur attention pour terminer leur partie à la fin du sprint.

Vient ensuite le chaos. Qui "possède" quelle histoire? Que signifie «en cours» ou «fait»? Devrions-nous faire deux histoires distinctes pour le back-end et le front-end? Si oui, cela ne brise-t-il pas l'idée des user stories basées sur la fonctionnalité? Notre système a une notion de "sous-tâches", ce qui atténue certains de ces problèmes. Mais les sous-tâches ajoutent une complexité supplémentaire. Y a-t-il une meilleure façon? Est-ce une "mauvaise" façon d'utiliser Scrum?

J'ai utilisé une certaine forme d'Agile au cours des dernières années à quelques endroits. Je n'ai pas encore de formation officielle, alors veuillez pardonner toute mauvaise terminologie ou idéologie. J'essaie simplement d'apprendre des moyens pratiques d'améliorer notre processus.

Une "histoire" est ainsi nommée parce qu'elle représente une histoire complète, enfin, du point de vue du client. Sans front-end ou back-end, il n'y a pas de chemin de cas d'utilisation à exécuter par le client.

Dans votre cas, je pense que le front-end et le back-end devraient être une seule histoire. Divisez-le en tâches. Les développeurs possèdent leurs différentes tâches. Ces tâches peuvent être suivies individuellement à travers leurs phases - en cours, codage terminé, test de module terminé, etc.

Assurez-vous d'inclure les tâches assignées au contrôle qualité dans la même histoire - sans validation, une histoire est inutile. Le contrôle qualité testera l'histoire intégrée de bout en bout qu'un client verra. Ce n'est qu'alors que l'histoire globale doit être marquée comme terminée. Dans un environnement Agile idéal, un vrai client ou un proxy client essaie également l'histoire dans une application en cours d'exécution et marque l'histoire comme acceptée si elle répond aux exigences convenues.

Si vous souhaitez des boucles de rétroaction plus rapides, essayez de diviser le cas d'utilisation en fonctionnalités de bout en bout plus petites. Par exemple, au lieu d'un cas d'utilisation tel que "Un client peut acheter des articles à l'aide d'un panier", divisez-le en "Un client peut ajouter un produit à un panier" et ainsi de suite ... Ensuite, complétez chaque cas d'utilisation plus petit bout en bout comme décrit ci-dessus.

EDIT: Je voulais sauvegarder les points ci-dessus avec quelques sources. Les caractéristiques d'une bonne histoire d'utilisateur sont représentées de manière concise avec un acronyme appelé " INVEST ". Il a été créé par Bill Wake et popularisé par le mouvement Scrum. Notez en particulier les articles sur les histoires étant indépendants et verticaux.

Plus d'informations ici et ici .

Qui "possède" quelle histoire?

Celui qui saisit l'histoire. Du point de vue organisationnel, ils estiment qu'une seule personne est responsable du travail. Une fois que vous avez deux personnes, il est trop facile de passer la balle.

Devrions-nous faire deux histoires distinctes pour le back-end et le front-end? Si oui, cela ne brise-t-il pas l'idée des user stories basées sur la fonctionnalité?

Ça dépend. J'ai vu les deux façons de fonctionner. Si l'histoire est assez grande pour que deux développeurs y travaillent à plein temps, alors peut-être qu'elle devrait être divisée. Si les deux développeurs font partie de deux équipes différentes, alors peut-être qu'il devrait être divisé. Si les deux développeurs y travailleront lors de sprints différents, alors peut-être qu'il devrait être divisé.

Est-ce une "mauvaise" façon d'utiliser Scrum?

La clé à retenir est que le processus est là pour vous servir, et non l'inverse. Les user stories sont un moyen pour les techniciens et les non-techniciens de faciliter la communication. Ils expriment ce qu'ils aimeraient, tout le monde négocie, puis vous fournissez des commentaires dans l'histoire sur ses progrès.

Tant que le processus fonctionne pour vous, cela ne peut pas être si mauvais.

Lorsque nous avons implémenté des modèles Scrum, il est parfaitement prévu que plusieurs développeurs puissent être impliqués dans une même histoire d'utilisateur. Il peut y avoir du travail pour la couche de données, l'intégration, le CSS frontal, l'infrastructure, etc. L'équipe peut se regrouper sur les différentes sous-tâches pour une histoire pour le faire.

Cela étant dit, une personne est propriétaire de l'histoire et est responsable de la mise à jour de l'avancement de celle-ci et de s'assurer que tout le monde a fait sa pièce et qu'elle fonctionne ensemble. C'est la personne pour nous qui rapporte qu'une histoire est "terminée".

Comme d'autres l'ont suggéré, mon équipe divise également nos histoires d'utilisateurs en tâches. Cela est généralement facile à faire si vous gérez vos user stories via un logiciel (tel que JIRA ou Rally). Ensuite, il est facile de dire quelles parties de l'histoire avancent.

Mais une alternative pour les tâches serait de simplement réaffecter la propriété à mesure que chaque personne termine sa partie. Donc, l'histoire se transmet - peut-être que le développeur 1 commence avec le travail backend, puis passe au développeur 2 pour faire l'interface utilisateur. Ensuite, il est transmis à votre testeur QA pour vérification. Cette méthode devrait bien fonctionner dans des environnements où vous utilisez de vraies cartes sur le mur ou si votre logiciel ne suit pas les tâches.

Mais dans tous les cas, je recommande de ne jamais appeler une histoire "terminée" jusqu'à ce que l'équipe accepte que cela soit fait, y compris les tests. De cette façon, tout le monde a la possibilité de donner son avis. Et si vous combinez cela avec des idées sur la propriété collective du code et les revues de code, chaque histoire est vraiment "détenue" par l'équipe de toute façon. Il peut être "attribué" à différentes personnes en cours de route, mais si quelqu'un est absent (malade / vacances / trop de réunions? / Autre), le travail peut toujours être fait.

Mon équipe accepte souvent les témoignages d'utilisateurs dans le cadre de notre réunion matinale debout / SCRUM. De cette façon, tout le monde peut facilement reconnaître ou contester si c'est vraiment "fait". D'autres fois, nous laissons simplement notre ingénieur AQ faire cela - si elle est convaincue que cela a été testé et fonctionne, et que toutes les tâches sont terminées, nous l'appelons terminé.

Où j'en suis aujourd'hui, nous appelons ce projet plus vaste une "épopée". Une épopée est composée de plusieurs histoires et peut s'étendre sur plusieurs sprints / itérations. Une histoire, pour nous, est toujours donnée à un seul développeur et devrait s'inscrire dans un seul sprint. Une seule histoire est ensuite subdivisée en tâches. Chacune des tâches est effectuée par le même développeur sur cette histoire. Les tâches sont destinées à donner un aperçu de la progression de l'histoire pendant le sprint / itération. Au fur et à mesure que chaque histoire est terminée, par chaque développeur, l'épopée montre les progrès.

Le but de l'épopée est d'avoir un objectif plus grand qui ne rentre pas nécessairement dans un seul sprint / itération. Au fil du temps, toutes les histoires sont terminées et l'épopée est terminée. Les épopées sont placées dans une version.

Vient ensuite le chaos. Qui "possède" quelle histoire? Que signifie «en cours» ou «fait»?

Nous avons un code de démonstration toutes les deux semaines où les histoires de ce sprint / itération doivent être montrées aux parties prenantes et approuvées. Dans ce contexte, «terminé» pour une histoire signifie que je peux vous montrer ce qu'elle fait. Un développeur est propriétaire de son histoire et est responsable de la montrer (cette partie est une sorte de simplification excessive, mais assez bonne pour cette réponse; nous coordonnons nos démos à travers une seule personne). "Terminé" signifie qu'il peut être démontré avec succès. "En cours" signifie que j'ai des tâches en suspens et que l'histoire n'est pas terminée. Une épopée est terminée lorsque toutes les histoires de cette épopée ont été démontrées avec succès.

Maintenant, c'est la progression de cas parfaite. Nous avons des histoires et des démos qui échouent, des utilisateurs qui veulent autre chose, etc. Ci-dessus est l'objectif et pour la plupart cela fonctionne.