Assez de détails suffisamment est la réponse habituelle.
sur le projet, nous sommes actuellement occupés (qui était incomplet et remis à nous sans aucune histoires BRS / documentation / utilisateur de toutes sortes, nous obtenons des histoires comme:
comme propriétaire de produit, j'ai besoin du développeur pour tester le flux de travail XXX afin que cela fonctionne correctement.
et
comme propriétaire de produit, j'ai besoin du développeur pour tester le workflow yyy afin que cela fonctionne correctement.
Aucune indication n'est donnée de ce que "correctement" signifie.
Lorsque vous demandez plus de détails, on vous informer que vous demandez trop de détails et que cela est agile, l'exigence deviendra plus claire plus tard pendant le sprint (sprint de 2 semaines) et vous ne devriez pas vous inquiéter du détail, alors , mais plutôt de donner à l'histoire un poids dans des "poils de poupée" et d'arrêter d'être difficile. Soyez un gros gars. Ne vous inquiétez pas du détail.
Est-ce ce que agile est censé être comme?
7 Réponses :
Souvent, les entreprises sont des stratégies de processus hybrides. Cela étant dit que cela semble être un rad (développement rapide de l'application) + Scrum. Si ce n'est que le premier sprint que oui, c'est assez de détails pour commencer. À ce stade du premier sprint, je conseillerais à l'équipe d'aller de l'avant en vous assurant que le flux de travail peut exécuter le début à la fin, quels que soient les résultats qu'il génère. Cela signifie souvent faire une certaine manipulation d'exception Pokemon (exception de capture au lieu de spécifiques), enregistrer l'erreur et prendre les informations dans le sprint suivant.
Malheureusement, il s'agit de Sprint 5 sur 4 avec une date prévisionnelle de la technologie révisée «supposée» de 5 décembre qui a été reportée. Où l'une des sprints a même été prolongée d'une semaine à mi-chemin.
C'est impressionnant, malheureusement, c'est la norme en matière de développement agile.
Il doit décrire le chemin le plus simple du début à la fin. Il n'a pas besoin de décrire toutes les exceptions ou variations. Lorsque vous rencontrez ces exceptions et variations, vous devrez avoir une conversation avec le client et mettre à jour l'histoire si nécessaire.
Vous devez demander autant de détails que nécessaire pour vous sentir à l'aise d'estimer l'histoire.
Vous pouvez ajouter des critères de tests d'acceptation à l'arrière de la carte de l'histoire (elles ne doivent pas être détaillées).
comme client, je veux payer avec Carte de crédit ...
Test avec VISA, MasterCard
Par la façon dont vos histoires semblent un peu étranges. Ils devraient être client / fonctionnalité centrée.
+1: Si l'histoire de l'utilisateur est «Développeur teste un composant», ce n'est vraiment pas une grande partie d'une histoire d'utilisateur. C'est juste une liste "à faire". Pas un produit.
convenu que les histoires sont étranges. C'est pourquoi ils n'ont pas encore été complétés. Si vous ne me dites pas ce qu'il est censé faire, vous ne pouvez pas vous attendre à ce que je vous dise que cela fonctionne correctement
Un bon modèle pour des histoires est la suivante: afin de
Lorsque vous demandez plus de détails, on vous informer que vous demandez trop de détails et que cela est agile, l'exigence deviendra plus claire plus tard pendant le sprint (sprint de 2 semaines) et vous ne devriez pas vous inquiéter du détail, alors , mais plutôt de donner à l'histoire un poids dans des "poils de poupée" et d'arrêter d'être difficile. Soyez un gros gars. Ne vous inquiétez pas du détail.
Pas vraiment. Histoires utilisateur Capturez l'essence, mais cela ne signifie pas aucun détail. Les détails sont transmis lors de la conversation et sont définitivement
obligatoires pour une bonne compréhension de ce qui doit être fait (même de mentionner qu'il semble difficile d'estimer quoi que ce soit si vous ne savez pas quoi faire et ce qui est attendu ). Communiquer les détails sur les histoires est en fait une partie du travail du propriétaire du produit (PO). Cela devrait se produire lors de la première partie de la réunion de planification de sprint où la PO explique chaque histoires à l'équipe, avant le poker de planification et / ou à tout moment si une clarification est requise. En d'autres termes, n'hésitez pas à demander au PO pour plus de détails (et demandez également aux critères de l'acceptation). Et s'il y a trop d'incertitude, mettez une grande estimation devant l'histoire et expliquez pourquoi vous ne pouvez pas faire une estimation «meilleure».
Pour moi, votre PO / Client / Poignées ne semble pas participer très activement et c'est un gros obstacle très grand. Votre scrummaster doit prendre en charge cela, il n'y a pas de solution magique.
Cette réponse semble cool ... problème, c'est que nous ne voyons que le PO en pleine difficulté et il est en réunion la plupart du temps ...
C'est un majeur Guêpe: si le PO n'est pas disponible, vous ne pouvez pas faire Scrum, surtout si les gens ne vous donnent pas de bonnes histoires d'utilisateurs. Vous avez un gros problème ici, peut-être que la PO n'est pas la bonne personne ... votre Scrummaster doit résoudre ce problème.
+1: Agile concerne l'interaction entre développeurs et po. Pas le PO Dire aux développeurs qu'il sera finalement clair. Comment deviendra-t-il clairement sans le PO expliquant?
C'est une bonne réponse. "Correctement" peut dans certains cas signifie que quelque chose d'aussi large que "la page charge complètement", mais cela ne signifie pas que cela ne devrait pas être spécifié - ne pas entrer dans les détails atomiques, il est important d'identifier uniquement les parties pertinentes pour chaque histoire.
Lorsque Agile est dû à la partie de développement de l'entreprise, le rôle PO est généralement faible ou inexistant. J'ai vu que les responsables de développement tentent de remplir ce rôle avec des niveaux de réussite variables. Cependant, la clé de cette question n'est pas que le PO échoue, le Scrummaster n'assurcit pas que leur est suffisamment de détails pour que l'histoire soit raisonnablement bien comprise (mais elles y arrivent).
C'est très subjectif quand on parle des détails. Un «détail suffisant» semble parfois «insuffisant» ou parfois «nit-choisir». Je me sens très difficile de trouver un équilibre. Personnellement, je n'aime pas trop de détails qui sont parfois tout simplement impossibles à mettre sur un document. Mais celles-ci sont parfois inévitables, surtout si vous gérez des équipes offshore. Du manifeste agile: la méthode la plus efficace et la plus efficace de transmission d'informations à une équipe de développement est une conversation face à face. J'aime cette discussion aussi: Artima.com/Intv/fixit.html
J'aime la réponse, mais ce n'est toujours pas assez clair pour moi. Le PO fournit des détails dans les conversations, mais devrait-il ensuite être ajouté (documenté) aux histoires d'utilisateurs d'origine? Où est la "mémoire" des conversations détaillées?
Scrum Backlog Les articles / histoires d'utilisateurs n'ont pas besoin d'être très spécifiques à être ajoutés à l'arriéré.
Plus de détails est nécessaire pour les rendre sprincables (planifiées dans un sprint). Il est suffisamment de détail à cette époque afin de pouvoir être estimé, et il devrait avoir un critère d'achèvement a L'User Story est une promesse pour une conversation avec le propriétaire du produit sur le scénario qu'il couvre.
Les détails prématurés sont des déchets
Combien de détails est "assez" dépend de nombreuses choses. Votre environnement semble indiquer le besoin de plus en détail.
Comme départ, vous aurez peut-être besoin de plus en détail dans votre définition de l'histoire si
On dirait que vous utilisez des histoires d'utilisateurs ici pour définir le processus, plutôt que des fonctionnalités du système. Mais je ne pense pas qu'il y ait suffisamment de détails ici pour que le développeur sache si le test est adopté.
Aussi, ce que vous avez énumérés ici sont des critères d'acceptation, l'histoire d'utilisation est généralement plus descriptive et est sous-tendue par un ou plusieurs critères d'acceptation pour définir l'essence de la fonctionnalité.
questions que je retournerais immédiatement au PO avec sont: Quelle est la logique pour le flux de travail xxx? À chaque étape, quelles sont les options? Qu'est-ce qui (le cas échéant) les actions sont enregistrées? Quel email / notifications sont envoyés? Comment? à qui?
Si le propriétaire du produit ne peut pas articuler le produit et indique à un maître Scrum How comment agile fonctionne, il a-t-il besoin de «formation».
Essayez de fournir un écran vide et de lui demander ce qui manque.
Je vote pour fermer cette question comme hors-sujet car il ne s'agit pas de la programmation.