« Scrum vs. Shape Up : les différences » : différence entre les versions
De Wiki Agile
Aucun résumé des modifications |
Aucun résumé des modifications |
||
| 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 ? | |||
