« Scrum vs. Shape Up : les différences » : différence entre les versions

De Wiki Agile
← Modification précédente
VisuelWikicode
Aucun résumé des modifications
 
(3 versions intermédiaires par le même utilisateur non affichées)
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 />
Ligne 20 : 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/>
Ligne 77 : Ligne 78 :
<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/>
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/>
==Conclusion==
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 ?
La réponse est oui, et elle s'appelle Shape Up.
Voilà pour les différences entre Scrum et Shape Up. Dans un prochain article, nous verrons comment passer de Scrum à Shape Up sans mourir en cours de route.<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 ?
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/>
 
==À propos de l'auteur==
Je suis passionné par les nouvelles méthodes de travail et par l'organisation des équipes de produits et d'ingénierie afin d'en faire des équipes performantes et très motivées, garantissant la prévisibilité et la qualité des produits livrés. Je suis très attaché à la méthode Shape Up, une nouvelle approche du développement de produits numériques qui va au-delà des méthodes Agile, Lean, Kanban et Scrum.
Récupérée de "https://wikiagile.coach/Scrum_vs._Shape_Up_:_les_différences"