Aidez-moi à comprendre comment l'AQ fonctionne dans Scrum
Apparemment, nous utilisons la méthodologie de développement Scrum. Voici généralement comment cela se passe:
Les développeurs se débattent pour essayer d'accomplir leurs tâches. Généralement, les tâches prennent la plupart du sprint à terminer. QA harcèle Dev pour publier quelque chose qu'ils peuvent tester, Dev envoie enfin du code buggé à QA un jour ou deux avant la fin du sprint et passe le reste du temps à corriger les bogues que QA trouve. QA ne peut jamais terminer les tâches à temps, les sprints sont rarement libérables à temps, et Dev et QA ont quelques jours misérables à la fin du sprint.
Comment la mêlée est-elle censée fonctionner lorsque les tâches de développement libérables prennent la majeure partie du sprint?
Merci à tous pour votre participation à la discussion. Comme c'est une question assez ouverte, il ne semble pas y avoir de "réponse" - il y a beaucoup de bonnes suggestions ci-dessous. Je vais essayer de résumer certains de mes points "à la maison" et apporter quelques clarifications.
(BTW - Est-ce le meilleur endroit pour mettre cela ou aurais-je dû le mettre dans une "réponse"?)
Points à méditer/agir:
- Vous devez vous assurer que les tâches des développeurs sont aussi petites (granulaires) que possible.
- La durée du sprint doit être basée de manière appropriée sur la durée moyenne des tâches (par exemple, le sprint avec 1 semaine de tâches doit être d'au moins 4 semaines)
- L'équipe (y compris l'AQ) doit travailler pour devenir plus précise lors de l'estimation.
- Envisagez de faire un sprint QA séparé en parallèle mais décalé si cela fonctionne le mieux pour l'équipe
- Test unitaire!
Mon opinion est que vous avez un problème d'estimation. Il semble que le temps pour tester chaque fonctionnalité soit manquant, et seule la partie de construction est prise en compte lors de la planification du sprint.
Je ne dis pas que c'est un problème facile à résoudre, car il est plus courant qu'autre chose. Mais les choses qui pourraient aider sont:
Considérez l'AQ en tant que membres de l'équipe de développement et incluez-les dans la planification et l'estimation du sprint de plus près.
Les "tâches de développement libérables" ne devraient pas prendre la majeure partie du sprint. Les fonctionnalités de travail complètes devraient. Essayez de rassembler des métriques sur le temps de développement par rapport au temps d'AQ pour chaque type de tâche et utilisez ces métriques lors de l'estimation des sprints futurs.
Vous devrez peut-être revoir votre backlog pour voir si vous avez des fonctionnalités à grain très grossier. Essayez de les diviser en tâches plus petites qui pourraient être facilement estimées et testées.
En résumé, il semble que votre équipe n'ait pas trouvé sa vitesse réelle car certaines tâches ne sont pas prises en compte lors de l'estimation et de la planification du sprint.
Mais en fin de compte, l'inexactitude des estimations est un problème de gestion de projet difficile que vous rencontrez dans les projets basés sur des agiles ou des cascades. Bonne chance.
Un peu tard pour la fête ici mais voici mon point de vue basé sur ce que vous avez écrit.
Maintenant, Scrum est une méthodologie de gestion de projet, pas une méthodologie de développement. Mais il est essentiel, à mon avis, d'avoir un processus de développement en place. Sans celui-ci, vous passez la majorité de votre temps réagissant plutôt que de construire.
Je suis un gars test-first. Dans mon processus de développement, je construis d'abord des tests pour appliquer les exigences et les décisions de conception. Comment votre équipe les applique-t-elle? Le point que j'essaie de faire valoir ici est que vous ne pouvez tout simplement pas "jeter des trucs par-dessus la clôture" et vous attendre à autre chose qu'à l'échec. Cet échec sera soit par l'équipe de test (en ne testant pas très bien et donc en laissant passer les problèmes) soit par les développeurs (en ne construisant pas le produit qui résout le problème). Je ne vous dis pas must écrivez des tests en premier - Je ne suis pas un militant ou un évangéliste test-first - mais je dis que vous must avez un processus en place pour produire un code de qualité, testé et prêt à la production lorsque vous atteignez la fin d'une itération.
J'ai été là où vous êtes dans cette méthodologie de développement que j'appelle Death Spiral Method. J'ai construit des logiciels pour le gouvernement (US) pendant des années dans un tel modèle. Cela ne fonctionne pas bien, cela coûte BEAUCOUP d'argent, cela produit du code tardif, un mauvais code et ne fait rien pour le moral. Vous ne pouvez pas faire de progrès lorsque vous passez tout votre temps à corriger des bugs que vous auriez pu éviter en premier lieu. J'ai été absolument abattu par l'affaire.
Vous ne voulez pas que le contrôle qualité trouve vos problèmes. Vous voulez vraiment les mettre au chômage. Mon objectif est de rendre le QA sidéré car tout fonctionne. Certes, c'est un objectif. En pratique, ils trouveront des trucs. Je ne suis pas surhumain. Je fais des erreurs.
Retour à la programmation ...
Dans mon travail actuel, nous faisons Scrum, nous n'appelons pas ça comme ça. Nous ne sommes pas dans les étiquettes ici mais nous produisons du code de qualité à temps. Tout le monde est à bord. Nous disons à QA ce que nous aurons prêt à tester et quand. S'ils viennent frapper deux semaines plus tôt pour cela, ils peuvent parler à la main. Tout le monde connaît le calendrier, tout le monde sait ce qu'il y aura dans la version et tout le monde sait que le produit doit fonctionner comme annoncé avant de passer au contrôle qualité. Alors qu'est-ce que cela signifie? Vous dites à QA "ne vous embêtez pas à tester XYZ - il est cassé et ne sera pas corrigé avant la version C" et s'ils vont tester cela, vous les dirigez vers cette déclaration et leur dites de ne pas perdre votre temps. Dur, peut-être, mais parfois nécessaire. Je ne veux pas être impoli, mais tout le monde a besoin de connaître "les règles" et ce qui doit être testé et ce qu'est un "problème connu".
Votre gestion doit être à bord. S'ils ne le sont pas, vous allez avoir des problèmes. QA ne peut pas non plus diriger le show et le groupe de développeurs ne peut pas le faire complètement. Tous les groupes (même si ces groupes ne sont qu'une seule personne par groupe ou un gars qui porte plusieurs chapeaux) doivent être sur la même page: le client, l'équipe de test, les développeurs, la direction et n'importe qui d'autre. Plus de la moitié de la bataille est généralement la communication.
Peut-être que vous mordez plus que ce qui peut être accompli pendant un sprint. C'est peut-être le cas. Pourquoi fais-tu ça? Pour respecter un calendrier? Si c'est le cas, c'est là que la direction doit intervenir et résoudre le problème. Si vous donnez du code buggy QA, attendez-vous à ce qu'il le rejette. Mieux vaut leur donner 3 choses qui fonctionnent que 8 choses qui sont inachevées. Le but est de produire un ensemble de fonctionnalités qui est complètement implémenté à chaque itération, et non de rassembler un tas de choses à moitié faites.
J'espère que cela sera reçu tel qu'il est censé être - comme un encouragement et non comme une diatribe. Comme je l'ai mentionné, j'ai été là où tu es et ce n'est pas amusant. Mais il y a de l'espoir. Vous pouvez faire bouger les choses en un sprint, peut-être deux. Peut-être que vous n'ajoutez aucune nouvelle fonctionnalité dans le prochain sprint et corrigez simplement ce qui est cassé. Vous devrez décider cela en équipe.
Encore une petite prise pour écrire du code de test: je me suis retrouvé beaucoup plus détendu et beaucoup plus confiant dans mon produit depuis l'adoption d'une approche "écrivez les tests d'abord". Lorsque tous mes tests sont réussis, j'ai un niveau de confiance que je ne pourrais tout simplement pas avoir sans eux.
Bonne chance!
J'espère que vous corrigerez cela en abordant moins de tâches de développement à chaque sprint. Ce qui conduit aux questions: qui est le paramétrage des objectifs du développeur? Pourquoi Dev est-il toujours en deçà de ces objectifs?
Si les développeurs ne fixent pas leurs propres objectifs, c'est pourquoi ils sont toujours en retard. Et ce n'est pas le moyen idéal pour pratiquer Scrum. Il s'agit simplement d'un développement incrémentiel avec des livrables importants et axés sur les délais et aucune responsabilité réelle des parties prenantes de la part des développeurs.
Si les développeurs ne peuvent pas fixer leurs propres objectifs parce qu'ils n'en savent pas assez, alors ils doivent être plus impliqués dès le départ.
Scrum dépend de quatre principes de base, décrits dans le Agile Manifesto .
Les interactions sont importantes - cela signifie que les développeurs, le contrôle qualité, la gestion de projet et les utilisateurs finaux doivent parler plus et parler entre eux. Le logiciel est un processus de codage des connaissances dans le langage obscur des ordinateurs. Pour encoder la connaissance, les développeurs doivent avoir la connaissance. [Pourquoi pensez-vous que nous l'appelons "code"?] Scrum n'est pas une méthodologie "d'écriture de spécification par-dessus le tableau arrière". C'est ANTI- "écrire des spécifications - jeter sur le tableau arrière"
Le logiciel de travail est important - cela signifie que chaque morceau dévié doit conduire à une version fonctionnelle . Pas un ensemble de corrections de bugs avec lesquels QA doit lutter, mais un logiciel qui fonctionne.
Collaboration client - cela signifie que le développeur doit travailler avec les analystes commerciaux, les utilisateurs finaux, les propriétaires d'entreprises, tous ceux qui peuvent les aider à comprendre ce qu'ils construisent. Les délais importent moins que la prochaine chose remise au client. Si le client a besoin de X, c'est la chose la plus prioritaire pour tout le monde. Si le plan du projet dit construire Y, c'est une charge de malarkey.
Répondre au changement - cela signifie que les clients peuvent réorganiser les priorités des sprints suivants. Ils ne peuvent pas réorganiser le sprint en cours (c'est fou) mais tous les sprints suivants sont candidats pour changer les priorités.
Si le client conduit, les délais deviennent alors des "jalons de projet" moins artificiels et plus "nous avons besoin de X d'abord, puis de Y, et cette chose dans la section Z, nous n'en avons plus besoin. Maintenant que nous avons W, Z est redondant."
Les règles Scrum stipulent que tous les éléments Sprint doivent être "entièrement testés, fonctionnalités potentiellement implémentables" à la fin du Sprint pour être considérés comme complets. Les sprints se terminent TOUJOURS à temps, et l'équipe n'obtient pas de crédit et n'est pas autorisée à présenter quoi que ce soit lors de la revue Sprint qui n'est pas terminée - et cela inclut l'AQ.
Techniquement, c'est tout ce dont vous avez besoin. Une équipe s'engage sur une certaine quantité de travail, arrive finalement au contrôle qualité deux jours avant la fin du sprint et le contrôle qualité n'est pas fait à temps. Donc, la sortie du Sprint est nulle, ils doivent aller devant le client et admettre qu'ils n'ont rien à montrer pendant un mois de travail.
La prochaine fois, vous parierez qu'ils choisiront moins de travail et découvriront comment le faire parvenir à l'AQ afin qu'il puisse être terminé à temps.
S'exprimant en tant que QA qui a travaillé sur des projets Agile pendant 2,5 ans, c'est un problème vraiment difficile et je n'ai toujours pas toutes les réponses.
Je travaille dans le cadre d'un "triplet" (deux développeurs qui associent le programme + un QA) et je suis impliqué dans la préparation des histoires et l'estimation dans la planification des réunions au début des itérations de deux semaines. Comme adrianh l'a mentionné ci-dessus, il est essentiel que les QA se fassent entendre dans la planification initiale du sprint. Cela peut être difficile, surtout si vous travaillez avec des développeurs avec des personnalités très fortes, mais les QA doivent être affirmatifs dans le vrai sens du mot (c'est-à-dire non agressifs ou énergiques mais respectueux cherchant à comprendre la vérité/PO et les développeurs/experts techniques tout en se faisant compris). Je préconise de produire des tâches d'AQ d'abord lors de la planification pour encourager une mentalité axée sur les tests - l'AQ devra peut-être littéralement se mettre en avant pour que cela soit adopté. Cela est contraire au nombre de personnes qui pensent que le développement de logiciels fonctionne, mais qui rapporte des dividendes pour plusieurs raisons;
L'AQ est entendue et n'est pas reléguée à la question "alors comment allez-vous tester cela?" après que les développeurs aient dit leur morceau (mentalité de cascade).
Cela permet à l'AQ de proposer des idées de tests qui vérifient en même temps la testabilité des critères d'acceptation lorsque la vérité/PO est présente (j'ai dit qu'il était essentiel qu'ils soient présents à la réunion de planification, n'est-ce pas?!) pour combler les lacunes dans la compréhension.
Il fournit la base d'une approche pilotée par les tests - une fois l'approche test énoncée et chargée, les développeurs peuvent réfléchir à la façon dont ils produiront du code pour réussir ces tests.
Si les étapes 1 à 3 sont votre seule activité TDD pour le reste de l'itération, vous faites toujours un million de fois mieux que le scénario postulé par Steve dans le premier post; "Les développeurs se débattent pour essayer d'accomplir leurs tâches. Généralement, les tâches prennent la plus grande partie du sprint. Les pesteurs de QA Dev publient quelque chose qu'ils peuvent tester, Dev lance finalement du code bogué à QA un jour ou deux avant la fin du sprint et les dépenses le reste du temps à corriger les bogues que QA trouve "
Inutile de dire que cela vient avec quelques mises en garde pour l'AQ;
Ils doivent être prêts à voir leurs idées de tests contestées par les développeurs et la vérité/PO et à parvenir à un compromis; l'attitude "police QA" ne se lavera pas dans une équipe Agile.
Les tâches d'AQ doivent trouver un équilibre difficile pour être ni trop détaillées ni trop génériques (les tâches peuvent être écrites sur une carte pour aller sur un "panneau de radiateur" et discutées lors des réunions quotidiennes de stand up - elles doivent être déplacées de "en cours" à "terminé" PENDANT l'itération).
Les AQ doivent se préparer pour les réunions de planification/estimation. Ne vous attendez pas à pouvoir simplement vous présenter et produire une approche de test du haut de votre tête pour des histoires d'utilisateurs invisibles! Les développeurs semblent pouvoir le faire parce que leurs tâches sont souvent beaucoup plus claires - par exemple "changer le module x pour interfacer avec le composant z" ou "refactoriser la méthode y". En tant qu'AQ, vous devez être familiarisé avec les fonctionnalités introduites/modifiées AVANT la planification afin de connaître la portée des tests et les techniques de conception de test que vous pourriez appliquer.
Il est presque essentiel d'automatiser vos tests et de les écrire et de les "échouer" dans les deux ou trois premiers jours d'une itération ou au moins de coïncider avec quand les développeurs ont le code prêt. Vous pouvez ensuite exécuter les tests et voir s'ils réussissent comme prévu (QA TDD approprié). C'est ainsi que vous évitez une mini cascade à la fin des itérations. Vous devriez vraiment faire une démonstration du test aux développeurs avant ou lorsqu'ils commencent à coder afin qu'ils sachent quoi viser.
Je dis que 4 est "presque essentiel" parce que la même chose peut parfois être réalisée avec succès avec des listes de contrôle manuelles (j'ose dire des scripts!) Du comportement attendu - la clé est de partager cela avec les développeurs à l'avance; continue à leur parler!
En ce qui concerne le point 2 ci-dessus au sujet des tâches, j'ai essayé de créer des tâches aussi granulaires que 1/2 heure à 2 heures de taille chacune correspondant à un travail démontrable, par ex. Msgstr "Ajouter des chèques pour un mot de passe incorrect au test automatique - 2 heures". Bien que cela m'aide à organiser mon travail, les autres membres de l'équipe l'ont critiqué pour être trop détaillé et avoir pour effet de me redresser, soit de déplacer plusieurs tâches pour terminer la veille, soit de ne pouvoir déplacer aucune tâche du tout parce que Je n'y suis pas encore arrivé. Les gens veulent vraiment voir un sentiment de progrès constant lors des redressements quotidiens, il est donc plus utile de créer des tâches en blocs d'une demi-journée ou d'un jour (mais vous pouvez garder votre propre liste de "micro-tâches" à faire jusqu'à la fin). des tâches plus importantes que vous utilisez pour COMMUNIQUER les progrès globaux au stand-up).
En ce qui concerne les points 4 et 5 ci-dessus; les tests automatisés ou les listes de contrôle manuelles que vous préparez tôt devraient vraiment couvrir uniquement les chemins heureux ou les critères d'acceptation clés. Une fois ces tests réussis, vous pouvez avoir planifié une tâche supplémentaire pour une dernière série de "tests exploratoires" vers la fin de l'itération pour vérifier les cas Edge. Ce que les développeurs font pendant cette période est problématique car, en ce qui les concerne, ils sont "code complet" à moins et jusqu'à ce que vous trouviez un bug. Certains praticiens Agiles préconisent d'aller d'abord pour les cas Edge, bien que cela puisse également être problématique car si vous manquez de temps, vous ne pouvez pas être sûr que les critères d'acceptation ont été respectés. C'est l'une de ces décisions finement équilibrées qui dépend du contexte de la user story et de votre expérience en tant que QA!
Comme je l'ai dit au début, je n'ai toujours pas toutes les réponses, mais j'espère que ce qui précède fournit quelques conseils nés d'une expérience difficile!
Nous avons résolu ce problème comme suit: - Chaque article dans le backlog de produit doit avoir des critères d'ajustement ou des critères d'acceptation, sans ceux-ci, nous ne démarrons pas de sprint - Un testeur fait partie de notre équipe, pour chaque article de backlog de produit, il crée un test tâches (1 ou plus, sur la base des critères d'acceptation) avec une estimation et un lien vers l'article à tester - Pendant la mêlée quotidienne, toutes les tâches terminées sont placées dans une colonne "À tester" - Nous ne faisons jamais de tâches qui prennent plus de 16 heures; les tâches qui sont estimées plus longtemps, sont divisées
"Comment la mêlée est-elle censée fonctionner lorsque les tâches de développement libérables prennent la majeure partie du sprint?"
Comme vous l'avez découvert - cela ne fonctionne pas très bien :-) Le processus que vous décrivez ne ressemble pas beaucoup à Scrum pour moi - ou du moins pas comme Scrum bien fait.
Je ne suis pas sûr de ce que vous avez décrit si les gens de l'AQ font partie de l'équipe - ou d'un groupe distinct.
S'il s'agit d'un groupe distinct, c'est probablement une grande partie du problème. Ils ne seront pas impliqués dans l'engagement de l'équipe à l'achèvement des tâches - et la négociation de portée associée avec le propriétaire du produit. Je n'ai jamais vu un groupe agile réussir bien sans être des compétences QA dans l'équipe. Soit en ayant des développeurs avec beaucoup de compétences en test/AQ - soit en ayant une ou trois personnes en AQ intégrées dans l'équipe.
S'ils sont dans l'équipe, alors ils doivent faire entendre leur voix davantage dans la planification initiale du sprint. À présent, il devrait être clair pour le propriétaire du produit et l'équipe que vous êtes trop engagé.
J'essaierais quelques choses si c'était moi:
- Obtenez du QA/testez des gens dans l'équipe s'ils ne sont pas déjà là
- Avoir une bonne longue conversation avec le propriétaire du produit et l'équipe sur ce qui compte comme "terminé". Il semble que certains développeurs soient toujours dans l'état d'esprit pré-scrum de "remis à QA" "== terminé.
- Décomposer les histoires en petits morceaux - facilite la détection des erreurs d'estimation
- Envisagez de courir des sprints plus courts - car il est plus facile et plus facile de suivre et d'apprendre plus souvent.
Vous pouvez également trouver ces astuces pour lisser un burndown scrum utiles.
Il semble que votre équipe de développement ne fasse pas suffisamment de tests par elle-même avant la sortie de QA. Si tous vos tests unitaires réussissent, le cycle d'AQ devrait être relativement fluide, non? Ils trouveront des erreurs d'intégration, mais il ne devrait pas y en avoir beaucoup, non?
Je pense qu'il y a plusieurs problèmes ici. Tout d'abord, je pense que les tâches de développement ne sont peut-être pas assez fines, ou peut-être pas bien estimées, ou peut-être les deux. Le but des sprints dans Scrum est de pouvoir démontrer un code exploitable à la fin des sprints. Les deux problèmes que j'ai mentionnés pourraient conduire à un code bogué.
Si les développeurs publient du code bogué vers la fin du sprint, je regarderais également:
- Les propriétaires de produits tiennent-ils vraiment les membres des développeurs responsables de l'exécution de leurs tâches? C'est le travail du PO et si cela ne se produit pas, alors les développeurs se relâcheront.
- Les développeurs utilisent-ils tout type de TDD? Sinon, cela pourrait grandement aider. Prenez l'habitude des développeurs de tester leur code. Nous avons ce problème là où je travaille, et mon équipe se concentre sur la réalisation du TDD dans les domaines importants afin que nous n'ayons pas besoin que quelqu'un d'autre le fasse plus tard
- Les histoires de tâche/utilisateur sont-elles trop génériques? La marge de manœuvre dans les pannes de tâches rendra les développeurs bâclés. Encore une fois, il s'agit en quelque sorte d'un problème de bon de commande.
Une idée que j'ai entendue dans le passé est d'utiliser une personne QA comme scrummaster. Ils seront présents pour les standups quotidiens et pourront comprendre où en sont les choses avec les développeurs. Ils peuvent résoudre les problèmes avec l'OP (en supposant que l'OP peut faire correctement son travail).
Je ne peux pas m'empêcher de penser que vous avez besoin de plus de coorporation entre QA et vos équipes de mêlée. Il semble que les tests ne se produisent qu'à la fin, ce qui est un problème. Faire en sorte que l'AQ fasse partie de l'équipe aidera à identifier les choses qui peuvent être testées plus tôt et mieux.
J'ai également l'impression que vous avez un problème avec le propriétaire du produit. Ils doivent être là pour s'assurer que tout le monde va dans la bonne direction. ils doivent s'assurer qu'il existe une bonne coopération, non seulement entre l'AQ et les développeurs, mais entre les développeurs eux-mêmes.
Divisez les tâches en tâches plus petites.
De plus, QA peut créer des cas de test pour que Dev puisse tester.
Une idée à considérer est de faire travailler l'AQ une itération derrière le développement principal. Cela fonctionne bien dans notre environnement.
Ici, je dirais que la taille unique ne convient pas à tous. Chaque équipe traite l'AQ différemment. Cela dépend tellement du projet sur lequel vous travaillez, qu'il soit petit ou grand. A-t-il besoin d'une régression approfondie, de l'acceptation par l'utilisateur et de tests exploratoires ou vous avez assez peu de scénarios à tester. Permettez-moi de répéter qu'en Agile, les généralistes sont préférés aux spécialistes. Qu'est-ce que c'est? Parce qu'il y a du temps pendant le projet où vous n'avez rien à tester, donc à ce moment-là vous pourriez faire autre chose. Vous pouvez également effectuer des tests même si vous êtes un programmeur inconditionnel.
Comment le gérons-nous? Nous avons un sprint régulier de 2 semaines. Les tests commencent après une semaine sur la tâche effectuée par les développeurs au cours de la semaine. Maintenant, le testeur continue d'ajouter des problèmes à notre outil de suivi des problèmes et les développeurs qui ont terminé leurs tâches de sprint commencent à sélectionner ces bogues. À la fin du sprint, nous avons principalement terminé notre tâche de sprint et tous les bogues critiques et majeurs.
Alors, qu'est-ce que le testeur deux dans la première semaine du sprint?
Eh bien, il y a toujours des choses à tester. Nous avons des tâches de test dans le backlog, qui peuvent inclure des tests exploratoires. Beaucoup de gens n'apprécient pas les tests exploratoires, mais cela est extrêmement important pour construire des produits de qualité. Les bons testeurs se créent une tâche et trouvent les possibilités où les choses tournent mal et testez-les.
J'espère que cela pourra aider!