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

33

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?

holdenmcgrohen
la source
9
Vous semblez craquer pour le mythe
Nathan Cooper
1
@holdenmcgrohen Comment les estimations sont-elles faites - planifiez-vous le poker ou autre chose?
Robbie Dee
3
Les testeurs devraient rédiger des scénarios de test dès le premier jour. Tout ce qu'ils ont besoin de faire, ce sont les histoires. Si les développeurs ont des temps d'arrêt importants pendant le sprint, cela signifie que vous ne prenez pas assez d'histoires. De plus, si vos testeurs sont bons, ils tiennent vos développeurs occupés par des rapports de bogues vers la fin du sprint. En outre, idéalement, les quelques articles les plus importants de l'arriéré sont précisés. Les développeurs peuvent donc, dans le pire des cas, travailler sur l'un des deux meilleurs éléments de l'arriéré.
Gort the Robot
1
@holdenmcgrohen, nous sommes également confrontés au même problème dans notre projet. Nous avons commencé à ajouter des histoires Stretch (ne devrait pas être « indispensable ») dans le cadre du sprint et n'est sélectionné que lorsque les développeurs sont à court de tâches. Maintenant, cette approche nous aide à garder les testeurs occupés les premiers jours du prochain sprint.
user6005214
1
N'oubliez pas que dans la plupart des sprints, vous sélectionnez un sous-ensemble de tâches à partir d'un carnet de commandes . Si vous accomplissez tout ce que vous avez promis, vous avez une longueur d'avance sur le prochain sprint en commençant à travailler sur plus d'éléments de l'arriéré - comme si vous écrasiez, vous retirez moins d'éléments de l'arriéré lors du prochain sprint. peut finir ceux qui n'étaient pas finis. Dump dogme; Sachez que le but de l’outil est de vous servir et non de vous servir de cet outil.
Keshlam

Réponses:

49

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.
Encaitar
la source
Oui, oui et oui. Spot sur réponse dans tous les sens.
David Arno
Bonne réponse - le dernier paragraphe a besoin de travail. Soulevez et expliquez les points ici plutôt que de pointer vers un tome.
Robbie Dee
1
Qu'ont fait vos développeurs lors d'une phase de test en cascade? - Je ne voulais pas comparer scrum à watefall, mais plutôt à des approches de type kanban, où il y a toujours une liste de tâches à effectuer qui sont déjà évaluées et classées par ordre de priorité. Le backlog Scrum contient des fonctionnalités qui n'ont pas été correctement examinées par l'équipe. Par conséquent, si un seul développeur (qui ne dispose actuellement d'aucune fonctionnalité sur laquelle travailler) décide de commencer à implémenter l'une d'elles au milieu du sprint, cela peut avoir des conséquences inattendues. .
Holdenmcgrohen
@holdenmcgrohen assez juste. Mon estimation est toujours terrible, ce que j'essaie de rendre compte, alors j'aime toujours avoir quelque chose à côté. Je pense que des rencontres quotidiennes peuvent aider ici, si vos développeurs ne sont pas laissés seuls trop longtemps, ils ne peuvent pas aller trop loin.
Encaitar
@Encaitar Très bien +1
Robbie Dee
20

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.

Bryan Oakley
la source
1
+1 Les processus agiles exigent du mou. Afin d'optimiser un système, vous devez souvent désoptimiser les sous-processus. Dans ce cas, vous avez dit le mieux avec "l'optimisation de l'équipe". Tout le reste est un symptôme de l'erreur d'utilisation.
CodeGnome
Au début de ma carrière, j'ai rencontré des sociétés qui s'attendaient à ce que leur candidat travaille sur tous les logiciels PHP, Java, C #, applications de bureau (VB), QA (automatisé, manuel), Photoshop, CSS, etc. À cette époque, l’industrie considérait que ces entreprises étaient moins professionnelles en raison de leur valeur de spécialisation. Je me demande si le même modèle est accepté (voire même devenu une nécessité) sous Agile.
kuldeep.kamboj
1

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é.

Robbie Dee
la source
8
Lisez le guide Scrum . Vous trouverez peut-être un élément qui indique qu'il est correct de diviser l'équipe de développement en testeurs et développeurs (conseil, vous ne le ferez pas).
Nathan Cooper
3
Le document ne dit pas que vous avez des membres de l'équipe de développement spécialisés, mais vous ne pouvez pas séparer un groupe pour le traiter comme des "poulets".
Nathan Cooper
5
Pour les électeurs défavorisés, quelle partie de la formation Agile vous a manqué là où il est spécifié que vous devez adopter une stratégie qui fonctionne pour votre équipe ? L'équipe de Robbie Dee a adopté ce qui a fonctionné pour eux dans leurs circonstances uniques, avec leur projet unique et leurs contraintes environnementales. Chaque entreprise a des barrières environnementales et des "dommages" qui doivent être acheminés. Cela semble être une approche parfaitement acceptable de la question qui a été posée . La question ne portait pas sur la meilleure façon d’organiser les testeurs et les efforts de test sur votre équipe de sprint.
maple_shaft
4
Non. Le PO a spécifiquement posé des questions sur Scrum. Vous ne pouvez pas faire ce que vous voulez et appelez ça Scrum. Cela peut être agile ou non, mais avoir des parties de votre "équipe" interfonctionnelle traitées comme des ressources externes ou comme un élément autre que les membres de première classe de l'équipe de développement n'est pas Scrum.
CodeGnome
2
@CodeGnome a tout à fait raison et aborde un point que je soulève toujours : l’agile est une philosophie, Scrum est une mise en œuvre de cette philosophie. Les deux ne sont pas la même chose et respectent des règles distinctes. (Oui, Scrum est arrivé en premier, mais a par la suite été modifié pour devenir une implémentation Agile)
-2

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.

nvoigt
la source
6
Les personnes en forme de T sont une chose, faire écrire du code par les testeurs (à moins que nous ne parlions d'automatisation de test) en est une autre.
Robbie Dee
2
Cela suppose simplement que seuls les testeurs ont des temps morts dans le sprint? Les développeurs ont également des temps morts.
maple_shaft
Je suppose que les développeurs peuvent faire des tests sans formation supplémentaire. Là où je vis, cela fait partie de l'éducation et du travail.
nvoigt