Quels types de tâches peuvent être inclus et suivis comme des éléments de travail dans l'arriéré Sprint?
L'analyse, la révision et les tests d'unités peuvent être incluses ou des tâches de codage de base peuvent être incluses et suivies dans l'arriéré Sprint?
Fondamentalement, je décompose des histoires d'utilisateurs dans des tâches techniques pour mettre à jour l'arriéré Sprint et souhaitez savoir si des tâches ayant des rôles non codant peuvent être mises à jour et suivies dans le carnet de sprint.
5 Réponses :
Vous avez ces tâches que vous souhaitez suivre comme éléments de travail. Soyez prudent de le faire.
Pourquoi? Vous commencez à concrétiser un processus. Il y a une pente glissante ici. Dès que vous commencez à concrétiser le processus, vous arrêtez d'être en réalité agile et commencez à créer une cascade inflexible d'étapes séquentielles obligatoires.
Si vous pensez que ces choses sont si importantes que vous deviez les écrire ou que les développeurs les oublieront, vous ne donnez pas à vos développeurs la responsabilité d'être agile ou du pouvoir de prendre leurs propres décisions.
Vous les traitez comme indigne de confiance.
Analyse d'une histoire d'utilisateur. Ils vont le faire quand même. Pourquoi l'écrire? Va-ils oublier? Le point est Examen du code. Vous voulez qu'ils fassent cela. Vous devez créer la culture où cela se fait et les résultats sont Si les résultats d'un examen de code sont "Votre code suce, le refaire", alors personne ne participe et cela ne se fait pas excepté par Fiat.
Si les résultats d'un examen de code sont "une nouvelle meilleure pratique pour que chacun d'apprendre de" plus "peut-être que vous devriez peut-être repenser ceci selon d'autres meilleures pratiques", peut-être que les gens participeront.
Le test unitaire fait partie d'une sprint sans aucune question ni discussion. Lorsque vous ressentez l'envie d'écrire des tâches pour les programmeurs, vous devez également réfléchir à la question de savoir pourquoi.
Pourquoi devez-vous écrire cela en panne? Que ne font-ils pas?
Voici la partie importante.
ne analysent-ils pas? Pourquoi pas? Vous rendez-vous difficile à analyser? Les utilisateurs ne se rendent-ils pas disponibles?
ne font-ils pas les critiques de code? Pourquoi pas? Quel est le bloc de route pour les critiques de codes? Pas assez de temps? Pas assez de coopération? Pas assez de récompense? Qu'est-ce qui les arrête?
ne font-ils pas des tests d'unité? Pourquoi pas? Quel est le bloc routier à tester? Pas assez de temps? Pas assez de flexibilité? Pas assez de commentaires positifs pour faire des tests d'abord?
Pourquoi vous sentez-vous la nécessité de "contrôler" et "coerce" vos développeurs? Pourquoi ne font-ils pas cela seul?
En effet, c'est peut-être - la partie
Merci pour votre réponse. Ce que je veux dire, c'est l'analyse des exigences, la révision du code et l'unité teste le code. Oui, ils ne sont pas livrables dans le sens agile, mais sont essentiels pour assurer la qualité du code à mon avis et nous devrons passer des efforts pour cela.
@JCS: Veuillez Mettre à jour Votre question pour que cela soit parfaitement clair.
+1 J'aime tout ce que vous phrases comme une question, une grande matière rétrospective
La réponse courte est - tout ce qui fonctionne mieux pour votre équipe et l'histoire d'utilisation en question.
Par exemple, si nous travaillons à refactoriser une pièce de code dans le cadre d'une histoire d'utilisation, nous pouvons séparer une tâche distincte pour gérer la mise sous test en premier. Mais si c'est un nouveau dev, nous en déduisons que ce sera sous test (et généralement fait avec TDD) dans le cadre de notre processus.
D'autres exemples incluent parfois une tâche distincte pour couvrir le temps passé à la coordination contre codage, essais d'intégration avec des fournisseurs externes, etc. - Fondamentalement, toute tâche discrète et mesurable qui contribue à compenser cette histoire spécifique (y compris certaines des exemples que vous avez inclus ci-dessus).
La ligne de fin de la ligne est qu'il n'ya pas une formule définie pour ce que chaque histoire devrait avoir, plutôt adapter les tâches basées sur les besoins individuels de chaque histoire (même de ces tâches ne sont pas liées au code).
Merci. Appréciez votre réponse.
Si vous créez la tâche d'analyse, de codage, d'examen, d'essais, etc. dans chaque histoire d'utilisateur vous se rapprocher de quelque chose appelé Scrumfall (chaque itération divisée en cascade étapes). Il est l'un des odeurs Scrum. Fondamentalement, ces activités devraient être incluses dans la tâche unique: « faire quelque chose » signifie faire tout ce dont vous avez besoin pour compléter « quelque chose » = vous êtes développeur professionnel et vous savez (ou il est dit par la politique) ce qui doit être fait pour tâche complète <. / p>
C'est le cas général. Parfois, vous avez besoin en effet de répartir les tâches aux « activités » mais d'abord, vous devriez commencer avec le processus commun et utiliser cet outil que si vous avez vraie raison -. Par exemple la tâche de pic dans une itération et véritable tâche dans la deuxième itération
Modifier J'ai utilisé la division des tâches dans les activités une fois. Nous ne l'avons pas TDD, mais les tests ont été écrits après avoir terminé la tâche. Donc, chaque tâche de développement a été jumelé à tester tâche de montrer que cela pourrait se faire par un autre développeur et parfois en parallèle avec le développement. Mais la responsabilité de tester par un autre développeur a été la décision de l'équipe et pour des tâches complexes ils ont vraiment fait cela.
Je ne suis d'accord qu'au point où vous impliquerez un modèle de tâches de tâches ne doit pas être suivi pour chaque arriéré. Mais parfois, un arriéré peut avoir besoin d'une analyse, de codage, de test et il n'y a rien de waterfalish à ce sujet. Ma justification? Dans la cascade - Toute la structure de l'organisation est différente - l'équipe d'analyse, l'équipe de codage, l'équipe QA, toutes sont silhées. Dans Scrum, l'équipe est crossfonction et idéalement tout le monde est impliqué dans chaque étape de la création à la fin de l'arriéré.
On peut appeler une odeur de Scruming uniquement si les tâches sont bloquées dans l'équipe d'autres membres de l'équipe et ne sont pas tenus de transparence impliquant tout le monde. Je peux donner de véritables exemples de la manière dont la mise en œuvre est bien différente de la cascade. Et cela ne peut certainement pas être appelé Scrumfall ou Mini cascade.
@sjt: Je n'ai pas écrit qu'il faisait la mêlée, j'ai écrit qu'il se rapproche de près. Mais très bon point car la question ne mentionne pas si chaque tâche peut être effectuée par un membre ou un membre spécifique. Ma réponse est tout simplement sur l'un des principaux principes principes = autonomiser les gens. Créez une tâche de haut niveau et donner la responsabilité de choisir des activités actives au gars qui fera la tâche.
Quelles tâches pouvant être incluses et suivies comme des éléments de travail dans l'arriéré Sprint?
Selon le guide de Scrum -> Dans la réunion de planification Partie 2, l'équipe identifie les tâches. Ces tâches sont les éléments de travail détaillés nécessaires pour convertir l'arriéré du produit en logiciel de travail. Les tâches devraient être décomposées afin qu'elles puissent être effectuées en moins d'un jour. Cette liste de tâches s'appelle le carnet de sprint. Donc, quelle que soit la tâche qui répond à la directive ci-dessus doit être incluse.
L'analyse, la révision et les tests d'unités peuvent être incluses ou des tâches de codage de base peuvent être incluses et suivies dans l'arriéré Sprint?
Oui, ils peuvent et doivent être inclus si cela conduit à convertir l'arriéré au logiciel de travail. Scrum ne suggère jamais d'inclure uniquement des tâches de codage dans un arriéré Sprint. En fait, Scrum demande à l'équipe d'être fonctionnelle croisée.
Fondamentalement, je décompose des histoires d'utilisateurs dans des tâches techniques pour mettre à jour l'arriéré Sprint et que vous souhaitez savoir si des tâches ayant des rôles non codant peuvent être mises à jour et suivies dans le carnet de sprint.
Cela me semble méfiant. Est-ce juste «vous» qui décompose les tâches? Ce devrait être l'ensemble de l'équipe qui décompose les tâches de la deuxième partie de la réunion de planification. Encore une fois, les tâches non codantes peuvent être incluses dans un sprint. Juste pour vous donner un exemple réaliste: dans mon équipe de développement Web, un arriéré typique a eu les tâches suivantes. 1. Définir et découvrir 2. Concevoir et créer une matrice de test 3. Écrivez des tests d'unité pour tester la matrice 3. Code pour faire passer des tests de l'unité 4. Test 5. Test de régression 6. Déboguer 7. Passez sur le logiciel de travail avec PO (si nécessaire pour vous assurer que c'est ce que PO veut)
Modifier Un point de plus sur les tâches. Les tâches ajoutées lors de la planification devraient constamment être décomposées / mises à jour / renommées si nécessaire. L'ensemble de cela consiste à ajouter un ensemble transparent de choses décomposées de choses à faire, ce qui, lorsqu'il est finalement fait, conduit éventuellement à des logiciels de travail à la suite de normes QA, les plus efficaces et efficientes. Ces tâches devraient être ramassées et travaillées sur la circulation fonctionnelle et ne doivent pas être bloquées parmi les membres de l'équipe.
J'espère que cela vous aidera!
Si vous concentrez tous les efforts que vous postulez au suivi de la tâche pour fractionnez vos histoires plus petites (1-3 points), vous allez travailler pour devenir plus agile. Les petites histoires n'ont presque pas besoin d'estimations de niveau de travail ou de suivi. Votre Po bénéficie de la possibilité de prioriser des ensembles de fonctionnalités plus petits et de vous concentrer sur la mise en œuvre de la valeur au lieu de documenter des étapes évidentes de manière répétitive. Suivre certainement des pratiques standard convenues d'une équipe par l'heure par histoire n'est pas du tout utile.
Pourrais-je suggérer: zone51.stackexchange.com/proposals/9543/...
+1 Dans la sympathie du pilonnage, vous allez prendre des membres pour formuler votre question de cette façon, en particulier le dernier paragraphe :)
@gbjbaanb Vous pourriez suggérer, mais il n'y a rien de mal à poser cette question à ce sujet.
Cette question est hors sujets car il ne figure pas dans le cadre des questions appropriées pour ce site, telles que définies dans Quels sujets puis-je poser ici ? Veuillez également voir: Quels types de questions dois-je éviter de demander? Vous pourrez peut-être obtenir de l'aide sur Un autre site d'échange de pile .
Je vote pour fermer cette question comme hors-sujet car il ne s'agit pas de la programmation.