Bonjour Merci pour cette vidéo comme tous les autres et du temps que vous y consacrez. Vous parlez d'énormément de choses différentes dans cette vidéo et je ne suis pas sûr qu'au final tout soit limpide (en tout cas pour moi= Vous prenez comme exemple "les taches d'analyses" et indiquez que le problème est le même avec "les taches des designers". Vous recommandez ensuite, que l'analyse ne doit pas être faite en amont du sprint, mais pendant le sprint de réalisation. Donc indirectement on comprend que pour l'exemple des designers : les maquettes et la réalisation doivent être faite dans le même sprint. > Mais les maquettes (tout comme l'analyse) sont très souvent la principale DOR et j'ai peur que vous enchainiez les problèmes en cascade avec ce principe : - Les devs ne pourront pas estimer (faute de maquette) ou leurs estimations perdront en fiabilité. - Souvent les maquettes sont sujets avec beaucoup d'aller/retour, de validation, voir de Test U. Compte tenu que cette charge possède beaucoup de variable imprévisible, difficile de la prévoir. Et en plus, du fait que ca soit dans le même sprint, on créait une dépendance avec les devs qui seront immédiatement bloqué en cas de glissement. - Il faudra également rallonger la durée des sprints pour prendre en compte le traitement de bout en bout la demande (là où avant on n’intégrait pas l’analyse). Je veux bien croire que cela peut marcher sur des petites charges, voir sur des équipes très très mature... Mais en faire une recommandation, c'est donc dangereux pour bon nombre d'équipe qui cherche à s'organiser à mon sens. > Egalement vous indiquez de minimiser l'analyse... Là aussi, j'ai très régulièrement vu de gros problèmes faute d'analyse (tout à refaire, car l'analyse est faite en coin d'une table, ou bâclé). Sans partir sur des tartines, elle ne faut pas partir du principe qu'elle doit être la plus faible possible. Pour ma part, bien au contraire, je privilégie de prendre le temps, sans pour autant partir sur une analyse en 3 tomes (ca serait du cycle en V :P). Ce qu'on gagne en analyse c'est du temps qu'on ne perd pas en réalisation. > Sur l'argumentaire, l'analyse et le dev fait 2 sprints plutôt qu'un n'est pas aussi vrai car on est obligé théoriquement de rallonger la longueur des sprints (La charge d'analyse + la charge de dev est la même qu'elle soit faite sur un ou 2 sprint). On gagne un peu car on n’est plus obligé d'attendre la fin du sprint d'analyse pour l'intégrer dans le sprint de réalisation (au contraire on augmente le focus). Mais si cela est un vrai problème, il y a toujours des méthodes tel que le ScrumBan qui permet de pallier à ce problème. En faite, indirectement vous étendez les étapes du Cycle Time, pour incorporer des étapes qu'on retrouve souvent plus en Lead Time (analyse+UX). > Pour rappel, si un sujet est complexe, il y a les "spikes" qui sont intégrés dans le sprint, mais pour des demandes qui en sprint+1 et non en cours. Mais ca peut etre la fameuse exception dont vous parlez. Vous en parliez dans une video de 2019. * Donc à 4:40 j'étais d'accord avec JP Lambert qui disait que vous avez esquivé la question :D (Merci beaucoup pour ce moment) Après je suis persuadé que celà marche et je vous crois sur parole. Mais j'ai un doute sur l'efficacité de faire les mapping d'API, lire la documentation de SDK, ou encore construire un modele de donnée en plein sprint planning qui en fait une séance interminable et qui mobilise tout le monde. C'est à mon sens cannibaliser le travail d'analyste. L'analyste devrait être comme tout le monde, avoir ses taches, un livrable et le présenter/partager son résultat. Tout comme on ne demande pas aux dev de coder durant le sprint planning. > Après je caricature, car de souvenir vous fonctionnez en "no estimate". Ce qui implique effectivement un approfondissement des sujets durant le sprint planning pour un meilleur découpage. Mais à cela 2 choses : - on n’est pas sur le même niveau d'analyse. Je parle d’analyse de haut niveau imputé souvent à un BA par exemple. Alors que dans votre cas, il me semble que c’est plus niveau dev, qui là oui, peut etre faite en sprint planning, voir pendant le sprint. (Je crois d'ailleurs que tout notre désaccord est qu'on ne parle pas du même type d'analyse et c'est ce point qui n'est pas claire). - Le "No estimate" est une méthode a part entière spécifique. Si c'est bien de cela qu'on parle, l'indiquer clairement aurait été bénéfique, car certains risques de partir tête baisser sans en connaitre les principes. (D’ailleurs une vidéo dédiée ne serait pas de refus) Pour la fin de video, pas de débat, on est en phase sur le fait de l’intégration des analystes, le partage de l’expertise etc… En tout cas, c'est mon point de vue (un peu long désolé). Et c'est qui fait toutes la force de l'Agilité (et de votre chaine) c'est que rien n'est dans le marbre. Que on peut en discuter, débattre, échanger, partager son expérience, que tout est bon à prendre… et c’est ce que vous faite merveilleusement bien via cette très bonne video. Merci à vous 😊
Il faut que tu viennes au Live pour en échanger ! Ça commence dans 20 minutes 👌 -- JP
Год назад+1
5:24 Personnellement, je considère que faire l'analyse technique, fait partie de l'exécution du ticket. Donc le faire en sprint planning, c'est encore trop tôt. Ne pas confondre l'analyse technique et la découpe. Si on fait de l'analyse technique en sp, on analyse quoi ? les item du backlog produit qui ne sont pas encore dans le Sprint backlog. On "gaspille" du temps à faire du travail de "réalisation" pour des éléments qui ne sont pas encore engagés. On "waterfall" l'analyse sur la durée du sprint et non de la story. Et du coup on va dire "on défini le design en SP" "on défini les tests en SP ...
Год назад+1
9:10 dans un couloir j'ai affiché "Un expert ne me sert à rien s'il ne sait pas partager sa connaissance ou son savoir-faire"
Год назад
Dans JIRA le ticket Need-Info a des cotés 'utilisation de l'assistance d'une compétence externe" Le ticket reste assigné à un membre de l'équipe. On identifie juste dans ce ticket que ce membre de l'équipe échange avec une partie externe.
Une petite question qui sort un peu du sujet mais pas tant que ça 😁 si dans la société, ils ont l habitude de pointer leur temps de travail. Comment concilier partage du travail analyse développement en respectant les coûts horaires ? Si besoin de plus de précision. Je suis à disposition 😉 Encore une très bonne vidéo
Le coût horaire n'est-il pas plus lié aux personnes impliquées (c'est à dire : qui pointent) qu'au type d'activité ? Ce que je veux dire, c'est qu'il "suffit" que chacun pointe avec exhaustivité et on a alors l'information. Après, le modèle privilégié pour les équipes agiles, qui visent à réduire la bureaucratie, est de simplement prendre un peu de hauteur et considérer qu'à un sprint donné toute l'équipe travaillait sur un objectif donné de l'entreprise. Il est alors trivial de calculer les différents coûts et de faire un suivi, pour une bureaucratie minimale. D'ailleurs, on parlait un peu de ce sujet dans une précédente vidéo : ruclips.net/video/XeMKXS8mIQs/видео.html Qu'en penses-tu ? Est-ce que ces éléments répondent à tes questions ? -- JP
Год назад+1
En Scrum c'est facile de pointer le temps de travail. Je travaille à temps plein, le temps d'un sprint, à participer à l'ensemble de l'activité du sprint. Ce qui se passe dans le sprint appartient à l'équipe auto-organisée. Le coût-horaire est celui d'un membre de l'équipe. Après l'équipe a peut-être son budget et sa manière de gérer son budget et de faire des différences (néfastes) entre les membres de l'équipe. Dans l'équipe pluridisciplinaire, les gens sont payés pour être dans l'équipe, pas pour une casquette particulière Si un membre de l'équipe doit être mieux payé, c'est parce qu'il apporte plus aux autres membres de l'équipe. Et pas parce qu'il fait plus ou parce qu'il fait plus un type de tâches. Et si ça ne lui plait pas, c'est qu'il n'est pas fait pour une équipe agile.
Merci pour vos réponses. C'est pour moi un sujet qui demanderai un plus long échange car j'ai du résumé fortement ici 😁. Ça me conforte dans mes pensées que vouloir faire de l agile uniquement lors de la phase de développement (comprendre maquette faite, analyse technique faite et écritures des specs par les LeadDev faite) ça n a aucun sens.
Год назад+1
@@MrAzaliah n'hésite pas à venir sur le forum, on peut développer avec tous les autres
J'ai du mal avec la définition donnée du "Dernier moment raisonnable". Techniquement, le dernier moment raisonnable est le moment avant lequel la capacité de faire un choix est retiré à l'équipe par manque de temps/ressources. C'est pour cela qu'il est préférable de tirer à soit les questions techniques les plus épineuses dans un cycle de discovery. Le but est bien de comprendre le système en amont pour ne pas payer les pots cassés plus tard.
Год назад
Le dernier moment raisonnable, c'est le moment ) partir duquel on élimine le mieux les chances de gaspillage. Note : Une équipe qui manque de temps ou de ressources, ça n'existe pas en Scrum. Les ressources et le temps sont "fixes", la qualité aussi. Ce qui varie, c'est la quantité. Et cette quantité, on l'estime vis-à-vis de ces valeurs fixées. On n'est jamais en retard, on a juste mal estimé. On n'est jamais en manque de ressource (temps, humaines, €€), on en veut juste trop pour ces valeurs qui ont été fixées. C'est le grand drame des roadmap avec des dates, des échéances (qui sont bonnes) mais sur lesquelles les parties prenantes, viennent souvent coller des perspectives et les annoncer comme des réalités
@ Oui mais non... Une équipe existe pas ex-nihilo. Quid des réglementations (ex: RGPD) ? Quid du/des concurrents qui sortent un produit rendant la solution actuelle obsolète ? Quid du manque de fonds existant de l'entreprise ?
Год назад
@@NiokSam Désolé, mais je ne comprends pas la réponse en rapport à la mienne. la première partie de ma réponse est à propos du dernier moment raisonnable, auquel je veux présenter la caractéristique d'être le moment le plus proche du démarrage du sprint afin d'avoir connaissance des derniers apprentissages, et une vue la plus claire de ce qu'on va viser comme objectif dans le sprint qu'on veut démarrer et de la capacité de réalisation qu'on a. Par opposition, le "pas dernier moment" se reconnait par le fait qu'on peut remettre en question ce qu'on décide soit parce qu'on récolte de nouvelles informations, soit parce qu'on ne va par inclure l'item de backlog ciblé dans le prochain sprint.
Год назад
Ca me rappelle que le "Assignee" de JIRA m'a toujours ennuyé en scrum. Un Item du backlog est pris en charge PAR L'ÉQUIPE, équipe qui probablement la "délègue" à un sous-ensemble de l'équipe. Mais pas forcément UN (seul ) membre de l'équipe. Donc que signifie d'assigner un ITem de backlog à UNE personne ? Personnellement je préfère une allusion à un rôle de steward, logisticien, gardien, ... de l'élément. Un rôle que n'importe qui dans l'équipe peut prendre sur n'importe quel ticket et qui identifie qui s'occupe de l'encodage, des déplacements dans le board , de relire la DOD, ... bref celui qui soutient la vie logistique du ticket.
On peut aussi dire qu'il y a une personne qui se positionne comme étant celle qui vérifie que la tâche avance bien. Celle qui en fait son focus. Ce n'est pas forcément elle qui la "gère", qui la réalise ou autre, juste, son focus est dessus. T'en dis quoi ? -- Constantin
Год назад
@@ScrumLife ben je cherche surtout la nuance sur le verbe gérer. Pour détacher l'aspect "JIRA" de l'aspect "travail pour faire évoluer le statut"
La pluridisciplinarité de l'équipe Scrum ☄ ruclips.net/video/rUSxzIw8_D0/видео.html
Bonjour
Merci pour cette vidéo comme tous les autres et du temps que vous y consacrez.
Vous parlez d'énormément de choses différentes dans cette vidéo et je ne suis pas sûr qu'au final tout soit limpide (en tout cas pour moi=
Vous prenez comme exemple "les taches d'analyses" et indiquez que le problème est le même avec "les taches des designers". Vous recommandez ensuite, que l'analyse ne doit pas être faite en amont du sprint, mais pendant le sprint de réalisation. Donc indirectement on comprend que pour l'exemple des designers : les maquettes et la réalisation doivent être faite dans le même sprint.
> Mais les maquettes (tout comme l'analyse) sont très souvent la principale DOR et j'ai peur que vous enchainiez les problèmes en cascade avec ce principe :
- Les devs ne pourront pas estimer (faute de maquette) ou leurs estimations perdront en fiabilité.
- Souvent les maquettes sont sujets avec beaucoup d'aller/retour, de validation, voir de Test U. Compte tenu que cette charge possède beaucoup de variable imprévisible, difficile de la prévoir. Et en plus, du fait que ca soit dans le même sprint, on créait une dépendance avec les devs qui seront immédiatement bloqué en cas de glissement.
- Il faudra également rallonger la durée des sprints pour prendre en compte le traitement de bout en bout la demande (là où avant on n’intégrait pas l’analyse).
Je veux bien croire que cela peut marcher sur des petites charges, voir sur des équipes très très mature... Mais en faire une recommandation, c'est donc dangereux pour bon nombre d'équipe qui cherche à s'organiser à mon sens.
> Egalement vous indiquez de minimiser l'analyse... Là aussi, j'ai très régulièrement vu de gros problèmes faute d'analyse (tout à refaire, car l'analyse est faite en coin d'une table, ou bâclé). Sans partir sur des tartines, elle ne faut pas partir du principe qu'elle doit être la plus faible possible.
Pour ma part, bien au contraire, je privilégie de prendre le temps, sans pour autant partir sur une analyse en 3 tomes (ca serait du cycle en V :P). Ce qu'on gagne en analyse c'est du temps qu'on ne perd pas en réalisation.
> Sur l'argumentaire, l'analyse et le dev fait 2 sprints plutôt qu'un n'est pas aussi vrai car on est obligé théoriquement de rallonger la longueur des sprints (La charge d'analyse + la charge de dev est la même qu'elle soit faite sur un ou 2 sprint). On gagne un peu car on n’est plus obligé d'attendre la fin du sprint d'analyse pour l'intégrer dans le sprint de réalisation (au contraire on augmente le focus). Mais si cela est un vrai problème, il y a toujours des méthodes tel que le ScrumBan qui permet de pallier à ce problème. En faite, indirectement vous étendez les étapes du Cycle Time, pour incorporer des étapes qu'on retrouve souvent plus en Lead Time (analyse+UX).
> Pour rappel, si un sujet est complexe, il y a les "spikes" qui sont intégrés dans le sprint, mais pour des demandes qui en sprint+1 et non en cours. Mais ca peut etre la fameuse exception dont vous parlez. Vous en parliez dans une video de 2019.
* Donc à 4:40 j'étais d'accord avec JP Lambert qui disait que vous avez esquivé la question :D
(Merci beaucoup pour ce moment)
Après je suis persuadé que celà marche et je vous crois sur parole.
Mais j'ai un doute sur l'efficacité de faire les mapping d'API, lire la documentation de SDK, ou encore construire un modele de donnée en plein sprint planning qui en fait une séance interminable et qui mobilise tout le monde. C'est à mon sens cannibaliser le travail d'analyste. L'analyste devrait être comme tout le monde, avoir ses taches, un livrable et le présenter/partager son résultat. Tout comme on ne demande pas aux dev de coder durant le sprint planning.
> Après je caricature, car de souvenir vous fonctionnez en "no estimate". Ce qui implique effectivement un approfondissement des sujets durant le sprint planning pour un meilleur découpage.
Mais à cela 2 choses :
- on n’est pas sur le même niveau d'analyse. Je parle d’analyse de haut niveau imputé souvent à un BA par exemple. Alors que dans votre cas, il me semble que c’est plus niveau dev, qui là oui, peut etre faite en sprint planning, voir pendant le sprint.
(Je crois d'ailleurs que tout notre désaccord est qu'on ne parle pas du même type d'analyse et c'est ce point qui n'est pas claire).
- Le "No estimate" est une méthode a part entière spécifique. Si c'est bien de cela qu'on parle, l'indiquer clairement aurait été bénéfique, car certains risques de partir tête baisser sans en connaitre les principes. (D’ailleurs une vidéo dédiée ne serait pas de refus)
Pour la fin de video, pas de débat, on est en phase sur le fait de l’intégration des analystes, le partage de l’expertise etc…
En tout cas, c'est mon point de vue (un peu long désolé). Et c'est qui fait toutes la force de l'Agilité (et de votre chaine) c'est que rien n'est dans le marbre. Que on peut en discuter, débattre, échanger, partager son expérience, que tout est bon à prendre… et c’est ce que vous faite merveilleusement bien via cette très bonne video. Merci à vous 😊
Il faut que tu viennes au Live pour en échanger ! Ça commence dans 20 minutes 👌
-- JP
5:24 Personnellement, je considère que faire l'analyse technique, fait partie de l'exécution du ticket. Donc le faire en sprint planning, c'est encore trop tôt. Ne pas confondre l'analyse technique et la découpe.
Si on fait de l'analyse technique en sp, on analyse quoi ? les item du backlog produit qui ne sont pas encore dans le Sprint backlog. On "gaspille" du temps à faire du travail de "réalisation" pour des éléments qui ne sont pas encore engagés. On "waterfall" l'analyse sur la durée du sprint et non de la story.
Et du coup on va dire "on défini le design en SP" "on défini les tests en SP ...
9:10 dans un couloir j'ai affiché "Un expert ne me sert à rien s'il ne sait pas partager sa connaissance ou son savoir-faire"
Dans JIRA le ticket Need-Info a des cotés 'utilisation de l'assistance d'une compétence externe"
Le ticket reste assigné à un membre de l'équipe.
On identifie juste dans ce ticket que ce membre de l'équipe échange avec une partie externe.
Une petite question qui sort un peu du sujet mais pas tant que ça 😁 si dans la société, ils ont l habitude de pointer leur temps de travail. Comment concilier partage du travail analyse développement en respectant les coûts horaires ? Si besoin de plus de précision. Je suis à disposition 😉
Encore une très bonne vidéo
Le coût horaire n'est-il pas plus lié aux personnes impliquées (c'est à dire : qui pointent) qu'au type d'activité ?
Ce que je veux dire, c'est qu'il "suffit" que chacun pointe avec exhaustivité et on a alors l'information.
Après, le modèle privilégié pour les équipes agiles, qui visent à réduire la bureaucratie, est de simplement prendre un peu de hauteur et considérer qu'à un sprint donné toute l'équipe travaillait sur un objectif donné de l'entreprise. Il est alors trivial de calculer les différents coûts et de faire un suivi, pour une bureaucratie minimale.
D'ailleurs, on parlait un peu de ce sujet dans une précédente vidéo : ruclips.net/video/XeMKXS8mIQs/видео.html
Qu'en penses-tu ? Est-ce que ces éléments répondent à tes questions ?
-- JP
En Scrum c'est facile de pointer le temps de travail.
Je travaille à temps plein, le temps d'un sprint, à participer à l'ensemble de l'activité du sprint. Ce qui se passe dans le sprint appartient à l'équipe auto-organisée. Le coût-horaire est celui d'un membre de l'équipe.
Après l'équipe a peut-être son budget et sa manière de gérer son budget et de faire des différences (néfastes) entre les membres de l'équipe.
Dans l'équipe pluridisciplinaire, les gens sont payés pour être dans l'équipe, pas pour une casquette particulière
Si un membre de l'équipe doit être mieux payé, c'est parce qu'il apporte plus aux autres membres de l'équipe. Et pas parce qu'il fait plus ou parce qu'il fait plus un type de tâches.
Et si ça ne lui plait pas, c'est qu'il n'est pas fait pour une équipe agile.
Merci pour vos réponses. C'est pour moi un sujet qui demanderai un plus long échange car j'ai du résumé fortement ici 😁. Ça me conforte dans mes pensées que vouloir faire de l agile uniquement lors de la phase de développement (comprendre maquette faite, analyse technique faite et écritures des specs par les LeadDev faite) ça n a aucun sens.
@@MrAzaliah n'hésite pas à venir sur le forum, on peut développer avec tous les autres
@@MrAzaliah il faut que tu viennes au live jeudi, tu viendras nous en parler en direct et de vive voix ! ! !
-- JP
J'ai du mal avec la définition donnée du "Dernier moment raisonnable". Techniquement, le dernier moment raisonnable est le moment avant lequel la capacité de faire un choix est retiré à l'équipe par manque de temps/ressources. C'est pour cela qu'il est préférable de tirer à soit les questions techniques les plus épineuses dans un cycle de discovery. Le but est bien de comprendre le système en amont pour ne pas payer les pots cassés plus tard.
Le dernier moment raisonnable, c'est le moment ) partir duquel on élimine le mieux les chances de gaspillage.
Note : Une équipe qui manque de temps ou de ressources, ça n'existe pas en Scrum. Les ressources et le temps sont "fixes", la qualité aussi. Ce qui varie, c'est la quantité.
Et cette quantité, on l'estime vis-à-vis de ces valeurs fixées.
On n'est jamais en retard, on a juste mal estimé.
On n'est jamais en manque de ressource (temps, humaines, €€), on en veut juste trop pour ces valeurs qui ont été fixées.
C'est le grand drame des roadmap avec des dates, des échéances (qui sont bonnes) mais sur lesquelles les parties prenantes, viennent souvent coller des perspectives et les annoncer comme des réalités
@ Oui mais non... Une équipe existe pas ex-nihilo. Quid des réglementations (ex: RGPD) ? Quid du/des concurrents qui sortent un produit rendant la solution actuelle obsolète ? Quid du manque de fonds existant de l'entreprise ?
@@NiokSam Désolé, mais je ne comprends pas la réponse en rapport à la mienne.
la première partie de ma réponse est à propos du dernier moment raisonnable, auquel je veux présenter la caractéristique d'être le moment le plus proche du démarrage du sprint afin d'avoir connaissance des derniers apprentissages, et une vue la plus claire de ce qu'on va viser comme objectif dans le sprint qu'on veut démarrer et de la capacité de réalisation qu'on a.
Par opposition, le "pas dernier moment" se reconnait par le fait qu'on peut remettre en question ce qu'on décide soit parce qu'on récolte de nouvelles informations, soit parce qu'on ne va par inclure l'item de backlog ciblé dans le prochain sprint.
Ca me rappelle que le "Assignee" de JIRA m'a toujours ennuyé en scrum.
Un Item du backlog est pris en charge PAR L'ÉQUIPE, équipe qui probablement la "délègue" à un sous-ensemble de l'équipe. Mais pas forcément UN (seul ) membre de l'équipe.
Donc que signifie d'assigner un ITem de backlog à UNE personne ?
Personnellement je préfère une allusion à un rôle de steward, logisticien, gardien, ... de l'élément. Un rôle que n'importe qui dans l'équipe peut prendre sur n'importe quel ticket et qui identifie qui s'occupe de l'encodage, des déplacements dans le board , de relire la DOD, ... bref celui qui soutient la vie logistique du ticket.
On peut aussi dire qu'il y a une personne qui se positionne comme étant celle qui vérifie que la tâche avance bien. Celle qui en fait son focus. Ce n'est pas forcément elle qui la "gère", qui la réalise ou autre, juste, son focus est dessus.
T'en dis quoi ?
-- Constantin
@@ScrumLife ben je cherche surtout la nuance sur le verbe gérer. Pour détacher l'aspect "JIRA" de l'aspect "travail pour faire évoluer le statut"