Scrum Process Management - Conseils, pièges, idées [fermé]

Question

Je fais de la mêlée avec une équipe depuis un moment, mais les choses semblent compliquées pour certaines raisons. J'ai réfléchi à la façon dont ils pourraient être changés et j'ai quelques questions que je voudrais poser ici.

Tout d’abord, quel devrait être le rôle des testeurs, des concepteurs et des non-développeurs dans le processus Scrum? S'ils sont égaux aux autres membres de l'équipe, quelques problèmes se posent. Les concepteurs et les testeurs travaillent généralement sur une tâche une fois le développement terminé. Ils ne peuvent donc pas planifier correctement un sprint en raison de cette dépendance.

Deuxièmement, nous avons des délais. Celles-ci sont strictes et ont beaucoup d'impact sur la priorisation. Le résultat final est des modifications de l'arriéré au milieu d'un sprint en raison de modifications des délais ou de mauvais résultats à la fin du sprint. Nous avons également beaucoup de travail non technique tel que le support client qui doit être fait entre-temps et ne peut pas être planifié car il varie beaucoup. Je pense donc que la structure, la culture et les pratiques de l’équipe ne sont pas compatibles avec Scrum. Scrum for me est un outil de gestion de processus destiné aux équipes travaillant au développement d'un seul logiciel.

Que pensez-vous de l’appliquer dans des scénarios plus spécifiques et plus complexes? Avez-vous une expérience à partager?

Answer 1

En général, les testeurs et les documentateurs (et autres non-développés) sont des membres égaux d’une équipe Scrum. L'idée derrière cela est de minimiser les risques.

Exiger une définition de done, qui inclut un produit potentiellement livrable, entièrement testé et documenté, oblige le projet à se réunir à la fin de chaque sprint.

Si le test ne commence pas avant APRÈS le dev. C'est fait, ce qui se passe, c'est que beaucoup de bugs sont découverts après que les développeurs aient fini avec une tâche. Vous devez maintenant corriger ces bogues, ce qui est très lent et coûteux, à la fois parce que les bogues interagissent et que la règle générale est la suivante: "Le coût de la correction d'un bogue augmente de façon exponentielle avec le temps." Les bogues que vous attrapez tôt sont économiques et faciles à corriger, les bogues tardifs sont un cauchemar.

C'est pourquoi vous souhaitez que les tests (et la documentation) évoluent au même rythme que le développement. Et maintenant vous devriez demander, comment! Les tests sont lents, comment diable peut-il se déplacer au même rythme que dev?

La solution, c’est l’automatisation, c’est-à-dire que SCRUM s’appuie toujours sur XP ou Agile, tous deux exigent une excellente couverture de test unitaire et un TDD. Voici un autre casse à surveiller. Les développeurs de fonctionnalités devraient être ceux qui écrivent à la fois, le test unitaire et le test système. Toute l'automatisation des tests doit être effectuée par le dev. équipe. Certains endroits divisés par dev. de l'automatisation dev. et c'est mauvais.

OK, vous disposez maintenant de tests automatisés de qualité et vous les exécutez AU MOINS une fois par jour. Et évidemment, vous pratiquez l'intégration continue, n'est-ce pas? Cela réduit énormément la charge de travail des testeurs. Et c'est ainsi que les tests peuvent rester en phase avec dev. Encore une chose, les testeurs travaillent maintenant sur des choses vraiment difficiles et créatives qu'il est impossible ou très difficile d'automatiser, chaque fois qu'ils trouvent un bogue de cette façon, tout ce qu'il faut pour exposer le bogue est automatisé et fait partie des tests de régression quotidiens. . Ouf, c'est une longue réponse!

Passons maintenant à la deuxième partie de votre question. Scrum concerne la discipline. Les sprints sont courts et les modifications de l'arriéré au cours d'un sprint ne devraient PAS se produire. Le travail non technique devrait être confié à une équipe de support client et ils peuvent faire Scrum à ce sujet. Vous avez raison de dire que cela ressemble à votre culture et à vos pratiques sont incompatibles avec Scrum.

D'après mon expérience, la transition vers Scrum / Agile est un processus très douloureux et stressant, et la plupart des tentatives de transition échouent. L'une des clés du succès est un champion de Scrum / Agile dans l'équipe de direction. D'après votre description, il semble que vous n'en ayez pas.

Scrum comporte des coûts et des avantages, mais si vous le faites mal, vous risquez d’engager des coûts avec peu ou pas d’avantages. Si vous faites Scrum mal et mal, vous feriez mieux de ne pas le faire du tout.

Answer 2

  

Tout d’abord, quel devrait être le rôle des testeurs, des concepteurs et des non-développeurs dans le processus Scrum? S'ils sont égaux aux autres membres de l'équipe, quelques problèmes se posent. Les concepteurs et les testeurs travaillent généralement sur une tâche une fois le développement terminé. Ils ne peuvent donc pas planifier correctement un sprint en raison de cette dépendance.

Si les concepteurs et les testeurs ne peuvent pas planifier un sprint en raison d'une dépendance au développement, cela signifie que votre développement n'est pas planifié correctement. C’est un problème qui doit être résolu.

Votre équipe doit pouvoir dire "La tâche B nécessite que la tâche A soit effectuée en premier. La tâche A prendra 8 heures, puis la tâche B, 4 heures. Si vos estimations de tâches sont précises, les dépendances ne posent aucun problème.

  

Deuxièmement, nous avons des délais. Celles-ci sont strictes et ont beaucoup d'impact sur la priorisation. Le résultat final est des modifications de l'arriéré au milieu d'un sprint en raison de modifications des délais ou de mauvais résultats à la fin du sprint. Nous avons également beaucoup de travail non technique tel que le support client qui doit être fait entre-temps et ne peut pas être planifié car il varie beaucoup.

Si cela se produit, le problème est que vous ne faites pas Scrum. Scrum ne fonctionne que si la direction souscrit complètement au processus. Cela signifie laisser vos développeurs seuls pendant 30 jours pendant qu'ils travaillent sur leur sprint prévu et ajouter de nouveaux travaux à l'aide des méthodes que Scrum a mises en place à cet effet. Vous ajoutez des éléments de la liste de souhaits au carnet de produit, puis lors de la planification du sprint, les développeurs et les parties prenantes s’accordent sur ce qui sera traité lors du prochain sprint.

Si des problèmes de support client interrompent régulièrement le développement normal, vous devez sérieusement envisager de diviser l'équipe, de créer un groupe dédié au développement dans Scrum et de charger un autre groupe de s'occuper des problèmes de support client. Vous pouvez ensuite faire alterner les personnes à la fin de chaque sprint.

Answer 3

Vous ne devriez vraiment pas ajouter de modifications au carnet de commandes de Sprint en fonction des modifications apportées à mi-Sprint. Elles devraient uniquement figurer dans le carnet de commandes des produits et être ignorées jusqu'à la fin du Sprint.

Vous devriez aligner vos échéances sur les sprints. Je pense qu'il est acceptable de suspendre une tâche à mi-sprint sans en introduire une nouvelle.

Si vous constatez que vous ajoutez de nombreuses tâches à mi-chemin du sprint, vos sprints sont probablement trop longs. N'oubliez pas que vous visez environ 20 jours de travail dans chaque sprint et que vous commencez à avoir les problèmes que vous décrivez!

Les testeurs sont importants pour tout processus Agile, mais ne rentrent pas vraiment dans Scrum où la théorie est que toute personne sans tâche active choisit la tâche suivante. Essayer de choisir des associations entre les tâches et les gens commence à entrer dans la planification, ce que tout cela visait à éviter!

Les testeurs, s'ils travaillent à proximité des développeurs, peuvent aider à déterminer si un élément du travail est réellement terminé!

Answer 4

Tout d'abord, vous n'utilisez pas du tout Scrum, vous utilisez peut-être certaines pratiques Scrum, mais pas tout le processus.

Les concepteurs et les testeurs travaillent généralement sur une tâche après le développement. Ils ne peuvent donc pas planifier correctement un sprint en raison de cette dépendance.

Il n’existe aucune relation de dépendance entre tâches, qui se produit rarement et capacité de planifier correctement. Lors de la planification du sprint, l’équipe doit estimer les histoires relatives à la définition de «fait». Si cela inclut, et cela devrait vraiment, concevoir et tester l’histoire, l’estimation de l’effort nécessaire pour satisfaire aux critères d’acceptation de l’histoire doit inclure la conception et les tâches de test.

  

Le résultat final est des modifications de l'arriéré au milieu d'un sprint en raison de changements d'échéance ou de mauvais résultats à la fin du sprint.

Il semble que la longueur de votre sprint soit plus large que nécessaire. Pourquoi n'essaies-tu pas de le raccourcir? Une bonne longueur de sprint est la longueur que vous pouvez vous engager pour conserver les modifications hors du sprint. Je suppose qu'une semaine fonctionnerait.

Et ce comportement démontre que votre Scrum Master ne fait pas son travail correctement car il ne supprime pas les obstacles.