Deux questions concernant Scrum

Question

J'ai deux questions connexes concernant Scrum.

Notre compagnie essaie de l'implanter et nous sommes sûrs de sauter par-dessus des cerceaux.

Les deux questions sont sur "fait signifie que c'est fait!"

1) Il est vraiment facile de définir « Done » pour les tâches qui sont/ont - acceptation de test clair critères - complètement autonome - testé à la fin par les testeurs

Que faut-il faire avec des tâches telles que: - architecture design - refactorisation - certaines classes utilitaires développement

Le principal problème avec lui, qu'il est presque complètement entité interne et il n'y a aucun moyen de vérifier/tester à l'extérieur. Par exemple, l'implémentation d'une fonctionnalité est une sorte de binaire - c'est fait (et passe tous les cas de test) ou ce n'est pas fait (ne pas passer quelques cas de test).

La meilleure chose qui me vient à l'esprit est de demander à un autre développeur de passer en revue cette tâche . Cependant, il est de toute façon ne fournit pas un moyen clair de déterminer est-il complètement fait ou non. Donc, la question est de savoir comment définir "Terminé" pour de telles tâches internes?

2) Mise au point/tâche bugfix

Je sais que la méthodologie agile ne recommande pas d'avoir de grandes tâches. Au moins si la tâche est importante, elle doit être divisée pour les tâches plus petites. Supposons que nous ayons un problème assez important - une nouvelle refonte de gros modules (à remplacez la nouvelle architecture par une nouvelle). Bien sûr, cette tâche est divisée sur des dizaines de petites tâches. Cependant, je sais qu'à la fin nous aurons session assez longue de debug/fix.

Je sais que c'est généralement le problème du modèle cascade. Cependant, je pense qu'il est difficile de s'en débarrasser (surtout pour des changements assez importants).

Dois-je allouer une tâche spéciale pour les intégrations de débogage/correction/système et etc.?

Dans le cas, si je le fais, habituellement cette tâche est tout simplement énorme par rapport à tout le reste et il est un peu difficile de le diviser en petites tâches.

Je n'aime pas ça, à cause de cette énorme tâche monolithique.

Il existe un autre moyen. Je peux créer des tâches plus petites (associées à des bogues), les mettre en backlog, les classer par ordre de priorité et les ajouter aux itérations à la fin d'activité, quand je saurai quels sont les bugs.

Je n'aime pas de cette façon, car dans ce cas, toute l'estimation deviendra faux. Nous estimons la tâche, marquez la demander complète à tout moment. Et nous allons ouvrir les nouvelles tâches pour les bogues avec de nouvelles estimations.Donc, nous finirons par temps réel = estimer le temps, ce qui n'est certainement pas bon.

Comment résolvez-vous ce problème?

Cordialement, Victor

Answer 1

Pour la première partie « conception de l'architecture - refactoring - certaines classes utilitaires de développement » Ceux-ci sont jamais « fait » parce que vous les faites comme vous allez. En morceaux.

Vous voulez faire juste assez d'architecture pour obtenir la première version. Ensuite, pour la prochaine version, un peu plus d'architecture.

Le refactoring est la façon dont vous trouvez les classes utilitaires (vous ne créez pas de classes utilitaires - vous les découvrez lors du refactoring).

Le refactoring est quelque chose que vous faites en pièces, au besoin, avant une version. Ou dans le cadre d'une grande fonctionnalité. Ou lorsque vous avez des difficultés à écrire un test. Ou lorsque vous avez du mal à faire passer un test et que vous avez besoin de "déboguer".

De petites pièces de ces choses sont faites encore et encore pendant toute la durée du projet. Ils ne sont pas vraiment des «candidats à la libération», alors ce ne sont que des sprints (ou des parties de sprints) qui sont effectués dans le processus d'obtention d'une version.

Answer 2

"Dois-je allouer une tâche spéciale pour les intégrations de débogage/correction/système et etc.?"

Pas de la même façon que vous l'avez fait avec une méthodologie de cascade où rien n'a vraiment fonctionné. Rappelez-vous, vous construisez et testez de façon incrémentielle. Chaque sprint est testé et débogué séparément. Lorsque vous arrivez à une version candidate, vous pouvez effectuer des tests supplémentaires sur cette version. Les tests mènent à la découverte de bogues qui mène au backlog. Habituellement, il s'agit d'un arriéré hautement prioritaire qui doit être corrigé avant la publication. Parfois, les tests d'intégration révèlent des bogues qui deviennent un backlog de faible priorité qui n'a pas besoin d'être corrigé avant la prochaine version.

Quelle est la taille de ce test de version? Pas très. Vous avez déjà testé chaque sprint ... Il ne devrait pas être trop de surprises.

Answer 3

Je dirais que si une activité interne a un avantage pour l'application (que tous les éléments de backlog dans la mêlée devraient avoir), c'est que l'avantage est réalisé. Par exemple, "Architecture de conception" est trop générique pour identifier le bénéfice d'une activité. "Architecture de conception pour user story A" identifie la portée de votre activité. Lorsque vous avez créé une architecture pour l'histoire A, vous en avez terminé avec cette tâche.

Le refactoring devrait également être fait dans le contexte de la réalisation d'une histoire d'utilisateur. "Refactor Client class pour activer plusieurs numéros de téléphone pour prendre en charge Story B" est quelque chose qui peut être identifié comme fait lorsque la classe Customer prend en charge plusieurs numéros de téléphone.

Answer 4

Troisième question "refonte d'un gros module (pour remplacer la nouvelle architecture d'un nouvel environnement par une nouvelle) Bien sûr, cette tâche est répartie sur des douzaines de petites tâches, mais je sais qu'à la fin nous aurons une longue session de débogage /réparer." Chaque sprint crée quelque chose qui peut être libéré. Peut-être que ce ne sera pas le cas, mais ça pourrait l'être.Donc, quand vous avez une refonte majeure, vous devez manger l'éléphant une petite pièce à la fois. Tout d'abord, regardez la plus grande valeur - le plus important - le plus grand retour aux utilisateurs que vous pouvez faire, faire et libérer.

Mais - vous dites - il n'y a pas de si petit morceau; chaque pièce nécessite une refonte massive avant que tout puisse être libéré.

Je ne suis pas d'accord. Je pense que vous pouvez créer une architecture conceptuelle - ce que ce sera quand vous aurez fini - mais ne pas implémenter le tout en même temps. Au lieu de cela, vous créez des interfaces temporaires, des ponts, de la colle, des connecteurs qui feront un sprint.

Ensuite, vous modifiez les interfaces temporaires, les ponts et la colle pour que vous puissiez terminer le prochain sprint.

Oui, vous avez ajouté du code. Mais vous avez également créé des sprints que vous pouvez tester et libérer. Sprints qui sont complets et n'importe qui peut être une version candidate.

Answer 5

Il semble que vous brouilliez la définition de l'utilisateur et de la tâche. Simplement:

• Les user stories ajoutent de la valeur. Ils sont créés par le propriétaire d'un produit. Les tâches sont des activités entreprises pour créer la valeur . Ils sont créés par les ingénieurs .

Vous avez cloué des éléments clés de l'histoire de l'utilisateur en disant qu'ils doivent avoir des critères d'acceptation clairs, qu'ils sont autonomes et qu'ils peuvent être testés.

L'architecture, la conception, le refactoring et le développement de classes d'utilitaires sont tâches. Ils sont ce qui est fait pour compléter une histoire d'utilisateur. Il appartient à chaque magasin de développement d'établir des normes différentes pour ceux-ci, mais dans notre société, au moins un autre développeur doit avoir examiné le code (programmation par paire, lecture de code, révision de code).

Si vous avez des user stories qui sont "refactor class X" et "design feature Y", vous êtes sur la mauvaise voie. Il peut être nécessaire de refactoriser X ou de concevoir Y avant d'écrire du code, mais ceux-ci pourraient être des tâches nécessaires pour accomplir l'histoire de l'utilisateur "créer un nouveau widget de connexion".

Answer 6

Nous avons rencontré des problèmes similaires avec le code «en coulisses». Par «dans les coulisses», je veux dire, n'a aucune valeur commerciale apparente ou testable.

Dans ces cas, nous avons décidé de définir les développeurs de cette partie du code comme étant les vrais "utilisateurs". En créant des exemples d'applications et de documentation que les développeurs pouvaient utiliser et tester, nous avions du code "fait". Habituellement, avec scrum, vous recherchez une fonctionnalité commerciale qui utilise un code pour déterminer «terminé».

Answer 7

Pour les tâches techniques telles que le refactoring, vous pouvez vérifier si le refactoring a été réellement effectué, par ex. call X n'a ​​plus de méthode f(), ou plus de fonction foobar().

Il devrait y avoir de la confiance envers l'équipe et au sein de l'équipe également. Pourquoi voulez-vous vérifier si la tâche est réellement terminée? Avez-vous rencontré des situations où quelqu'un prétendait qu'une tâche avait été effectuée et que ce n'était pas le cas?Pour votre deuxième question, vous devriez d'abord vraiment essayer de le diviser en plusieurs petites histoires (articles de backlog). Par exemple, si vous réarchitrez le système, vérifiez si la nouvelle et l'ancienne architecture peuvent coexister pour effectuer le portage de tous vos composants de l'un à l'autre.

Si cela est vraiment pas possible, cela doit être fait séparément du reste des éléments de backlog de sprint et pas intégré avant qu'il ne soit « fait faire ». Si le sprint se termine avant la fin de toutes les tâches de l'élément, vous devez estimer la quantité de travail restante et la replanifier pour l'itération suivante.

Voici twenty ways to split a story qui pourrait aider à avoir plusieurs articles plus petits en souffrance, avec la méthode recommandée et la plus sûre.