[DevoxxFR] How to not just survive but thrive with flexible scope

 Lors de cette session, Gojko Adzic a sans aucun doute réalisé l’une des meilleures présentations de ce Devoxx France 2014. Il annonce qu’il va nous donner des pistes pour malmener les Scrum Master et Product Owner, le ton est donné !

Gojko démarre sa présentation en parlant de son expérience personnelle. Il avait créé une société dans laquelle le niveau technique était élevé et avant gardiste sur les pratiques de développement (par exemple ses équipes réalisaient du DevOps bien avant que le terme soit inventé). Finalement cela n’a pas fonctionné comme il l’espérait : s’adapter aux changements était difficile.

Il poursuit en nous demandant à quelle date remonte le premier projet agile. Dans la salle nous entendons les années 80, ou 90. Après quelques recherches que Gojko a effectuées, il se trouve que le premier projet agile remonte à 1628 !

Il s’agit de l’histoire du Vasa, le célèbre bateau Norvégien. Pour résumé, le Roi avait commandé un bateau dernier cri (très esthétique, beaucoup de canons, etc). Il se trouve que ce bateau a été bien spécifié, livré dans les temps. Malheureusement, après avoir navigué à peine un mille marin, le bateau a coulé… Pour plus de détail, je vous invite à consulter cette adresse.

Gojko aborde ensuite la notion de vélocité. Pour lui cette dernière n’est pas une information fiable. Il nous donne l’exemple de la planification d’un trajet routier. Il souhaite aller de Paris à Brest et regarde les prévisions (les chiffres ne sont pas forcément exacts mais donnent un ordre idée) :

Distance : 390 km
Temps : 4h
Vitesse moyenne (km/h) : 105

La vitesse moyenne représente la vélocité. Mais après avoir réalisé le chemin, il a obtenu les valeurs suivantes :

Distance : 440 km
Temps : 5h
Vitesse moyenne (km/h) : 110

Lors de son périple, des évènements comme des travaux, accidents ont eu lieu.

Enfin dernier exemple pour nous montrer que la vélocité peut être aberrante :

Distance : 850 km
Temps : 8h
Vitesse moyenne (km/h) : 110

Sur le ton humoristique, Gojko nous dit que ce sont des valeurs pour aller de Paris à Brest en Allemagne. Cela renforce le fait que la vélocité ne reflète pas les changements pouvant avoir lieu en cours de route.

Gojko enchaîne sur d’autres métriques avec l’outil Sonar. Ce dernier apporte des informations intéressantes mais elles ne sont pas suffisantes pour garantir le succès d’un projet. En effet il est tout à fait possible d’avoir une couverture de test de 100% mais n’étant pas de qualité.
Il catégorise alors les métriques qui ont une bonne et une mauvaise influence. Sonar rentre dans cette seconde catégorie.

Il enchaîne en nous montrant une liste de user stories dans un Jira et une Road Map du projet ColdFusion d’Adobe. Pour lui cela apporte deux inconvénients majeurs :

• la vision du produit n’est pas claire
• cela démontre une certaine rigidité

Arrive ensuite un exemple avec une user story :

     En tant que vendeur
     Dans le but de suivre l’inventaire
     Je veux des rapports

Pour Gojko cela n’est pas assez précis. Il repart alors avec un exemple et nous montre la carte du centre de Paris. 

Pour atteindre une destination, nous avons un ensemble de chemins possibles. En chemin, nous pouvons nous rendre compte que nous ne sommes pas sur la bonne voie et modifier notre parcours. Il compare ainsi la destination à notre vision et nous avons une multitude de possibilités pour y parvenir.

Gojko évoque le fait qu’il faut faire des expériences et avancer. Nous allons sans doute nous tromper mais le plus important est d’apprendre de ses erreurs, de continuer d’avancer et de s’adapter aux changements.
Le plus important est d’avoir en tête la « big picture » et d’avoir un périmètre flexible.

Afin d’étayer ses arguments, Gojko nous parle des trois principes de Palchinsky :

• Rechercher de nouvelles idées et les essayer
• Lorsque vous essayez de nouvelles idées, faites en sortes qu’elles durent
• Rechercher du feedback et apprendre de ses échecs

Gojko revient sur la Road Map et nous fait remarquer que c’est plutôt un chemin parmi tant d’autres.

Il revient sur la user story et nous demande ce qu’il ne va pas. Pour lui les user stories sont des options et non des engagements. Elles doivent apporter un changement de comportement :

Il propose de l’améliorer avec la version suivante :

   En tant que vendeur
   Dans le but de suivre l’inventaire plus rapidement
   Je veux des rapports

Il finit sa présentation par nous dire que les bonnes user stories sont des expériences qui durent.

Je vous invite à consulter cette excellente présentation sur Parleys dès qu’elle sera disponible.