Scrum - Quels sont les membres de l'équipe occupés pendant un sprint
Ainsi, un sprint scrum est une période de temps fixe pendant laquelle un ensemble spécifique de fonctionnalités doit être implémenté. Et une équipe Scrum est composée de toutes les personnes engagées à fournir ces fonctionnalités, la majorité d'entre elles étant généralement des développeurs et des testeurs.
Après avoir établi ces règles, on peut se demander comment garder toutes ces personnes occupées pendant tout le sprint. Au début du sprint, il n'y a encore rien à tester, et à la fin du sprint, il ne reste généralement rien ou très peu à développer/corriger.
J'ai vu 2 approches pour gérer cela, mais aucune ne semble résoudre correctement le problème.
1) Laissez les membres de l'équipe décider quoi faire quand ils sont hors des tâches.
Les inconvénients:
- Si ce qu'ils font n'est pas planifié à fond (c.-à-d. Refactorisation majeure, passage à un nouveau cadre de test), leur travail peut s'avérer inutile ou être bloqué à mi-parcours
- D'un autre côté, planifier 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 estimées de manière approfondie, il est donc assez facile pour les travailleurs sans scrupules de passer leur temps à regarder des chats YouTube sans que cela se reflète sur la mêlée ou ailleurs
2) Faites de la place dans le sprint uniquement pour le développement et commencez les tests une fois le sprint terminé (lorsque les développeurs commencent à travailler sur les fonctionnalités du sprint suivant)
Les inconvénients:
- Lors du développement de fonctionnalités pour le sprint actuel, les développeurs sont distraits en corrigeant les bogues du précédent, et ils peuvent ne pas effectuer la quantité de travail qui a été estimée être effectuée pendant le sprint actuel
- Deux tableaux de mêlée sont nécessaires: un pour les fonctionnalités de sprint actuelles et un pour les bugs de sprint précédents
Ma question est donc la suivante: comment répartir correctement le travail pendant le sprint entre les développeurs et les testeurs afin que personne ne soit surchargé de travail ou se retrouve sans tâches à 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 il n'y a encore rien à tester
Vraiment? Vous n'avez aucune exigence à valider? Pas de discussions à avoir avec votre client? Pas de fil de fer à évaluer? Aucun plan de test auquel penser?
à la fin du sprint, il ne reste généralement rien ou très peu à développer/corriger
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? À quoi ressemble 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 backlog. 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'. Je m'en fichais de ça. Mais je pense que vous avez deux problèmes ici:
Un service d'assurance qualité "traditionnel" qui teste le code une fois qu'il est "terminé" 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 la bonne. Jetez un œil aux quadrants de tests 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.
Essayer de s'en tenir trop étroitement à un calendrier SCRUM de sprints de 1 semaine/2 semaines sans avoir un backlog priorisé et dimensionné qui est divisé en tâches qui sont assez faciles à réaliser dans un court laps de temps dans un seul sprint. Si vous aviez cela, il y aurait toujours plus de travail à faire. Peut-être que la dernière fonctionnalité sur laquelle vous travaillez dans ce sprint n'entre pas dans la version de ce sprint, mais elle peut toujours aller dans la suivante.
De côté. Si vous avez une petite équipe cohésive, les rôles importent moins. Au lieu d'avoir quelqu'un avec le testeur d'étiquettes qui n'est pas autorisé à écrire du code de production, ou quelqu'un étiqueté un développeur qui pense être au-dessus des tests, tout le monde devrait faire tout ce qui est nécessaire pour que l'équipe réussisse, y compris les tâches de gestion de projet redoutées lorsque ils sont nécessaires, c'est ce qu'on appelle une équipe interfonctionnelle.
Un point supplémentaire soulevé par @Cort Ammon dans les commentaires. Le manifeste agile parle de la collaboration client sur la 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 ce serait un gros 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 professionnellement dans leur intérêt, alors vous avez un problème ou ils le font.
J'ai écrit n article qui parle des développeurs de logiciels qui ne sont pas considérés comme des professionnels. Un médecin professionnel, un avocat, un ingénieur civil confronté à un client qui a modifié les exigences à mi-chemin ne réduirait pas seulement la qualité et gémirait à ce sujet. Ils diraient à leurs clients que ce serait un problème. Si le client poussait, un professionnel ne le ferait pas aveuglément à un niveau dangereusement inférieur, car il serait responsable. Nous ne passons pas d'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 le 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 y a beaucoup de vidéos de chats, soit vous avez de mauvais développeurs, soit vous les traitez mal.
- La communication. Si vos développeurs se parlent, aux testeurs, à la direction, au client, alors tout le monde devrait probablement 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 consiste à optimiser l'équipe, pas 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 faisais partie, 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 il n'y a encore rien à tester,
Bien que cela puisse être vrai au sens littéral, cela implique que vous pensez que le seul travail pour un testeur est de "tester". Il y a beaucoup à faire avant de commencer le test. 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 à travailler sur un plan de test, à collecter des données de test, etc. S'ils ont le luxe d'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/corriger
Je n'ai pas encore vu une équipe de développement qui n'a plus de choses à réparer. 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 à écrire des tests automatisés, ils peuvent réviser les tests de code et les appareils/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 quand ils sont hors des tâches.
Le défaut de votre réflexion est que les individus sont à court de tâches. Les tâches appartiennent à l'équipe dans son ensemble. Ils ne devraient pas faire d'autre travail tant qu'il reste des histoires ou des tâches pour l'équipe dans le sprint en cours.
Faites 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. L'intérêt de l'agilité est qu'une équipe entière est impliquée dans la réalisation d'un objectif commun. Cela signifie que tous le travail requis pour terminer une histoire doit être représenté dans un sprint - conception, développement, test, documentation, etc.
Enfin, ce n'est pas la seule autre solution viable. Vous négligez la vraie solution, qui est que chaque membre de l'équipe devrait intervenir au besoin pour aider à terminer les histoires dans un sprint.
L'objectif est un équipe objectif, 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 sur quoi on travaille actuellement et proposer de l'aider. Ou, ils peuvent prendre la prochaine tâche ou histoire et commencer à travailler dessus.
Dans toutes les boutiques agiles dans lesquelles j'ai travaillé, les testeurs sont considérés comme poulets donc ils ne sont pas classés dans le sprint comme les développeurs. Avant de mettre la main sur le logiciel, les testeurs doivent rédiger des plans et s'assurer que les environnements sont correctement configurés pour recevoir le logiciel. Dans le cadre de cela, ils devraient surveiller tous 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 bien sûr un art noir, donc elle remplit rarement exactement .
Si un développeur a du temps libre à la fin du sprint, ce temps doit toujours être suivi pour s'assurer qu'il ajoute de la valeur (apprentissage d'un nouveau cadre, analyse, tests supplémentaires, etc.).
La correction de bugs est une activité parfaitement acceptable à mettre dans un sprint. Il contribue à une fonctionnalité et ajoute ainsi de la valeur. Cela ne doit pas être considéré comme du temps volé lors du prochain sprint - mieux terminer une fonctionnalité.