Si la première journée m'avait un peu laissé sur la faim, cette deuxième journée fut un peu plus intéressante. Nous avons eu l'occasion d'aborder :
- Les rôles dans Scrum :
- Le Product Owner est un décisionnaire qui a en charge la gestion et l'alimentation du Product Backlog (ce qu'il y a à faire, i.e. le QUOI) en plus de bien veiller à ce que la Vision du produit soit bien partagée par l’ensemble des intervenants. Son rôle est vraiment déterminant pour la réussite du projet d'autant qu'il se doit d'être le plus disponible possible pour la Scrum Team durant toute la réalisation du Sprint ;
- Le Scrum Master a quant à lui la responsabilité de s'assurer que la méthode Scrum est bien respectée par tous. C'est avant tout un facilitateur qui présente des qualités humaines indéniables (empathie, bienveillance) en plus d'être un leader. Toutefois, il ne doit pas être directif ni imposer son point de vue. Il doit avant tout gérer les conflits et aider l'équipe à franchir les obstacles qu'elle rencontre. Son rôle est un rôle à plein temps, du moins au début... Car à plus long terme, lorsque la méthode est parfaitement assimilée, son rôle n'est plus nécessaire. Il peut soit redevenir un membre de la Scrum Team (cf. ci-après) ou devenir coach Scrum qui par conséquent intervient sur un autre projet dans le but d'enseigner la méthode auprès de nouvelles équipes ;
- La Scrum Team est l'équipe en charge de réaliser le produit. Elle commence par planifier et estimer ce qu'il y a à faire en sélectionnant en priorité les User Stories qui présente la plus grande valeur ajoutée pour le Product Owner et qui constituent la Backlog du Sprint. Les User Stories sélectionnées doivent avoir au préalable avoir été validées par le Product Owner et suffisamment spécifiées pour qu'il ne subsiste aucune ambiguïté au début du Sprint. Ces User Stories sont ensuite décomposées en tâches suffisamment fines pour pouvoir tenir dans un Sprint (une itération). Cette décomposition en tâches est réalisée par la Scrum Team (qui apporte donc la réponse au COMMENT) en accord avec le Product Owner. Lorsqu'une User Story comporte trop de points de réalisation, celle-ci devient une Epic (Épopée) qui est elle-même subdivisée en plusieurs sous User Stories ;
- Le principe général de la méthode, i.e. itérative et incrémentale, de deux à quatre semaines avec des mêlées quotidiennes, les points communs et les différences avec Kanban ;
- Les types de réunion suivantes :
- La réunion de planification au début de l'itération ;
- La réunion de clôture en fin d'itération (la démo au client) ;
- La rétrospective ;
- Les ateliers pratiques après les Lego et les avions en papier de la veille :
- Exercice de la NASA qui pose la question des objets à emmener avec soi pour survivre sur la Lune et répondant dans un temps contraint, d'abord tout seul, puis en équipe pour montrer que l'intelligence collective est supérieure à l'intelligence individuelle ;
- Exercice sur la définition de la Vision d'un Produit ;
- Exercice de planification (commencé et qu'on doit terminer demain) ;
Le programme demain devrait normalement être chargé et je me demande comment nous pourrons tout voir :
- Terminer l'expérience de la planification en début de Sprint ;
- Le stand-up meeting ;
- La démo au client en fin d'itération;
- La rétrospective ;
- Ce qu'est qu'une entreprise agile ;
Pour note, nous sommes à la page 80 il me semble du support du cours (et il y en a au moins 250).
Le mot de la fin sera donc demain mais pour le moment, je pense que ces deux premières journées auraient pu largement tenir sur une seule.
Aucun commentaire:
Enregistrer un commentaire