US Task force

Le concept de US Task Force dans les équipes Agile

En général, les équipes sont organisées comme suit :

• pendant le déroulement du sprint, un développeur prend une histoire d'utilisateur (US) dans le backlog du sprint et commence à la mettre en œuvre.
• au moment de la réunion quotidienne de Scrum (DSM), chaque développeur partage sa situation et ses préoccupations.

Alors que le DSM est largement et facilement adopté [Stray 2017], lors de la participation au DSM, chacun attend son tour de parole et écoute patiemment la situation des autres sans se sentir concerné car la plupart du temps. les US sont "INVEST", donc "Isolés" des autres US.

Cela se traduit par :

• une mauvaise collaboration
• une connaissance approfondie du domaine et de ce que font les autres.
• Les informations partagées ne sont pas perçues comme pertinentes, notamment en raison de la diversité des rôles, des tâches et de l'ancienneté [Stray 2018].
• un simple rapport individuel [Sutherland 2014].

Même si de nos jours, le bâton de parole est éventuellement remplacé par un ballon ou une mascotte pour rendre l'exercice plus amusant [Ratcliffe 2012] [van Vliet 2016], s'amuser devient ennuyeux... Dans une véritable mêlée de rugby, il y a tellement de confusion qu'un bâton de parole, habituellement impliqué dans les discussions de groupe pour réguler le partage [Priestley 2015], est nécessaire pour laisser à chacun une chance égale de parler [Linders 2016].

Qu'est-il arrivé à cet esprit de rugby ? Les gens essaient désespérément de le dynamiser avec des trucs et astuces [Sutherland 2014] [Yip 2016] [Ratcliffe 2012] [van Vliet 2016] mais rien ne se passe : moins de 45% des participants au MNS le trouvent positif [Stray 2017].

L'une des causes réside certainement dans les racines de Scrum [Sutherland 2011][Sutherland 2014] qui sont décrites dans [Takeuchi 1986] : tout construire en même temps avec une organisation de type C.

‍

Pour rappel, le guide Scrum indique que l'équipe est habilitée à mettre en place son organisation [Schwaber 2020] mais il semble que...

• Les développeurs ont tendance à travailler seuls derrière leur écran et ne vont pas sur le terrain où se trouvent les utilisateurs finaux
• La qualité est principalement axée sur l'adéquation fonctionnelle tandis que les exigences non fonctionnelles (ENF) sont négligées la plupart du temps.
• Ladocumentation n'est pas toujours mise à jour
• Letest de bout en bout est laissé à quelqu'un d'autre une fois que l'incrément de produit entier est disponible.
• L'automatisation des tests est limitée aux tests unitaires (éventuellement en mode TDD ), alors que l'ATDD pourrait être réalisé.

Il existe de nombreux autres anti-modèles que les équipes peuvent adopter involontairement et qui aggraveraient la situation, certains d'entre eux étant systémiques (par exemple, les équipes de composants).

Cette situation entraîne une augmentation des travaux en cours (WIP), car une fois le code livré, il reste encore toutes ces tâches à accomplir. Dans le meilleur des cas, du point de vue de l'utilisateur final, il y aura des défauts et il faudra retravailler. Cela a un impact sur le rendement de la première passe, et génère également des coûts de correction qui sont des dépenses beaucoup plus importantes, car les NFR intègrent souvent des exigences architecturales significatives (ASR) [Chen 2013] [Moustier 2019-1] qui nécessitent généralement un remaniement en profondeur. En outre, cela conduit également à une organisation de type A qui est précisément le modèle Waterfall !

Pour éviter l'erreur du "Done", il faut définir un Definition of Done (DoD) approprié. Cette DoD doit ensuite intégrer des critères qui peuvent être partiellement intégrés aux "quatre quadrants de test" [Marick 2003][Bach 2014][Crispin 2021] afin d'avoir un incrément de produit "potentiellement livrable aux clients" [Schwaber 2020].

Malheureusement, cela génère une charge de travail considérable qui est trop importante pour une seule personne au cours d'un Sprint. C'est là que commence la bonne question : comment faire un livrable US avec ces contraintes ?

Le SRE de Google propose une première option : limiter le développement de nouvelles fonctionnalités à 50 % et laisser les développeurs travailler sur les questions d'exploitation, telles que les éléments énumérés ci-dessus, le reste du temps [Beyer 2016]. Cette option exige beaucoup de compétences de la part de la personne qui construirait le système. les USmais elle ne résout pas le problème du DSM.

Une autre option consiste à rassembler plusieurs personnes sur un seul site US et à laisser l'équipe s'organiser réellement autour de les US. Encore une fois, ce type d'organisation se concentrerait sur le flux (qui profite au WIP !) et non sur un paradigme d'utilisation des ressources à 100% [Kniberg 2014]. Dans ces circonstances, l'équipe construit une Task Force US et le Mob Programming combiné à la documentation vivante, l'ATDD et le TDD pourraient également être une option.

Lorsqu'une équipe entière parvient à travailler sur une mission, les alertes des problèmes soulevés deviennent plus visibles et les Andons interrompent une partie de l'équipe pour permettre une résolution rapide. Ces Andons peuvent être soulevés à tout moment et finalement soulevés au moment du DSM pour partager la préoccupation à un niveau plus élevé. Dans cette configuration, il est facile de comprendre que l'équipe est capable de partager un point de vue rapide sur la mission en cours et pas seulement un rapport individuel sur des questions isolées qui ne sont pas significatives pour un autre Dev.

Si l'actuel site US ne mobilisait pas tous les membres de l'équipe à 100 %, au lieu de rester inactifs, ils pourraient effectuer des tâches de fond. Cela profite à la fois à la durabilité et à la dette technique avec des activités telles que les 5S sur les tests, le code ou la documentation existants. Ces "gars de l'arrière-plan" pourraient éventuellement préparer le prochain Sprint dans les Sprint Refinements.

Impact de la Task Force US sur la maturité des tests

Il ne fait aucun doute que si l'équipe est en mesure d'exécuter plusieurs types de tests sur un site US grâce au groupe de travail, la maturité des tests et la qualité des produits s'en trouvent inévitablement améliorées.

Pour contribuer à ce test à 360 degrés, l'équipe doit organiser un atelier "3 Amigos" avec éventuellement plus de trois personnes pour s'assurer que les éléments suivants ont été "pleinement" saisis les US ont été "pleinement" saisis. les US Le raffinement devrait ensuite être complété par les quadrants de test ; les personnes impliquées proposeront alors des activités qui devraient aborder les quatre parties [Crispin 2021].

En outre, si la mise à jour de la documentation fait partie de l'activité de développement, elle réduit les risques de divergence avec le code et améliore donc la qualité globale du produit.

Si les US embarque trop de choses pour un Sprint, alors une division de US devrait être effectuée [Larman 2010][Lawrence 2012][Le Lan 2018][Moustier 2020]. Le fractionnement doit être cohérent avec les tests à traiter, revoir un document dont la mise à jour est reportée à un autre US n'a aucun sens ! Au final, si le fractionnement conduit à un US inachevé, l'artefact livré sera déployé en mode Dark Launch.

Le point de vue d'Agilitest sur US Task Force

En ce qui concerne l'automatisation des scripts de test, si toute une équipe est impliquée sur un US , alors les scripts peuvent faire partie de les US au sein du Sprint. Les scripts livrés peuvent alors être exécutés à partir de la chaîne d'outils CI sur laquelle Agilitest peut être facilement branché.

Pour faciliter les tests et les rendre de type C selon l'esprit scrum, il est plus utile d'utiliser des pratiques qui permettent de tout construire en même temps. La spécification par l'exemple et l'ATDD en font partie. Agilitest encourage ce type de pratique car elle permet de 

• comprendre ce qui doit être fait 
• ce qui doit être testé
• ce qui est OK
• où les régressions apparaîtraient
• réduire les encours et le coût des retards [Reinertsen 2009].

‍

Pour découvrir l'ensemble des pratiques, cliquez ici.

‍