Scrum vs. Shape Up : les différences - Historique des versions

Fabrice Aimetti : /* Sprints vs Cycles */

Fabrice Aimetti — Wed, 20 Dec 2023 06:15:35 GMT

Sprints vs Cycles

← Version précédente		Version du 20 décembre 2023 à 06:15
Ligne 21 :		Ligne 21 :
	<small>''Illustration créée par l'auteur avec Excalidraw''</small><br/>		<small>''Illustration créée par l'auteur avec Excalidraw''</small><br/>
	<br/>		<br/>
	Scrum fonctionne généralement par sprints de deux semaines, sans interruption entre la fin d'un sprint et le début du suivant, selon un [https://es.wikipedia.org/wiki/~~Desarrollo_iterativo_y_creciente~~ modèle de développement itératif et incrémental].<br/>		Scrum fonctionne généralement par sprints de deux semaines, sans interruption entre la fin d'un sprint et le début du suivant, selon un [https://en.wikipedia.org/wiki/Iterative_and_incremental_development modèle de développement itératif et incrémental (en)].<br/>
	<br/>		<br/>
	En revanche, les cycles de développement standard de Shape Up sont d'environ 6 semaines, plus une période de relâchement ([https://www.linkedin.com/pulse/introducci%C3%B3n-al-m%C3%A9todo-shape-up-per%C3%ADodo-de-cool-down-marc-rovira-vall/?lipi=urn%3Ali%3Apage%3Ad_flagship3_pulse_read%3BPhrDMiQbRnCMx0stD0Osng%3D%3D ''Cool-down'']) de 2 semaines, suivant également un modèle "itératif et incrémental", mais non consécutif dans le temps. Dans Shape Up, nous partons d'un document Pitch, qui est le résultat de [https://www.linkedin.com/pulse/introducci%C3%B3n-al-m%C3%A9todo-shape-up-fase-de-shaping-marc-rovira-vall/?lipi=urn%3Ali%3Apage%3Ad_flagship3_pulse_read%3BPhrDMiQbRnCMx0stD0Osng%3D%3D l'étape Shaping], et à partir de là, l'équipe (de développement) commence à ordonner le travail qu'elle découvre qu'elle doit faire, en identifiant les différents éléments du logiciel qui le composent, en commençant par [https://basecamp.com/gettingreal/09.2-epicenter-design l'épicentre], découvrant ainsi les problèmes à résoudre en suivant un ordre logique d'exécution. Dans Shape Up, pratiquement toute nouvelle fonctionnalité est mise en œuvre en un seul cycle de 6 semaines au maximum, mais il peut arriver que quelque chose d'important ait été oublié dans le cycle par manque de temps (le but que nous nous sommes fixé). Dans ce cas, nous pouvons toujours procéder à une nouvelle mise en forme (''shaping'') des améliorations qui ont été laissées de côté (qu'il s'agisse d'aspects de conception UX/UI, de cas d'utilisation non envisagés, de nouveaux paramètres de configuration, etc. De cette façon, nous appliquerions un développement "itératif", car il nécessite une nouvelle itération sous la forme d'un nouveau mini-projet dans lequel le même processus de travail est répété ; et "incrémental" parce que cette nouvelle itération serait comme un affinage de la première. Et tout cela dans des intervalles de temps non consécutifs, contrairement à Scrum où les sprints d'affinage se succèdent les uns après les autres.<br/>		En revanche, les cycles de développement standard de Shape Up sont d'environ 6 semaines, plus une période de relâchement ([https://www.linkedin.com/pulse/introducci%C3%B3n-al-m%C3%A9todo-shape-up-per%C3%ADodo-de-cool-down-marc-rovira-vall/?lipi=urn%3Ali%3Apage%3Ad_flagship3_pulse_read%3BPhrDMiQbRnCMx0stD0Osng%3D%3D ''Cool-down'']) de 2 semaines, suivant également un modèle "itératif et incrémental", mais non consécutif dans le temps. Dans Shape Up, nous partons d'un document Pitch, qui est le résultat de [https://www.linkedin.com/pulse/introducci%C3%B3n-al-m%C3%A9todo-shape-up-fase-de-shaping-marc-rovira-vall/?lipi=urn%3Ali%3Apage%3Ad_flagship3_pulse_read%3BPhrDMiQbRnCMx0stD0Osng%3D%3D l'étape Shaping], et à partir de là, l'équipe (de développement) commence à ordonner le travail qu'elle découvre qu'elle doit faire, en identifiant les différents éléments du logiciel qui le composent, en commençant par [https://basecamp.com/gettingreal/09.2-epicenter-design l'épicentre], découvrant ainsi les problèmes à résoudre en suivant un ordre logique d'exécution. Dans Shape Up, pratiquement toute nouvelle fonctionnalité est mise en œuvre en un seul cycle de 6 semaines au maximum, mais il peut arriver que quelque chose d'important ait été oublié dans le cycle par manque de temps (le but que nous nous sommes fixé). Dans ce cas, nous pouvons toujours procéder à une nouvelle mise en forme (''shaping'') des améliorations qui ont été laissées de côté (qu'il s'agisse d'aspects de conception UX/UI, de cas d'utilisation non envisagés, de nouveaux paramètres de configuration, etc. De cette façon, nous appliquerions un développement "itératif", car il nécessite une nouvelle itération sous la forme d'un nouveau mini-projet dans lequel le même processus de travail est répété ; et "incrémental" parce que cette nouvelle itération serait comme un affinage de la première. Et tout cela dans des intervalles de temps non consécutifs, contrairement à Scrum où les sprints d'affinage se succèdent les uns après les autres.<br/>

Fabrice Aimetti le 19 décembre 2023 à 21:51

Fabrice Aimetti — Tue, 19 Dec 2023 21:51:24 GMT

← Version précédente		Version du 19 décembre 2023 à 21:51
Ligne 1 :		Ligne 1 :
	[[Category: Portail Framework]]		[[Category: Portail Framework]]
			[[Category: Shape Up]]
	Auteur : Marc Rovira Vall<br />		Auteur : Marc Rovira Vall<br />
	Source : [https://www.linkedin.com/pulse/scrum-vs-shape-up-diferencias-marc-rovira-vall/ Scrum vs. Shape Up: Diferencias]<br />		Source : [https://www.linkedin.com/pulse/scrum-vs-shape-up-diferencias-marc-rovira-vall/ Scrum vs. Shape Up: Diferencias]<br />

Fabrice Aimetti : Fabrice Aimetti a déplacé la page Scrum vs. Shape Up : Différences vers Scrum vs. Shape Up : les différences sans laisser de redirection

Fabrice Aimetti — Tue, 19 Dec 2023 21:50:37 GMT

Fabrice Aimetti a déplacé la page Scrum vs. Shape Up : Différences vers Scrum vs. Shape Up : les différences sans laisser de redirection

← Version précédente		Version du 19 décembre 2023 à 21:50
(Aucune différence)

Fabrice Aimetti le 19 décembre 2023 à 21:49

Fabrice Aimetti — Tue, 19 Dec 2023 21:49:29 GMT

@@ Ligne 77 : / Ligne 77 : @@
 <br/>
 En revanche, Shape Up propose de créer des environnements sans distraction afin d'atteindre une productivité élevée au sein de l'équipe. Chaque petite distraction peut coûter 20 minutes à un développeur avant qu'il ne revienne à un état productif. Si nous devions résumer l'approche de la productivité chez Shape Up par une formule fictive, elle ressemblerait à celle qui figure à droite de l'illustration : pour atteindre une productivité élevée, nous devons limiter le nombre de réunions, éviter les conversations inutiles et ne pas perdre de temps avec des tâches bureaucratiques qui n'ajoutent pas de valeur à l'équipe ou au produit, comme l'utilisation d'outils de ticketing (tels que JIRA), de rapports inutiles ou de contrôles du temps de travail. Si nous parvenons à protéger l'équipe des distractions, nous avons déjà gagné la moitié de la bataille. La deuxième partie de la formule consiste à s'assurer que l'équipe ne perd pas de temps et d'énergie sur des choses sans importance. Par conséquent, l'équipe ne doit pas compliquer à l'excès la mise en œuvre des fonctionnalités (il faut toujours viser la simplicité), ne doit pas sur-ingénieriser le code et ne doit pas travailler sur des tâches ''nice-to-have''.<br/>
 <br/>
- Alors, est-il possible de travailler dans un environnement sans backlogs, sans que les managers découpent le travail à faire et que les programmeurs agissent comme de simples preneurs de tickets (''ticket-takers''), sans post-its sur les murs, sans estimations avec des story points, sans la nécessité de participer à des rituels tels que des mêlées quotidiennes et d'autres cérémonies où l'on accorde beaucoup d'importance aux choses qui sont faites, sans la nécessité de suivre constamment la vélocité de l'équipe, sans le rôle d'un Scrum Master, et enfin sans un Chef de Projet chargé de maintenir l'équilibre entre le périmètre, le coût et le délai ([https://en.wikipedia.org/wiki/Project_management_triangle le triangle de fer]) du projet ?
+Merci beaucoup d'avoir lu cet article, partagez-le si vous l'avez aimé et postez vos commentaires ci-dessous. Si quelque chose que vous avez lu a éveillé votre intérêt et que vous avez envie d'essayer Shape Up, n'hésitez pas à me contacter.<br/>

Fabrice Aimetti le 19 décembre 2023 à 21:46

Fabrice Aimetti — Tue, 19 Dec 2023 21:46:46 GMT

← Version précédente		Version du 19 décembre 2023 à 21:46
Ligne 78 :		Ligne 78 :
	En revanche, Shape Up propose de créer des environnements sans distraction afin d'atteindre une productivité élevée au sein de l'équipe. Chaque petite distraction peut coûter 20 minutes à un développeur avant qu'il ne revienne à un état productif. Si nous devions résumer l'approche de la productivité chez Shape Up par une formule fictive, elle ressemblerait à celle qui figure à droite de l'illustration : pour atteindre une productivité élevée, nous devons limiter le nombre de réunions, éviter les conversations inutiles et ne pas perdre de temps avec des tâches bureaucratiques qui n'ajoutent pas de valeur à l'équipe ou au produit, comme l'utilisation d'outils de ticketing (tels que JIRA), de rapports inutiles ou de contrôles du temps de travail. Si nous parvenons à protéger l'équipe des distractions, nous avons déjà gagné la moitié de la bataille. La deuxième partie de la formule consiste à s'assurer que l'équipe ne perd pas de temps et d'énergie sur des choses sans importance. Par conséquent, l'équipe ne doit pas compliquer à l'excès la mise en œuvre des fonctionnalités (il faut toujours viser la simplicité), ne doit pas sur-ingénieriser le code et ne doit pas travailler sur des tâches ''nice-to-have''.<br/>		En revanche, Shape Up propose de créer des environnements sans distraction afin d'atteindre une productivité élevée au sein de l'équipe. Chaque petite distraction peut coûter 20 minutes à un développeur avant qu'il ne revienne à un état productif. Si nous devions résumer l'approche de la productivité chez Shape Up par une formule fictive, elle ressemblerait à celle qui figure à droite de l'illustration : pour atteindre une productivité élevée, nous devons limiter le nombre de réunions, éviter les conversations inutiles et ne pas perdre de temps avec des tâches bureaucratiques qui n'ajoutent pas de valeur à l'équipe ou au produit, comme l'utilisation d'outils de ticketing (tels que JIRA), de rapports inutiles ou de contrôles du temps de travail. Si nous parvenons à protéger l'équipe des distractions, nous avons déjà gagné la moitié de la bataille. La deuxième partie de la formule consiste à s'assurer que l'équipe ne perd pas de temps et d'énergie sur des choses sans importance. Par conséquent, l'équipe ne doit pas compliquer à l'excès la mise en œuvre des fonctionnalités (il faut toujours viser la simplicité), ne doit pas sur-ingénieriser le code et ne doit pas travailler sur des tâches ''nice-to-have''.<br/>
	<br/>		<br/>
			Alors, est-il possible de travailler dans un environnement sans backlogs, sans que les managers découpent le travail à faire et que les programmeurs agissent comme de simples preneurs de tickets (''ticket-takers''), sans post-its sur les murs, sans estimations avec des story points, sans la nécessité de participer à des rituels tels que des mêlées quotidiennes et d'autres cérémonies où l'on accorde beaucoup d'importance aux choses qui sont faites, sans la nécessité de suivre constamment la vélocité de l'équipe, sans le rôle d'un Scrum Master, et enfin sans un Chef de Projet chargé de maintenir l'équilibre entre le périmètre, le coût et le délai ([https://en.wikipedia.org/wiki/Project_management_triangle le triangle de fer]) du projet ?

Fabrice Aimetti le 19 décembre 2023 à 21:43

Fabrice Aimetti — Tue, 19 Dec 2023 21:43:57 GMT

← Version précédente		Version du 19 décembre 2023 à 21:43
Ligne 43 :		Ligne 43 :

	==Epics et User Stories vs Document Pitch==		==Epics et User Stories vs Document Pitch==
			[[Fichier:SU backlogs vs few options.png\|border\|link=\|800px]]<br/>
			<small>''Illustration créée par l'auteur avec Excalidraw''</small><br/>
			<br/>
			Une autre différence que nous constatons est que dans Scrum, vous travaillez avec des " flux de tickets ", où vous avez essentiellement un tas de tickets (compris comme des éléments qui composent le Backlog Produit) dans un outil de ticketing comme JIRA, Github, Trello ou autre, et il y en a toujours un qui commence par un : en tant que <type d'utilisateur>, je veux <fonctionnalité>, pour <obtenir un bénéfice>. En soi, ce n'est pas mauvais, mais le problème est que chaque ticket provient souvent de différentes parties de l'application/du système, ce qui signifie que l'équipe doit constamment changer de contexte. Imaginons qu'un développeur travaille, par exemple, sur quatre ou cinq tickets pendant le sprint et que chaque ticket provienne d'une partie complètement différente de l'application. Il est alors continuellement obligé d'apprendre différentes parties de l'application, ce qui lui prend beaucoup de temps et d'énergie. Parfois, cela se produit parce que l'objectif du sprint n'a pas été défini de manière suffisamment claire.<br/>
			<br/>
			Là encore, l'approche est complètement différente de celle de Shape Up. La personne responsable du produit est celle qui prépare une proposition de mini-projet (ou Pitch), qui définit, au niveau d'abstraction approprié, ce qui doit être réalisé au cours des 6 prochaines semaines (ou 2 semaines s'il s'agit d'un projet plus petit). Une fois la proposition préparée et prête à être mise en œuvre, l'équipe de développement se voit accorder l'autonomie sur le mini-projet dans la phase de construction, et l'équipe s'auto-organise comme elle l'entend pour mettre en œuvre ce qui est décrit dans le Pitch.<br/>

			==Priorités vs Binarité==
			[[Fichier:SU priorités vs binaires.png\|border\|link=\|800px]]<br/>
			<small>''Illustration créée par l'auteur avec Excalidraw''</small><br/>
			<br/>
			Dans Scrum et d'autres cadres agiles, nous avons l'habitude d'utiliser des techniques de priorisation comme celles décrites dans la partie gauche de l'illustration pour prioriser les Backlogs ou les longues listes de choses que nous voulons faire. Les gens semblent les adorer, mais dans le développement de produits digitaux, lorsqu'il s'agit de choisir ce qu'il faut faire ensuite, la réponse finit toujours par être binaire : "oui" ou "non", "maintenant" ou "pas maintenant", un "peut-être" est un "non" (pour l'instant). Le fait d'être binaire sur ce que nous choisissons de faire apporte de la clarté sur ce que nous devrions faire.<br/>
			<br/>
			Shape Up est binaire dans la prise de décision qui a lieu à la table de pari dans l'étape Betting (choisir les quelques options dans le format Pitch qui vont dans le cycle suivant), par opposition au choix des différents tickets qui constituent le backlog du sprint dans Scrum.<br/>

			==Taille et composition de l'équipe==
			[[Fichier:SU composition équipe.png\|border\|link=\|800px]]<br/>
			<small>''Illustration créée par l'auteur avec Excalidraw''</small><br/>
			<br/>
			En ce qui concerne les équipes, la taille standard d'une équipe Scrum est de 10 personnes au maximum, avec au moins un Product Owner, un Scrum Master et plusieurs développeurs composant l'équipe Scrum, selon le [https://scrumguides.org/scrum-guide.html Guide Scrum 2020].<br/>
			<br/>
			Avec Shape Up, les équipes de développement de produits sont composées de 2 ou 3 personnes au maximum (généralement un concepteur et un ou deux programmeurs). Les testeurs QA et les autres profils techniques transversaux sont impliqués ponctuellement lorsque cela est nécessaire. Avec des équipes de 3 personnes au maximum dans l'équipe de développement principale, la communication et l'interaction sociale entre les différents membres de l'équipe sont grandement simplifiées. Une équipe de 3 personnes signifie qu'il ne peut y avoir qu'un maximum de 3 canaux de communication ouverts à tout moment (voir la partie droite de l'illustration). Le simple fait d'ajouter une personne à l'équipe augmente la complexité de manière exponentielle (4 personnes signifient 6 canaux de communication possibles ouverts en même temps). Avec deux personnes, il y a une communication directe, c'est-à-dire qu'elles peuvent se parler. Avec trois personnes, elles ne se parlent plus, mais ont une conversation. Et avec quatre personnes ou plus, la seule chose qu'ils peuvent faire est une réunion. Il devient alors plus difficile de tenir tout le monde informé. Plus il y a de personnes impliquées, plus les choses vont lentement.<br/>
			<br/>
			En outre, les équipes de taille importante impliquent des discussions plus longues, il est plus difficile de parvenir à un consensus, il est plus difficile de partager des connaissances importantes entre les membres, et l'alchimie qui se crée n'est pas la même que dans les petits groupes. Des silos peuvent même être créés au sein de l'équipe elle-même (les programmeurs d'un côté, les concepteurs de l'autre, les testeurs QA de l'autre, etc.)<br/>
			<br/>
			Une autre différence concernant les équipes est que dans Shape Up, les personnes sont généralement sélectionnées (à la table de paris) pour travailler sur un projet spécifique, c'est-à-dire que les équipes sont reconfigurées à chaque fois. Dans Scrum, en revanche, le travail est confié à l'équipe et la composition de l'équipe ne change généralement pas en fonction des besoins du projet.

			==Vélocité de l'équipe==
			[[Fichier:SU velocity.png\|border\|link=\|800px]]<br/>
			<small>''Crédits à Salsita Software (partie droite), retouché par l'auteur (partie gauche) avec Excalidraw''</small><br/>
			<br/>
			Dans Scrum, il existe une formule (voir la partie gauche de l'illustration) qui sert d'indicateur de la performance de l'équipe à un moment donné. Cette formule de vélocité de l'équipe est ensuite utilisée pour prédire le temps nécessaire (ou le nombre de sprints nécessaires) pour terminer une fonctionnalité donnée qui se trouve encore dans le Backlog.<br/>
			<br/>
			En revanche, Shape Up propose de créer des environnements sans distraction afin d'atteindre une productivité élevée au sein de l'équipe. Chaque petite distraction peut coûter 20 minutes à un développeur avant qu'il ne revienne à un état productif. Si nous devions résumer l'approche de la productivité chez Shape Up par une formule fictive, elle ressemblerait à celle qui figure à droite de l'illustration : pour atteindre une productivité élevée, nous devons limiter le nombre de réunions, éviter les conversations inutiles et ne pas perdre de temps avec des tâches bureaucratiques qui n'ajoutent pas de valeur à l'équipe ou au produit, comme l'utilisation d'outils de ticketing (tels que JIRA), de rapports inutiles ou de contrôles du temps de travail. Si nous parvenons à protéger l'équipe des distractions, nous avons déjà gagné la moitié de la bataille. La deuxième partie de la formule consiste à s'assurer que l'équipe ne perd pas de temps et d'énergie sur des choses sans importance. Par conséquent, l'équipe ne doit pas compliquer à l'excès la mise en œuvre des fonctionnalités (il faut toujours viser la simplicité), ne doit pas sur-ingénieriser le code et ne doit pas travailler sur des tâches ''nice-to-have''.<br/>
			<br/>

Fabrice Aimetti : /* Epics et User Stories vs Documents du Pitch */

Fabrice Aimetti — Tue, 19 Dec 2023 21:26:58 GMT

Epics et User Stories vs Documents du Pitch

← Version précédente		Version du 19 décembre 2023 à 21:26
Ligne 42 :		Ligne 42 :
	Une autre différence est que l'affinage dans Scrum se fait au niveau de la story utilisateur et affecte le Backlog Produit (ajout de détails techniques et d'estimations dans les stories, repriorisation du Backlog, etc.) ; alors que dans Shape Up le shaping se fait au niveau du document Pitch sans aucun effet sur le Backlog parce que dans Shape Up le concept de Backlog tel que nous le connaissons n'existe pas.		Une autre différence est que l'affinage dans Scrum se fait au niveau de la story utilisateur et affecte le Backlog Produit (ajout de détails techniques et d'estimations dans les stories, repriorisation du Backlog, etc.) ; alors que dans Shape Up le shaping se fait au niveau du document Pitch sans aucun effet sur le Backlog parce que dans Shape Up le concept de Backlog tel que nous le connaissons n'existe pas.

	==Epics et User Stories vs ~~Documents du~~ Pitch==		==Epics et User Stories vs Document Pitch==

Fabrice Aimetti le 19 décembre 2023 à 21:26

Fabrice Aimetti — Tue, 19 Dec 2023 21:26:19 GMT

← Version précédente		Version du 19 décembre 2023 à 21:26
Ligne 40 :		Ligne 40 :
	En revanche, le Shaping dans Shape Up est pratiquement un travail à temps plein effectué par un profil Produit senior (type Product Manager) pendant les 6 semaines du cycle, qui, après que le pari ait été effectué (dans [https://www.linkedin.com/pulse/introducci%C3%B3n-al-m%C3%A9todo-shape-up-fase-de-betting-marc-rovira-vall/?lipi=urn%3Ali%3Apage%3Ad_flagship3_pulse_read%3BPhrDMiQbRnCMx0stD0Osng%3D%3D l'étape Betting]), le Pitch résultant est transmis à l'équipe de développement pour qu'elle l'exécute. Au cours de l'étape Shaping, les experts techniques (analystes, architectes, programmeurs, concepteurs UX/UI, testeurs QA, etc.) sont impliqués de temps à autre pour évaluer la faisabilité technique de ce qui est défini (en effectuant des [https://en.wikipedia.org/wiki/Spike_(software_development) spikes] si nécessaire). Leur implication précoce aide également l'équipe de développement à s'approprier le projet (meilleure acceptation) au moment de se mettre au travail (à [https://www.linkedin.com/pulse/introducci%C3%B3n-al-m%C3%A9todo-shape-up-fase-de-building-marc-rovira-vall/?lipi=urn%3Ali%3Apage%3Ad_flagship3_pulse_read%3BPhrDMiQbRnCMx0stD0Osng%3D%3D l'étape de la construction]).<br/>		En revanche, le Shaping dans Shape Up est pratiquement un travail à temps plein effectué par un profil Produit senior (type Product Manager) pendant les 6 semaines du cycle, qui, après que le pari ait été effectué (dans [https://www.linkedin.com/pulse/introducci%C3%B3n-al-m%C3%A9todo-shape-up-fase-de-betting-marc-rovira-vall/?lipi=urn%3Ali%3Apage%3Ad_flagship3_pulse_read%3BPhrDMiQbRnCMx0stD0Osng%3D%3D l'étape Betting]), le Pitch résultant est transmis à l'équipe de développement pour qu'elle l'exécute. Au cours de l'étape Shaping, les experts techniques (analystes, architectes, programmeurs, concepteurs UX/UI, testeurs QA, etc.) sont impliqués de temps à autre pour évaluer la faisabilité technique de ce qui est défini (en effectuant des [https://en.wikipedia.org/wiki/Spike_(software_development) spikes] si nécessaire). Leur implication précoce aide également l'équipe de développement à s'approprier le projet (meilleure acceptation) au moment de se mettre au travail (à [https://www.linkedin.com/pulse/introducci%C3%B3n-al-m%C3%A9todo-shape-up-fase-de-building-marc-rovira-vall/?lipi=urn%3Ali%3Apage%3Ad_flagship3_pulse_read%3BPhrDMiQbRnCMx0stD0Osng%3D%3D l'étape de la construction]).<br/>
	<br/>		<br/>
			Une autre différence est que l'affinage dans Scrum se fait au niveau de la story utilisateur et affecte le Backlog Produit (ajout de détails techniques et d'estimations dans les stories, repriorisation du Backlog, etc.) ; alors que dans Shape Up le shaping se fait au niveau du document Pitch sans aucun effet sur le Backlog parce que dans Shape Up le concept de Backlog tel que nous le connaissons n'existe pas.

			==Epics et User Stories vs Documents du Pitch==

Fabrice Aimetti le 19 décembre 2023 à 21:24

Fabrice Aimetti — Tue, 19 Dec 2023 21:24:05 GMT

← Version précédente		Version du 19 décembre 2023 à 21:24
Ligne 33 :		Ligne 33 :

	==Affinage du Backlog vs Shaping==		==Affinage du Backlog vs Shaping==
			[[Fichier:SU part time vs full time.png\|border\|link=\|800px]]<br/>
			<small>''Illustration créée par l'auteur avec Excalidraw''</small><br/>
			<br/>
			L'affinage du Backlog dans Scrum est souvent considéré comme une activité à temps partiel, réservant 5 à 10% de la capacité de l'équipe Scrum (complète ou partielle) pendant le sprint en cours pour préparer les stories du prochain sprint (ou des deux prochains sprints).<br/>
			<br/>
			En revanche, le Shaping dans Shape Up est pratiquement un travail à temps plein effectué par un profil Produit senior (type Product Manager) pendant les 6 semaines du cycle, qui, après que le pari ait été effectué (dans [https://www.linkedin.com/pulse/introducci%C3%B3n-al-m%C3%A9todo-shape-up-fase-de-betting-marc-rovira-vall/?lipi=urn%3Ali%3Apage%3Ad_flagship3_pulse_read%3BPhrDMiQbRnCMx0stD0Osng%3D%3D l'étape Betting]), le Pitch résultant est transmis à l'équipe de développement pour qu'elle l'exécute. Au cours de l'étape Shaping, les experts techniques (analystes, architectes, programmeurs, concepteurs UX/UI, testeurs QA, etc.) sont impliqués de temps à autre pour évaluer la faisabilité technique de ce qui est défini (en effectuant des [https://en.wikipedia.org/wiki/Spike_(software_development) spikes] si nécessaire). Leur implication précoce aide également l'équipe de développement à s'approprier le projet (meilleure acceptation) au moment de se mettre au travail (à [https://www.linkedin.com/pulse/introducci%C3%B3n-al-m%C3%A9todo-shape-up-fase-de-building-marc-rovira-vall/?lipi=urn%3Ali%3Apage%3Ad_flagship3_pulse_read%3BPhrDMiQbRnCMx0stD0Osng%3D%3D l'étape de la construction]).<br/>
			<br/>

Fabrice Aimetti le 19 décembre 2023 à 21:18

Fabrice Aimetti — Tue, 19 Dec 2023 21:18:37 GMT

@@ Ligne 23 : / Ligne 23 : @@
 <br/>
 En revanche, les cycles de développement standard de Shape Up sont d'environ 6 semaines, plus une période de relâchement ([https://www.linkedin.com/pulse/introducci%C3%B3n-al-m%C3%A9todo-shape-up-per%C3%ADodo-de-cool-down-marc-rovira-vall/?lipi=urn%3Ali%3Apage%3Ad_flagship3_pulse_read%3BPhrDMiQbRnCMx0stD0Osng%3D%3D ''Cool-down'']) de 2 semaines, suivant également un modèle "itératif et incrémental", mais non consécutif dans le temps. Dans Shape Up, nous partons d'un document Pitch, qui est le résultat de [https://www.linkedin.com/pulse/introducci%C3%B3n-al-m%C3%A9todo-shape-up-fase-de-shaping-marc-rovira-vall/?lipi=urn%3Ali%3Apage%3Ad_flagship3_pulse_read%3BPhrDMiQbRnCMx0stD0Osng%3D%3D l'étape Shaping], et à partir de là, l'équipe (de développement) commence à ordonner le travail qu'elle découvre qu'elle doit faire, en identifiant les différents éléments du logiciel qui le composent, en commençant par [https://basecamp.com/gettingreal/09.2-epicenter-design l'épicentre], découvrant ainsi les problèmes à résoudre en suivant un ordre logique d'exécution. Dans Shape Up, pratiquement toute nouvelle fonctionnalité est mise en œuvre en un seul cycle de 6 semaines au maximum, mais il peut arriver que quelque chose d'important ait été oublié dans le cycle par manque de temps (le but que nous nous sommes fixé). Dans ce cas, nous pouvons toujours procéder à une nouvelle mise en forme (''shaping'') des améliorations qui ont été laissées de côté (qu'il s'agisse d'aspects de conception UX/UI, de cas d'utilisation non envisagés, de nouveaux paramètres de configuration, etc. De cette façon, nous appliquerions un développement "itératif", car il nécessite une nouvelle itération sous la forme d'un nouveau mini-projet dans lequel le même processus de travail est répété ; et "incrémental" parce que cette nouvelle itération serait comme un affinage de la première. Et tout cela dans des intervalles de temps non consécutifs, contrairement à Scrum où les sprints d'affinage se succèdent les uns après les autres.<br/>
 <br/>