alice cooper - scrum

L’art du Scrum – conseils par Food Tuner

Aide-nous! Partage :-)Share on FacebookPin on PinterestTweet about this on TwitterShare on Google+Print this page

Toutes les stars du rock (aka entrepreneurs) doivent apprendre l’art de Scrum. C’est un peu comme le solfège, disons.

En principe, tout semble logique, mais cela devient un peu déroutant lorsque vous commencez à utiliser des outils comme JIRA.

Voici quelques conseils pour vous aider à créer votre « Product Backlog » et à faire des réunions efficaces.

Le Groupe

Tout d’abord, dans un groupe, vous avez des rôles différents:

Le « Product Owner » ou chef de produit

C’est celui qui a la vision. Il est en contact permanent avec les clients et les utilisateurs. Il doit donner des priorités à l’équipe. C’est lui qui décider en dernier lieu de valider les releases. Il se concentre sur le « quoi » beaucoup plus que sur le « comment ».

La Scrum Team 

C’est ceux qui s’occupent du « comment ». Cette équipe est composée de personnes aux compétences variées: les développeurs front-end, les dev back-end, les designers, les administrateurs système, les testeurs, etc. Leur but est de construire un « produit potentiellement livrable » à chaque sprint. Les membres de ce groupe doivent être team players, ils travaillent ensemble, s’aider les uns les autres et apprendre de leur travail en commun.

Le scrum master

Cette personne n’a pas de responsabilité de manager. Elle doit être un « facilitateur ». En conséquence, si vous êtes le chef de projet ou le manager de l’équipe, par définition, vous ne pouvez pas être le scrum master.

Si vous êtes un petit groupe qui rock, assurez-vous que vos rôles sont clairs dès le départ. Qui est le Product Owner? Qui est le scrum master?

 

Le Product Backlog

 

Le Product Backlog est une liste de toutes les fonctionnalités et des actions que votre produit pourrait un jour avoir ou faire. Attention, nous parlons ici du produit, pas le la start-up. Par conséquent, « lancer une campagne de crowdfunding » est pas un Item du Product Backlog (PBI).

Ce Product Backlog est trié par ordre de priorité: les items les plus importants au sommet de la liste.

C’est le product owner qui exprime ses exigences à l’équipe. Voici un exemple « nos utilisateurs demandent les étapes de la recette, ce qui est plus important pour eux que de sauvegarder leur recettes préférées ».

 

Le Sprint Backlog

 

Dans une start-up, les choses vont vite. En fait, vous devez faire des sprints courts afin de tester ce que vous avez développé avec vos utilisateurs. Le plus tôt vous remarquez que vous êtes sur la mauvaise voie, mieux ce sera.

Le format de sprint standard est donc de deux semaines, mais vous pouvez aller jusqu’à un mois.

Pour le prochain sprint, l’équipe se met d’accord sur les items du Product Backlog sur lesquels il faudra travailler.

Dans des outils comme JIRA, vos PBIs sont des User Stories. Vous définissez ensuite comment développer ces User Stories en créant des tâches. Quand le sprint est actif, vous déplacez ces tâches sur votre board, du Sprint Backlog (ou « to do »), à en cours (ou « In Progress »), puis Terminé (ou « done »). Vous pouvez également ajouter une colonne « A tester ».

Soyez attentif à la taille de votre BPIs, voir la revue du backlog.

 

La revue du backlog

 

Cette réunion est très importante. Consacrez y régulièrement deux heures. Vous n’aurez probablement pas le temps de parler de tous les éléments, mais le plus important est de clarifier le haut de la liste.

Le but de cette réunion est de vous assurer que les BPI répondent aux critères suivants:
Indépendant
Négociable
A de la Valeur
Estimable
Small (Petit)
 Testable

Une solution consiste à utiliser des cartes où il est écrit Small Medium Large et Extra Large (ou S, M, L, XL). Utilisez les pour que chaque membre du groupe évalue le temps nécessaire pour compléter le premier BPI. Chacun explique ensuite pourquoi il a choisi cette carte, en particulier si des cartes différentes ont été sélectionnées. En faisant cet exercice, vous vous rendrez compte que votre PBI ne remplit probablement pas certains des critères ci-dessus. Ainsi, révisez le BPI en le divisant en plusieurs user stories.

Si vous vous rendez compte, par exemple, qu’il y a plusieurs user stories à intérieur de votre PBI, vous pouvez alors changer ce PBI en « epic », qui est un groupe de user stories.

Faites encore une fois ce travail, jusqu’à ce que tout le monde tire la même carte.

Revoyez les priorités si nécessaire.

N’oubliez pas de définir les critères d’acceptation pour chaque PBI. Quels sont les critères qui vont vous permettre de considérer que cette user story est complétée? Voici un exemple: la fonction fonctionne sur Chrome, sur les ordinateurs et les mobiles (voir la réunion de planification du Sprint pour plus d’informations)

Réunion de planification du Sprint

 

Les décisions pour le sprint sont très importantes, prenez donc vraiment le temps d’examiner les BPIs. Consacrez quatre heures pour un 2 semaines Sprint.

Votre sprint doit contenir ces étapes, si vous compter faire un release: analyse, conception, implémentation, tests, intégration et déploiement.

Le Product Owner doit  partager sa liste de priorités avec le groupe. Ensemble, ils doivent examiner si l’équipe peut s’engager à accomplir les tâches requises dans le délai de sprint.

Mettre en place des critères de succès. Une tâche est effectuée quand elle est:

correctement testée
 optimale (du point de vue du code)
potentiellement livrable

Les questions à poser à la fin de la réunion:

1. Quelles sont les tâches à effectuer pour obtenir ces user stories dans un état potentiellement livrable?

2. Pensez-vous que nous pouvons le faire en deux semaines sans compromettre notre définition de «fait» et sans heures supplémentaires?

3. Qui pense que nous ne pouvons pas le faire?

L’équipe est maintenant engagée à terminer ce PBI dans le sprint. Vous pouvez maintenant passer au deuxième BPI et faire le même travail.

Question:

4. Pouvons-nous faire ces deux BPI dans les 2 semaines?

5. Qui pense que nous ne pouvons pas le faire?

L’équipe est maintenant engagée à terminer ce PBI dans le sprint. Vous pouvez maintenant passer au troisième BPI et faire le même travail.

À la fin de la réunion, vous pouvez décider de qui fait quoi ou attendre que le sprint commence pour le faire.

 

Daily Scrum Meeting

 

Durée: 15 minutes.

Chaque participant doit répondre à ces trois questions:

1. Qu’est-ce que j’ai fait hier (ou depuis le dernier Scrum Meeting)?

2. Qu’est-ce que je vais faire aujourd’hui (ou d’ici au prochain Scrum Meeting)?

3. Qu’est-ce qui bloque mes progrès ou réduit mon efficacité?

À ce stade, lorsque vous commentez ce qui doit être fait, vous pouvez mettre à jour le projet dans JIRA ou sur un scrum board physique et identifier qui fait quoi.

Si il y a des additionnels qui ont besoin d’être traités, vous pouvez les noter et les aborder après le Scrum Meeting).

 

La Revue du Sprint

 

A la revue du Sprint, vous pouvez inviter des personnes extérieures à votre groupe. Il peut s’agir de personnes du département des ventes par exemple. L’événement le plus important de cette réunion est la démonstration du produit en direct.

Le Product Owner évaluera alors si les PBIs, sur lesquels le groupe s’était engagé, répondent aux critères d’acceptation définis à la réunion de planification du Sprint et si les objectifs du Sprint sont atteints.

Ordre du jour:

1. Démonstration du produit

2. Product Owner déclare ce qui est considéré comme accompli

3. Mesure de la vitesse

4. Commentaires et remarques

Si des fonctionnalités supplémentaires sont demandées par le product owner, ils peuvent être ajoutés au Product Backlog et intégrés au prochain Sprint.

J’espère que cet article a contribué à clarifier un peu le processus. N’hésitez pas à nous laisser des commentaires!

Cheers!

Anne-Sophie

Bretonne, j'ai une âme d'exploratrice. J'adore apprendre de nouvelles choses et résoudre des problèmes.