Backlog Produit - La raison pour laquelle vous dévez découper

[@ScrumLife]

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

[@MrAsteba]

Bonne vidéo. Il est important de découper les tâches pour éviter qu'un dev travaille 6 mois sur une branche dans son coin, mais il est également important de trouver un bon compromis dans la granularité. En faisant des tâches trop petites, on augmente l'overhead (par exemple les projets sur lesquels je travaille ont des composantes hardware et des tests manuels pour quasiment chaque ticket. Un test manuel requiert plus ou moins le même effort indépendamment de la tâche testée puisqu'il faut mettre en place le hardware de test etc.) et empêche les devs de créer une architecture cohérente. J'ai déjà vu l'autre extrême où un développeur a créé 5 tickets pour deux heures de travail au total.

[@ScrumLife]

Il faut automatiser tous ces tests manuels !!! As-tu vu l'interview de Joe Justice où il nous parle d'agilité dans le hardware et en particulier chez Tesla ? Voici le lien : kzbin.info/www/bejne/rofPqHdorcSUfKM -- JP

[@MrAsteba]

@@ScrumLife oui idéalement automatiser ces tests manuels, mais cela reste impossible économiquement de tout automatiser dans pas mal de projets qui utilisent du hardware (je suis développeur embarqué et concrètement beaucoup de tests manuels étaient nécessaires dans toutes les entreprises où j'ai travaillées, d'où souvent l'impossibilité d'implémenter Scrum sans adaptation). Merci pour le lien je regarderai.

[@ScrumLife]

Personnellement j'ai travaillé quelques années dans l'embarqué et j'ai la conviction que l'automatisation des tests manuelles est totalement possible, certes il faut être prêt à considérer cela comme un vrai sujet et à investir dedans. D'un côté en suivant les bonnes pratiques du développement logiciel on peut : - Valider l'essentiel du logiciel dans une sandbox sans hardware - Valider beaucoup de choses sur le hardware lui-même, sans front-end et en pilotant la solution par des appels réseaux Et de l'autre côté, on va tester la solution complète externe en manipulant le hardware ! Souvent il y a des solutions professionnelles qui existent pour se faciliter la vie, et pour le reste il faut construire les outils soi-même. Et aujourd'hui, à l'heure du Raspberry Pi et de l'Arduino c'est encore plus facile : créer un système programmable qui manipule d'autres systèmes, ce n'est pas si difficile, si on prend le temps de s'y essayer. D'une manière générale, on revient sur un classique du développement logiciel : si on a prévu de le tester automatiquement, alors on va le construire de manière à pouvoir le tester automatiquement. Si on ne l'a pas prévu, alors tester automatiquement sera une véritable galère et effectivement le coût semblera démesuré par rapport à faire du test manuel... Sauf que, bien sûr, le test manuel est joué à répétition, et coûte cher à chaque fois tout en empêchant d'itérer plus vite. Les gains de l'automatisation sont bien entendu dans la durée -- et oui parfois on est sur un projet de 3 mois donc bon... Au plaisir d'en échanger plus ! -- JP

[@MrAsteba]

@@ScrumLife Comme dit sur le principe je suis d'accord que c'est idéal d'automatiser autant que possible et j'essaye de le faire autant que possible. D'autre part je connais bien ce que tu décris puisque nous l'utilisons pour automatiser une partie des tests en embarqué (sandbox software + tests automatiques pilotés par réseau sur le hardware), mais pour avoir travaillé sur des produits hardware complexes (bluetooth avec applications android/iOS tierce-parties, wifi, commande vocale avec microphone, haut-parleur pour sortie audio, caméras, etc) mais avec des clients/industries sensibles aux coûts, l'automatisation revient très cher comparé à des tests manuels et le ROI de l'automatisation complète est dur à justifier économiquement malheureusement. Pour cette raison, dans plusieurs entreprises où j'ai travaillé (petites et grandes) sur des projets embarqués, seule une partie des tests était automatisée et scrum est vraiment dur à suivre à la lettre dans ces cas. Je trouve que le ROI des tests automatiques est beaucoup plus élevé sur des produits purement software, qui sont souvent plus simples à tester automatiquement.

[@veroniquepicard1136]

Bonjour, je lance une bouteille ..... voici Bonjour à vous deux, Je suis en cours de formation (formation solo via internet) pour passer ma certification SCRUM. Voilà ma question, pouvez vous m'aider svp ? Merci. Dans un projet Agile, quid de la validation de la création graphique des écrans ? 1 -Dois je attendre la fin du sprint pour faire valider cette partie projet soit avec donc une brique technique quasi publiable ? 2 - Ou dois je revenir à un mode plus en V avec une validation client intermédiaire avant qu'on parte en développement ? Si je m'en réfère au guide, je dirais la solution 1 car à ce stade j'ai créé plus de valeur. Mais dans la vraie vie je sais que la créa peut être source de nombreux changements dû à des ressentis par toujours chalengeables car raisonnables. Il est donc plus aisé et surtout moins coûteux coûteux de modifier cette partie avant développement. Mais du coup je reviens en mode V. De plus, si j'ai des tests utilisateurs en cours de conception, je suis bien obligé d'avoir une phase intermédiaire avant développement. Je suis obligée de revenir à une méthode plus en V ? Qu'en pensez vous les experts Agile ? :-) Merci d'avance de votre retour Et Merci à Scrum Life pour toutes ces vidéos. Bravo.

[@sydeatn]

Salut Jean-Pierre, Pourrais-tu également ajouter le lien vers le tuto ou mod op de l'atelier Carpaccio d'éléphant ? Cela m'intéresse :) Dan.

[@ScrumLife]

Il n'est pas encore sorti ! On essaiera de l'ajouter le moment venu.

[@protecta22]

Le voici kzbin.info/www/bejne/iojddqKwoZKAmtE !

[@vellanefedovakateryna3423]

Bonjour, j'ai une petite question : est-ce qu'il est gênant d'avoir une user story qui est découpée en plusieurs tâches ? Exemple : Page d'authentification qui comprend plusieurs fonctionnalités : 1. Saisir son login 2. Saisir son mot de passe 3. Rubrique "Besoin d'aide" dans laquelle on retrouve deux autres fonctionnalités 3.1 Mot de passe perdu 3.2 Quel est mon login 4. S'enregistrer Faut-il avoir chaque user story par fonctionnalité ou peut-on créer une user story qu'on découpe avec toutes ces tâches ?

[@ScrumLife]

Bonjour Vella, je vais répondre par une question : Quel est le besoin de l'utilisateur ? -- Constantin

[@MathiouJacquesantoine73]

Piège à éviter : découper, Re découper, livrer et oublier l'objectif métier . " Si si on a livrer toutes les US" " Oui mais le gains attendu par le service clients n est pas au RDV... "

[@ScrumLife]

Oh ! C'est directement une des choses qu'on explique dans la formation qu'on a tourné aujourd'hui ! ! !