Une seule équipe avec les développeurs front-end & back-end - Scrum Life 70

[@ScrumLife]

Découvrez toute la communauté Scrum Life ! 👉 sl.run/zFTNN6

[@NicolasRemyDahu]

Ce teasing sur l'itération d'une journée :D

[@jean-philippeschmitt8186]

Hâte de vous entendre sur le sprint d'un jour ! Quels sont les objectifs de ces sprints ? Quelles tâches de dev sont adaptées à cette méthode? Comment amener le sujet et faire en sorte que l'équipe adhère à l'idée ? Sur quelle durée ? Quels sont les facteurs de succès de cette méthode ?

[@ScrumLife]

Voici déjà pas mal d'éléments de réponse dans cet article : jp-lambert.me/testez-le-sprint-de-1-jour-retour-dexp%C3%A9rience-c612cf5ba4fd

[@arfixo666]

Merci pour l episode ! Si la story qui prend du front et du back est trop grosse, le split front/back/par composant de la story est souvent la solution proposée par l equipe. De mon point de vue (PO), je perds de la valeur produit car elle est diluée entre plusieurs stories. Pour les arguments en face, on part du principe qu'une API/une librairie/une fonction dans le framework apporte toute seule de la valeur, mais on rentre dans la définition de valeur. Du point de vue PO, la valeur est celle offerte a l utilisateur final, celui qui n'est pas dans l equipe et dont on essaie de répondre au besoin. Mais mes équipes encouragent et proposent de plus en plus de segmenter le travail pour que : - l'api soit faite avec 1 sprint d avance - le composant visuel soit fait des que les maquettes UX sont validées - donc pourquoi pas avoir les front web d un côté, les dev android d'un autre, les dev ios d un autre, et finalement les devs BE dans leur coin ? - et si on mock, cest bon on livre la valeur aussi - et j'en passe.. Ca ressemble méchamment à un cycle waterfall tout ça. La valeur n arrive qu'après x étapes qui ne sont pas realisees dans 1 sprint. Et ce sont autant d arguments contre les features teams. Que conseilleriez-vous ? Merci !

[@ScrumLife]

Idéalement, il faudrait factualiser ce que l'on recherche via l'organisation de l'équipe. Par exemple si c'est livrer plus vite, on peut mesurer le temps de cycle. Si c'est pour livrer plus de valeur, on peut mesurer une sorte de vélocité sur des points de valeur business. Si c'est diminuer le nombre de "rework", de fois où on doit reprendre du travail qu'on pensait terminé, on peut aussi le mesurer. Puis, dès lors que vous avez une mesuré votre "performance" actuelle qui va servir de référence, alors on peut commencer à expérimenter ! Et pourquoi pas les laisser mettre en place ce qu'ils proposent. A priori de séquencer le travail de l'équipe donne l'illusion de maximiser la productivité de chacun... La réalité est que cela va certainement augmenter le temps de cycle et le nombre de rework. Mais laissons les chiffres parler ! Laissons à l'équipe le droit d'avoir des convictions et de se planter ! Et puis, qui sait... Si ça se trouve ils ont raison ??? Dès lors qu'objectivement ça nous emmène là où on veut aller... Où est le problème ?

[@alainkhuon]

Au niveau du partage de connaissance entre front et back, la video est pas mal. Par contre je reste sur ma faim concernant le partage entre front et back. Dans le cas où un back end est en avance sur le front pour un user story mais qu'il n'y a rien à tester ou à code review, que peut faire le back end à part commencer un nouveau user story? :)

[@aymericrichard6931]

Les tests auto, c'est quand on lance une voiture sur un mur avec un mannequin dedans ? :)

[@elsazapata4947]

Hello Jean-Pierre, Merci pour cette vidéo et les quelques tips ! Dans mon équipe nous avons déjà expérimenté le pair-programming pour faire monter en compétence un développeur back sur le front mais l'inconvénient c'est que sur le coup ça prend beaucoup de temps et retarde des tâches. Mais il y a un gain de temps bien plus loin dans le projet. On a expérimenté cela quand on était face au mur, en retard sur le projet. Mais on a choisi des tâches adaptés au niveau en front du développeur, ceci compte beaucoup, en effet s'il peut réutiliser du code déjà fait ça lui permettra de prendre en main plus rapidement le front et lui donner confiance. En revanche là où je suis moyennement d'accord c'est qu'il y a une question de compétences : un développeur back pourrait faire du front, mais avec quelle qualité ? On répond peut-être au besoin fonctionnel dans les temps mais derrière ça peut causer du refactoring à faire.

[@ScrumLife]

Le but n'est pas d'avoir des experts en tout. Le but est d'avoir des "backups", des personnes certes moins efficaces que l'expert, mais qui pourront donner des coups de main, que cela soit à cause d'une absence (parfois prévue, parfois imprévue) ou bien pour terminer le sprint. On gagne en flexibilité, mais on ne veut pas perdre l'efficacité de l'équipe. Il faut trouver le juste milieu... Faire que tout le monde puisse toucher à un maximum de choses, mais sans devenir expert en tout. Et puis, bien sûr, il est aussi et surtout question d'améliorer le niveau de collaboration au sein de l'équipe. Donc être capable de se plonger dans le travail d'un autre, sans être capable de le remplacer.

[@olivierledru2765]

Dans le même genre, la séparation classique analystes / codeurs / testeurs. Peut-on vraiment parler d'équipe quand on a des personnes qui se coordonnent mais qui ne collaborent pas ?

[@ScrumLife]

En effet, en publiant l'épisode ce matin je me suis rendu compte que nous aurions pu aborder le sujet sous un angle radicalement différent : celui de la communication, de la bonne ambiance, du team building, etc.

[@aymericrichard6931]

Quelle est la répartition de l'audience de la chaîne ? Dev, scrum, po, pm, managers, autres curieux ?

[@garfunk71]

Et la QA alors ?

[@aymericrichard6931]

@@garfunk71 ah! Chez moi la qa c'est le po :)

[@NicolasRemyDahu]

Je dirais que c'est à Scrum Life de faire le sondage, ça pourrait instruire tout le monde, et ce serait plus efficace qu'une petite question dans un commentaire ;)

[@lutaseb]

quoi de mieux qu'1 Jean Pierre Lambert? DEUX JEAN PIERRE LAMBERT ma ptite dame!

[@v.bourdeix]

Etant freelance en SASU, je suis à la fois, PO, développeur front, développeur back, administrateur système, chef de projet et commercial pour mon client, mais j'utilise quand même Scrum par habitude et pour délivrer de la valeur le plus rapidement / fréquemment possible. Est ce que ça semble bizarre ou est ce que mon cas est fréquent selon vous ?

[@PascalMenardais]

c'est bizarre dans cette chanson kzbin.info/www/bejne/lWi9gqyqhNagec0 j'entend : i'm always on the back-front ...