Scrum - Développeurs travaillant en dehors de Sprint

12

L'équipe Scrum

3 x développeurs
2 x testeurs
1 x Analyste de test d'automatisation

Nous ne sommes pas une équipe multifonctionnelle dans la mesure où les développeurs ne testent pas et les testeurs ne développent pas. Je pense que c'est la cause première du problème.

Nous faisons actuellement des sprints de deux semaines.

Au début du sprint, tout le monde est occupé, les développeurs commencent le travail de développement et les testeurs préparent leur test (rédaction de cas de test, etc.)

Une fois que les testeurs ont terminé leur préparation, ils attendent maintenant que le travail de développement soit terminé OU le travail de développement est terminé et les développeurs attendent des commentaires / bogues.

Les développeurs se démangent ici et commencent à travailler sur des éléments du backlog qui sont en dehors du sprint actuel. Cela a créé un effet étrange par lequel nous développons toujours le prochain travail de sprint dans le sprint actuel. Pour moi, cela ne me semble pas juste.

Du point de vue de la direction, ils préfèrent que les développeurs travaillent plutôt que de s'asseoir à leur bureau sans rien faire, mais en même temps, je pense que l'objectif de l'équipe Scrum et que l'accent devrait être uniquement sur le sprint actuel. Je souhaite que notre équipe soit multifonctionnelle mais malheureusement ce n'est pas réalisable. Les testeurs n'ont pas les compétences nécessaires pour effectuer des travaux de développement et la majorité des développeurs estiment que les tests sont en dessous d'eux.

Est-ce considéré comme un problème dans la mêlée? Y a-t-il une solution à cela? Scrum fonctionne-t-il uniquement avec des équipes multifonctionnelles?

J'aimerais connaître les expériences d'autres personnes avec cela si possible :)

agile scrum

— fml
source

3

Je suis d'accord avec la direction. Faire asseoir les gens à cause d'une période arbitraire de deux semaines est une idée terrible. Peut-être que les responsabilités de votre équipe sont trop rigides; dans des équipes aussi petites, il n'est pas rare que tous les membres de l'équipe soient «interfonctionnels», ce qui leur permet d'intervenir là où c'est nécessaire dans le sprint actuel.

— Robert Harvey

... ou peut-être que vous ne mettez pas assez dans vos sprints pour occuper l'équipe pendant deux semaines.

— Blrfl

3

Un mashup de développement / test de paires hybrides est-il pratique? Dans un sens, le processus est le même que le cycle de test unitaire; écrire un petit test un peu. Nous ne l'avions pas officiellement, mais les testeurs avaient l'habitude de nous contacter directement lorsqu'un bug ou deux a été trouvé. Nous n'avons pas communiqué via des rapports de bogues officiels. Au moment où "mon testeur" a terminé les tests, j'ai fini de réparer. Être une application Web a rendu le redressement des correctifs efficace. Mais au moins, expérimentez. Et franchement, même s'il n'est pas meilleur ou pire, le mgt percevra moins de temps d'attente individuel.

— radarbob

3

Le travail qui était initialement prévu pour un sprint est-il généralement terminé avec une qualité suffisante? Ou vous reste-t-il également avec des histoires à moitié terminées par rapport à la planification originale?

— Bart van Ingen Schenau

2

Vous pouvez simplement conserver votre processus mais l'appeler «kanban» au lieu de «scrum», et vous n'avez plus à vous soucier de savoir si votre processus est correct avec scrum. / un peu sarcastique, mais pas vraiment

— Eric King

16

C'est un problème assez courant, causé par le pipelining . L'équipe est multifonctionnelle, mais bien sûr, il existe des silos internes qui diminuent les performances.

Tout d'abord, je voudrais noter quelques points qui, à mon avis, sont importants:

Si vos développeurs effectuent une itération à l'avance, ils anticipent sur votre réunion de planification. Votre chef de produit et l'équipe doivent discuter correctement de ce qui est le plus précieux pour la prochaine itération. La priorisation ne doit pas être effectuée efficacement par les développeurs car ils n'ont rien de mieux à faire.
Peu importe comment vous divisez et organisez les itérations, vous ne pouvez pas vraiment occuper tout le monde tout le temps et avoir une seule équipe avec une seule réunion de planification tant que votre équipe a des spécialistes travaillant en silos. Même avec une approche en cascade pure, vous auriez toujours besoin de "jeter des trucs sur le mur" et d'attendre les commentaires.
Vous avez également le problème que souvent une seule histoire doit avoir une phase de développement, suivie d'une phase de test, suivie d'une phase de correction de bugs, suivie de ... cela peut vraiment rendre votre équipe inefficace - surtout si elle travaille à l'avance , car ils doivent changer de contexte.

Il est clair que cette situation a un coût très réel: l'équipe ne collabore pas. Je l'ai rencontré à chaque fois qu'une équipe d'assurance qualité était impliquée, j'ai donc eu un peu de temps pour expérimenter différentes solutions.

Ce qui a très bien fonctionné pour moi, ce sont ces deux outils:

Soulignez le principe selon lequel toute l'équipe est responsable de faire avancer les choses. Refusez les histoires "dev done", car elles sont un moyen pour les développeurs de dire "ce n'est plus mon problème", ce qui n'est ni constructif ni manifestement faux. Si une équipe ne livre pas une histoire qu'elle a acceptée, c'est toute l'équipe qui n'a pas livré.
Pour occuper le temps des développeurs et du contrôle qualité, associez-les . C'est de loin le meilleur moyen de partager l'expertise et la connaissance du domaine que vous pouvez choisir. Les développeurs peuvent aider les testeurs à automatiser leurs tâches. Les testeurs peuvent montrer aux développeurs où il est important de tester le code car il est fragile. Les deux collaborent et travaillent plus rapidement qu'improbable.

En utilisant ces deux techniques, l'équipe devrait être moins cloisonnée et plus performante. Bien qu'il soit très peu probable que les testeurs et les développeurs soient en mesure d'échanger des emplois, ils pourront travailler en équipe et résoudre le problème en interne, au lieu de se blâmer mutuellement.

— Sklivvz
source

1

Merci pour votre réponse. J'aime vraiment l'idée d'associer le développeur et la ressource QA ensemble. Je vais le suggérer lors de notre prochaine réunion et j'espère que nous pourrons le tester lors du prochain sprint. Je mettrai à jour la question et je vous ferai savoir comment ça se passe!

— fml

@Sklivvz Cela se produit plus souvent que lorsqu'il y a un service d'assurance qualité. Cela arrive à chaque fois que l'AQ est un rôle que seules "certaines personnes" peuvent jouer. Au lieu que la ressource inactive récupère la "prochaine" tâche prioritaire, le développeur se met en veille, puis récupère plus de travail pendant que le contrôle qualité réagit perpétuellement à la sortie du développeur.

— Edwin Buck

1

Si ce n'était pas clair ci-dessus, la "prochaine tâche hautement prioritaire serait" de réduire le carnet de commandes QA afin que les articles puissent être expédiés "et non la prochaine tâche de développement hautement prioritaire du carnet de commandes.

— Edwin Buck

1

Les conseils, comme toute l'équipe sont responsables, alors que cela semble bon, en réalité, ne sert pas l'équipe. Cela suggère que tout le monde est interchangeable et c'est un manque de tout le monde de ne pas intervenir. C'est faux. Chaque membre du SDLC a un rôle particulier et a passé des ANNÉES à perfectionner ses compétences. Demander à un ingénieur logiciel de tester est préjudiciable à la qualité car ils n'ont pas l'expérience nécessaire pour tester la qualité et feront probablement une tentative sans enthousiasme. Même si l'ingénieur QA les encadre, le mentorat prendrait du temps aux tests et rendrait le travail encore plus long.

— Chuck Conway

1

@ChuckConway personne ne suggère ce que vous dites. Le jumelage n'est pas un substitut ou un mentorat. Idéalement, vous faites confiance à l'équipe pour trouver la meilleure façon de minimiser les temps d'arrêt, et cela ne peut commencer que lorsque les gens comprennent les rôles et les besoins des autres. Les équipes les meilleures et les plus efficaces s'organisent (vrai ou pas, c'est un principe de base de l'agilité).

— Sklivvz

2

Il n'y a aucun problème avec la façon dont vous travaillez en rapport avec SCRUM et les sprints, à condition qu'il soit enregistré au moment de l'évaluation que le travail du développeur a été terminé en moins de temps (et combien de temps) que prévu. Cela permettra à l'équipe d'acquérir plus de points d'histoire pour le prochain sprint. Après tout, le but des sprints est de s'améliorer dans la planification. De toute évidence, vous pouvez encore vous améliorer.

nous développons toujours les prochains sprints dans le sprint actuel

Whoa! Ce n'est techniquement pas possible dans Scrum. Vous ne savez pas quels éléments de backlog seront dans le prochain sprint, qui doit être établi au début du prochain sprint dans une session de planification de sprint.

Il reste intéressant de découvrir de nouvelles façons créatives que les organisations inventent pour saboter Scrum.

— Martin Maat
source

3

Le problème avec des déclarations comme "Whoa! Ce n'est techniquement pas possible dans Scrum" et "... de nouvelles façons créatives que les organisations inventent pour saboter Scrum" est qu'elles impliquent qu'il existe une bonne façon de "faire Scrum". Pour qu'il y ait une manière correcte, Scrum doit être proscriptif, c'est-à-dire mettre les processus avant les gens. Scrum n'est donc pas un processus agile s'il existe une façon correcte de faire Scrum.

— David Arno

@David Arno C'est bien, vous dites essentiellement que toute méthodologie est par définition non agile. Même le manifeste agile. Seul un chaos pur et imprévisible serait agile. Mais attendez ... qui me dit d'être chaotique? Sérieux maintenant: l'adagium agile «les gens avant les processus» est là pour résoudre les conflits. Si l'on doit choisir, il faut faire ce qui a du sens, pas nécessairement ce que disent les règles. Il me semble que l'équipe de l'OP pourrait passer par le livre Scrum sans problèmes. Et peut-être le font-ils, la question clé semble être de savoir à quel point ils sont transparents.

— Martin Maat

1

@DavidArno en fait, cela implique seulement qu'il existe de mauvaises façons spécifiques de faire Scrum, et cela ne semble pas controversé. Par exemple, tout ce qui contredit le Manifeste Agile semble objectivement incorrect.

— Sklivvz

1

Scrum optimise pour l' équipe , pas pour l'individu. Le but de la mêlée est que l'équipe devienne efficace. Si les développeurs commencent à travailler sur des choses en dehors du sprint actuel, ils ne rendent pas service à l'équipe. Cela montre également que vous échouez quelque peu dans votre processus de planification, si vous ne planifiez pas suffisamment de travail pour remplir le printemps.

Si les développeurs n'ont plus de tâches de développement, ils doivent absolument intervenir et aider les testeurs ou les rédacteurs techniques ou les concepteurs - n'importe qui dans l'équipe. Ils ne doivent pas nécessairement écrire de tests réels (bien qu'ils le devraient ), mais ils peuvent toujours participer au processus de test. Ils peuvent écrire des scripts qui aident les testeurs à être plus efficaces, ou ils peuvent simplement discuter avec les testeurs de leurs défis et les aider à surmonter ces défis (par exemple: ajouter des attributs id aux éléments de la page Web, fournir des crochets ou des API que les testeurs peuvent utiliser dans leurs tests, etc.).

Je pense que le cœur du problème est que si vos développeurs ne travaillent pas toujours sur le sprint actuel, ils ne travaillent pas encore en équipe. Votre Scrum Master devrait en prendre note et s'efforcer de faire travailler l'équipe en tant qu'unité plutôt qu'en tant que groupe d'individus.

Je suggère également qu'il s'agit d'un problème de gestion. S'ils exercent une pression sur les développeurs pour qu'ils restent occupés, ils n'ont pas complètement adopté Scrum. C'est une autre chose avec laquelle le Scrum Master peut vous aider. Ils peuvent travailler avec la direction pour les aider à comprendre le fonctionnement de Scrum afin d'aider et d'encourager les équipes de développement plutôt que de les renverser.

— Bryan Oakley
source

0

Je pense que le problème clé ici est le suivant:

la majorité des développeurs estiment que les tests sont en dessous d'eux

La façon dont nous avons géré cela dans notre entreprise est que nous avons demandé aux développeurs comment ils pouvaient dire qu'ils avaient effectivement terminé leur travail s'ils ne pouvaient pas le prouver. Bien sûr, la seule façon de le prouver est de démontrer que le code qu'ils ont écrit fonctionne réellement, et cela se fait par le biais de tests. Il convient de leur faire remarquer que s'ils acceptent de participer aux tests, les tests seront effectués plus rapidement et ils auront plus de temps pour coder des fonctionnalités supplémentaires (qui devront également être testées).

Faites remarquer que tester votre code n'est pas en dessous du niveau des développeurs. Il fait partie intégrante du processus de développement. Il ne peut pas être séparé du simple codage. Tout le monde peut coder. Tout le monde ne peut pas coder et prouver que ce qu'il a codé fonctionne réellement.

Une autre façon de garder les développeurs occupés est de les faire travailler sur le codage de tests automatisés pour les fonctionnalités qu'ils ont développées dans le sprint. Ces tests pourraient ensuite être utilisés pour des tests de régression qui seraient exécutés périodiquement.

Quoi qu'il en soit, faire quelque chose qui n'était pas prévu au début du sprint est un gros non. Il vaut mieux ne rien faire, que de faire quelque chose qui n'était pas prévu. La fonctionnalité qu'ils écrivent dans ces cas ne répond probablement pas aux critères DoD (Definition of Done), car elle n'est probablement pas bien testée, car les testeurs étaient occupés à tester ce qui était initialement prévu. C'est une façon infaillible d'introduire des bogues et de détériorer la qualité du produit, ce qui envoie ensuite l'équipe dans une spirale descendante de problèmes de régression et de changement de contexte, ce qui entraîne du stress, une vitesse réduite et enfin, quitte l'équipe à cause de cela.

— Vladimir Stokic
source

Je dirais que les programmeurs testent le code, ils ne créent tout simplement pas de tests automatisés. Il y a une grande différence.

— JeffO

Dans ce cas particulier, je suis prêt à parier que le seul test que ces programmeurs font est celui d'IDE. Peu de développeurs intègrent réellement la solution dans un package d'installation, déploient le package à partir de zéro comme le ferait l'utilisateur final, puis testent réellement la solution. Dans la plupart des cas, cela ne suffit pas et est une raison de détérioration significative de la qualité.

— Vladimir Stokic

0

En théorie, tous les membres d'une équipe SCRUM devraient avoir les mêmes connaissances, afin que chaque membre puisse prendre chaque tâche de chaque autre membre. Sinon, vous devez diffuser les connaissances.

Mais dans la pratique, il y a toujours une sorte de spécialisation. Le logiciel peut être complexe, les membres de l'équipe ont des compétences différentes, etc. La division de l'équipe en développeurs et testeurs n'est qu'un exemple (très courant) de spécialisation.

La diffusion des connaissances peut prendre plus de temps que la direction ne veut en accepter.

D'après mon expérience, vous pourriez faire plusieurs choses:

Ne rendez pas l'équipe trop petite. Si vous avez par exemple 4 développeurs et 4 testeurs, il est beaucoup plus facile de déplacer une tâche vers un autre développeur ou testeur que d'en avoir seulement 3/2 comme sur cet exemple.
Essayez de diviser les tâches plus importantes. Si vous avez des tâches plus petites, vous serez plus flexible.
Définissez certaines tâches facultatives qui pourraient être effectuées s'il reste du temps.

Ces suggestions peuvent ne pas être une théorie 100% SCRUM, mais vous devez d'abord continuer à travailler sur le développement. SCRUM n'est qu'une boîte à outils.

— bernie
source

0

Il semble que vous devez désychroniser votre équipe. Comme ça:

   Test.   -------s1 -----------s2
   Dev.        --------s1 -----------s2

Si j'ai bien compris, les gars de l'automatisation des tests doivent commencer quelques jours plus tôt.

Mais je sens un problème dans votre équipe: j'ai un problème avec les développeurs qui ne testent pas leur propre code. Si les testeurs préparent le test sans revoir le code, ils ne font probablement que des tests de blackbox qui ne prennent pas en compte les points de décision du programme développé. Vous êtes satisfait de la qualité de votre logiciel?

— Lucas
source