Scrum - Quels sont les membres de l'équipe occupés pendant un sprint

Ainsi, un sprint Scrum est une période de temps fixe au cours de laquelle un ensemble spécifique de fonctionnalités doit être implémenté. Et une équipe Scrum se compose de toutes les personnes engagées dans la fourniture de ces fonctionnalités, la majorité d’entre elles étant généralement des développeurs et des testeurs.

Ayant établi ces règles, on peut se demander comment garder toutes ces personnes occupées pendant tout le sprint. Au début du sprint, rien n’a encore été testé, et à la fin du sprint, il n’ya généralement plus rien ou très peu à développer / réparer.

J'ai vu 2 approches pour gérer cela, mais aucune d'elles ne semble résoudre correctement le problème.

1) Laissez les membres de l’équipe décider quoi faire chaque fois qu’ils sont à court de tâches.

Les inconvénients:

• Si ce qu'ils font n'est pas planifié de manière approfondie (refactorisation majeure, passage à un nouveau cadre de test), leur travail peut s'avérer inutile ou être bloqué à mi-parcours.
• D'autre part, la planification d'un tel travail peut prendre beaucoup de temps et le client peut être déçu de voir l'équipe perdre du temps sur quelque chose qui n'apporte pas de valeur immédiate.
• De telles tâches ne peuvent généralement pas être évaluées avec précision. Il est donc très facile pour les travailleurs sans principes de passer leur temps à regarder des chats YouTube sans que cela se répète sur le tableau de bord ou ailleurs.

2) Faites de la place dans le sprint uniquement pour le développement et démarrez les tests une fois le sprint terminé (lorsque les développeurs commencent à travailler sur les fonctionnalités du prochain sprint)

Les inconvénients:

• Lors du développement de fonctionnalités pour le sprint actuel, les développeurs sont distraits par la correction des bogues du précédent et ils peuvent ne pas réussir à effectuer la quantité de travail estimée à être effectuée pendant le sprint actuel.
• Deux tableaux de mêlée sont nécessaires: un pour les fonctionnalités actuelles du sprint et un pour les précédents bugs du sprint

Ma question est donc la suivante: comment répartir correctement le travail entre les développeurs et les testeurs pendant le sprint, afin que personne ne soit surchargé de travail ou ne se retrouve sans tâche à aucun moment? Existe-t-il des moyens d'améliorer les approches décrites ci-dessus? Ou existe-t-il de meilleures approches?

Au début du sprint, rien n’a encore été testé

Vraiment? Vous n'avez aucune exigence à valider? Aucune discussion à avoir avec votre client? Pas de fil de fer à évaluer? Pas de test à prévoir?

à la fin du sprint, il ne reste généralement rien ou très peu à développer / réparer

Je n'ai jamais été à cet endroit dans un projet. Plus de travail à faire? Il y a toujours quelque chose. Tous vos tests sont-ils entièrement automatisés? Comment se présente votre CI? La couche d'accès à la base de données pourrait-elle être refactorisée pour être plus simple? Et je n'ai jamais travaillé sur quoi que ce soit avec une liste de bogues vide et un arriéré. Qu'ont fait vos développeurs lors d'une phase de test en cascade?

Je sais que certaines personnes deviennent très religieuses sur ce qui est et ce qui n'est pas «SCRUM». Cela m'est égal. Mais je pense que vous avez deux problèmes ici:

1. Un département QA «traditionnel» qui teste le code une fois qu'il est «fini» par les développeurs plutôt que de travailler avec les clients et les développeurs pour s'assurer que vous construisez la bonne chose ainsi que vous la construisez correctement. Jetez un coup d'œil aux quadrants de test agiles de Lisa Crispin. Les meilleurs testeurs sont impliqués à chaque étape du cycle de vie du développement logiciel et les meilleurs développeurs écrivent leurs propres tests.

2. Essayez de vous en tenir trop à un emploi du temps SCRUM de sprints d'une semaine ou de deux semaines sans disposer d'un arriéré hiérarchisé et hiérarchisé divisé en tâches assez faciles à effectuer dans un court laps de temps au cours d' un seul sprint. Si vous aviez cela, il y aurait toujours plus de travail à faire. Peut-être que le dernier long métrage sur lequel vous travaillez dans ce sprint n'entre pas dans la sortie de ce sprint, mais il peut toujours aller dans le prochain.

De côté. Si vous avez une petite équipe soudée, les rôles importent moins. Au lieu d'avoir une personne avec le testeur d'étiquettes qui n'est pas autorisée à écrire le code de production, ou une personne appelée développeur, qui pense être au-dessus des tests, tout le monde devrait faire le nécessaire pour que l'équipe réussisse, y compris les tâches de gestion de projet redoutées lorsque ils sont nécessaires, cela s'appelle une équipe interfonctionnelle.

Un point supplémentaire soulevé par @Cort Ammon dans les commentaires. Le manifeste agile parle de collaboration client sur négociation de contrat. Vous dites que:

le client peut être déçu de voir l'équipe perdre du temps sur quelque chose qui n'apporte pas de valeur immédiate

Cela peut être difficile à expliquer et je comprends que les clients peuvent être très difficiles parfois, mais cela serait un grand drapeau rouge pour moi. Ils vous font confiance avec leur code source / relation client / entreprise / tout ce que vous développez pour eux. S'ils ne peuvent pas vous faire confiance pour agir de manière professionnelle dans leur meilleur intérêt, alors vous avez un problème ou ils le font.

J'ai écrit un article sur les développeurs de logiciels qui ne sont pas considérés comme des professionnels. Un médecin professionnel, un avocat, un ingénieur du génie civil confronté à un client qui modifierait partiellement les exigences à son égard ne réduirait pas seulement la qualité et le gémir. Ils diraient à leurs clients que ce serait un problème. Si le client le poussait alors un professionnel ne le ferait pas aveuglément à un niveau dangereusement inférieur, car il serait responsable. Nous ne passons pas les examens d'entrée professionnels et ne sommes donc pas responsables. Cela ne signifie pas que nous ne devrions pas essayer d’être meilleurs.

En résumé, je ne m'inquiéterais pas trop d'essayer d'amener les gens à être plus efficaces au début et à la fin d'un sprint, mais plutôt de le voir comme un symptôme d'un problème plus large au sein de l'équipe. Avez-vous entendu parler de eXtreme Programming (XP) . Je dirais que les principes de XP à appliquer ici sont la communication et le respect:

• Respectez votre équipe pour faire ce qu’elle pense être le mieux. Je dirais que s’il ya beaucoup de vidéos de chats à regarder, alors vous avez des développeurs médiocres ou vous les traitez mal.
• La communication. Si vos développeurs communiquent entre eux, avec les testeurs, avec la direction, avec le client, tout le monde devrait avoir une bonne idée de ce qui se passe ensuite et, s’ils ne le font pas, ils peuvent simplement demander.

Le premier point est que Scrum concerne l'optimisation de l'équipe , et non de chaque individu. Si l'équipe est productive et efficace, peu importe si quelqu'un est inactif au début ou à la fin de la tâche.

Cependant, dans chaque équipe où je suis entré, il y a toujours beaucoup de travail. Permettez-moi de répondre à quelques-unes de vos préoccupations spécifiques:

Au début du sprint, rien n’a encore été testé,

Bien que cela puisse être vrai au sens littéral, cela implique que vous pensez que le seul travail d'un testeur est de "tester". Il y a beaucoup à faire avant qu'ils ne commencent à tester. D'une part, ils peuvent rencontrer le propriétaire du produit et les développeurs pour bien comprendre les exigences. Ils peuvent être occupés à élaborer un plan de test, à rassembler des données de test, etc. S'ils ont le luxe d'avoir un bon framework, ils peuvent commencer à écrire des tests automatisés à l'avance.

à la fin du sprint, il ne reste généralement rien ou très peu à développer / réparer

Je n'ai pas encore vu une équipe de développement à court de problèmes à résoudre. Cependant, ce n'est pas ce qu'ils devraient faire à la fin du sprint. Vers la fin du sprint, ils devraient aider les testeurs à tester le produit. Ils peuvent aider à rédiger des tests automatisés, ils peuvent aussi procéder à des tests de révision de code et à des fixtures / mots-clés / etc. écrits par les testeurs. Ils peuvent travailler avec l'équipe de documentation pour les aider à terminer leur travail, etc.

J'ai vu 2 approches pour gérer cela ... 1) Laissez les membres de l'équipe décider quoi faire chaque fois qu'ils sont en dehors des tâches.

Le défaut de votre pensée est que les individus sont à court de tâches. Les tâches appartiennent à l'équipe dans son ensemble. Ils ne doivent pas effectuer d'autres tâches tant qu'il reste des histoires ou des tâches à l'équipe dans le sprint en cours.

Faire de la place dans le sprint uniquement pour le développement,

Cette approche ne fait pas partie de la définition traditionnelle de scrum ou agile. Le point essentiel de l'agilité est que toute une équipe est impliquée dans la poursuite d'un objectif commun. Cela signifie que tout le travail requis pour terminer une histoire doit être représenté dans un sprint - conception, développement, tests, documentation, etc.

Enfin, ce n’est pas la seule autre solution viable. Vous négligez la vraie solution, à savoir que chaque membre de l’équipe doit apporter sa contribution au besoin pour aider à finir les histoires dans un sprint.

L'objectif est un objectif d' équipe , mais vous écrivez comme si chaque personne avait des objectifs individuels ("terminer mes tâches"). Si quelqu'un n'a rien à faire, il peut voir ce qui est en train d'être travaillé et proposer son aide. Ou bien, ils peuvent prendre la tâche ou l'histoire suivante et commencer à travailler dessus.

Dans tous les magasins agiles dans lesquels j'ai travaillé, les testeurs sont considérés comme des poulets , ils ne sont donc pas limités dans le sprint comme les développeurs. Avant de mettre la main sur le logiciel, les testeurs doivent rédiger leurs plans et s’assurer que les environnements sont correctement configurés pour recevoir le logiciel. Dans ce cadre, ils devraient regarder de près les documents de conception tels qu’ils sont.

Ensuite, vous devriez chercher à remplir le sprint. Il ne devrait pas y avoir de temps libre à la fin du sprint si les estimations sont bonnes, bien que l'estimation soit un art noir, elle se remplit donc rarement avec précision .

Si un développeur dispose de temps libre à la fin du sprint, vous devez toujours suivre ce temps pour vous assurer qu'il apporte une valeur ajoutée (apprentissage d'un nouveau cadre, analyse, tests supplémentaires, etc.).

La correction des bogues est une activité parfaitement acceptable pour un sprint. Il contribue à une fonctionnalité et ajoute ainsi de la valeur. Cela ne doit pas être vu comme du temps volé lors du prochain sprint - pour mieux finir une fonctionnalité.

Dans un monde idéal, votre équipe serait interfonctionnelle . Tout le monde a sa spécialisation, mais tout le monde peut également travailler comme une autre spécialisation. Si vos testeurs ne peuvent pas coder les tâches les plus simples, vous n’avez pas d’équipe interfonctionnelle.

La méthode SCRUM serait de permettre à votre équipe d’ être interfonctionnelle. Quoi qu'il en soit, vos testeurs devraient avoir des compétences en automatisation de test. Il ne s'agit que d'un pas en avant pour coder certaines choses moins complexes.